What middleware for network centric operations?

www.elsevier.com/locate/knosys

Knowledge-Based Systems 20 (2007) 255–265

What middleware for network centric operations?

Ali Benssam a, Jean Berger b, Abdeslem Boukhtouta b, Mourad Debbabi a,*,Sujoy Ray a, Abderrazak Sahi b

a Concordia Institute for Information Systems Engineering, Concordia University, Montreal, Que., Canadab Defence Research and Development Canada, Canadian National Defence, Valcartier, Que., Canada

Received 28 October 2005; accepted 6 May 2006Available online 5 October 2006

Abstract

The main intent of this paper is to address the issue of middleware in network centric operations. To this end, we characterize a set ofInformation Technology capabilities that such a middleware should implement. Afterwards, we will discuss the design and architecturalaspects of these capabilities. This will lead us to an efficient and practical decision support system that we call a digital cockpit. The latteris essentially a multi-tier IT platform that provides a plethora of services such as: data and service integration, monitoring, analysis, andprocess optimization. Moreover, the platform uses advanced display mechanisms to render the information in a structured and naviga-tional representation that offers the possibility to drill down into the details. A significant subgoal of the paper is to discuss the qualityattributes of such an NCO middleware. Finally, we present the results of an implementation of the aforesaid platform architecture.� 2007 Published by Elsevier B.V.

Keywords: Network centric operations; Middleware; Information technology; Data and service integration; Display; Monitoring; Analysis; Optimization;Decision support

1. Motivation and background

The Network Centric Operations (NCO) is a term thatencompasses a plethora of concepts that are popular inmany countries, military organizations and institutions,e.g.:

• Network Enabled Operations, NEOps (Canada).• Network Centric Warfare, NCW (US).• Network Enabled Capabilities, NEC (UK).• Network Based Defense, NBD (Sweden).• Network Enabled Operations, NEO (Australia).

It stands for the embodiment of information age in mil-itary intelligence, planning, operations, and logistics. Thisentails the seamless network connectivity and interopera-bility of major military platforms, systems, devices, sen-

0950-7051/$ - see front matter � 2007 Published by Elsevier B.V.

doi:10.1016/j.knosys.2006.05.020

* Corresponding author. Tel.: +1 514 8482424; fax: +1 418 8483171.E-mail address: [email protected] (M. Debbabi).

sors, and battle-space entities leading to remarkablesituation awareness. Consequently, NCO constitutes a par-adigm shift where battle-space entities are no longer stove-pipes (standalone entities) but rather a collection ofnetwork-enabled and network-ready entities that commu-nicate and interoperate in a seamless and synergistic way.

Progressively emerging from the co-evolution of organi-zation, technology, and doctrine, net-centricity aims to pro-vide shared information, shared intent, agility, and resource/decision synchronization. It addresses stove-pipe systemsproliferation, legacy system, connectivity, reusability, andprovides a suitable framework to enable organizationaltransformation and organization integration through net-centric enterprises services, to support analysis, coordina-tion and to ensure decision superiority and facilitate transi-tion from a platform centric environment for centralized/distributed resource management (complexity, multiplicity,diversity, and dynamic uncertain environment).

The critical cornerstone of any NCO platform is theunderlying information system. Information superiority,situational awareness, and self synchronization, which are

256 A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265

the main promises of the NCO paradigm are completelydependent on the quality of the NCO information system.Therefore, its architecture, design, and implementation arekey factors in the success of the operations in the battle-field. Hence, a special care should be devoted to the engi-neering of NCO information systems.

In this paper, we advocate the use of a middleware-based approach to elaborate the NCO information system.Such an approach is beneficial to both developers and usersof NCO applications. As of developers, it eases their designand programming tasks by abstracting from the complexityunderlying the inner workings of NCO core software com-ponents. Also, it provides more functional and high-levelset of application programming interfaces that increasethe productivity while improving several quality attributessuch as scalability and maintenance. Moreover; a middle-ware approach will improve the location transparency,which is a significant advantage especially with the distrib-uted nature of NCO applications. The use of open stan-dards within such a middleware will definitely ease morethe development of applications. Finally, if such a middle-ware is standardized, it will allow users to have vendor-in-dependence and the migration of their applications fromone middleware solution to the other one.

The primary intent of this paper is to address thearchitecture, design and implementation aspects of themiddleware underlying such an information system.Accordingly, our efforts will target those software compo-nents that will mediate NCO applications. We will charac-terize the set of capabilities that such a middleware shouldimplement. Then, we will explore the architectural anddesign aspects as well as the quality attributes that shouldbe considered in the deployment of such middleware.

Information systems have become the cornerstone thatshapes the present and the future of our economy and soci-ety. They have penetrated almost every aspect of our lives.This omnipresence is stemming from the significantadvancements in computer systems, software middlewareand applications, telecommunication infrastructures, etc.

Enterprises and organizations use a large variety of net-worked computer systems to collect, process, produce, andstore large volumes of information. Geographically distantcomputer systems are disparate in terms of hardware, plat-forms, operating systems, and software applications. Thisheterogeneity limits the scope of interchanging informationinside and outside the organizational environment. On theother side, the required services to interpret the aggregateddata are mostly available locally to the user’s terminal.Moreover, decision makers, top managers and leaders needa complete and efficient software infrastructure that cancontinuously subscribe to up-to-date local and global ser-vices and information, always synchronized to the real-time changes. In this paper, we address this high priorityorganizational interest to provide more competitive advan-tages in mission-critical situations.

While a surge of interest has lately been expressed sepa-rately on the data integration and web services technology,

only a few research has been so far conducted to propose ageneral architecture to support integration of informationsystems. Moreover, there exists different heterogeneousinformation system architectures related to specificdomains in the enterprises, with several restrictions andpolicy controls. We focus on a loosely coupled distributedparadigm that offers a message-based middleware, able tointegrate data and services from different industrialinfrastructures.

We also include in this paper an implementation of theproof of concept, referred as ‘‘Digital Cockpit’’. The intentof the digital cockpit is twofold: First, it achieves a syner-gistic integration of the various information sources. Sec-ond, the digital cockpit displays visual, structured,navigational, and real-time big pictures, so that decisionmakers can drill down into the details and consequentlysupports enhanced decision making process using the avail-able information. The digital cockpit uses cutting-edgevisualization technologies that will highlight and analyzecomplex relationships, patterns, and trends.

More explicitly, the objectives of this paper may be clas-sified as the following:

• Identify different information and service sources of theorganization and the underlying databases, data models,formats, and protocols.

• Explore the dependencies and relationships betweenthese information sources.

• Integrate all these sources of information in order toensure a real-time availability of updated, consolidated,structured, and unified data across the networks.

• Understand the security requirements.• Elaborate a platform that will present the synthesized

information in a dynamic and real-time visual objectwith the ability to drilling down the information details.

• Finally, illustrate an implementation of a suite of servic-es and tools that allow analytical processing and optimi-zation techniques (statistical analysis, graphicaltechniques, simulation of what-if scenarios, trend analy-sis, comparative analysis, etc.) on the gathered data todisclose the enormous potential of the information sys-tems integration.

The rest of the paper is structured as follows: in Section2, we present the related work and discuss the scopes andlimitations briefly. In Section 3, we describe the proposedarchitecture in details. Section 4 outlines the securityrequirements and the proposed solution. In Section 5, wedetail the adopted methodology for the implementationof digital cockpit model. Section 6 contains the conclusionand possible future work.

2. Related work

Middleware-based information integration has been mas-sively empowered by the large-cap corporations in the lastfew years to suffice their business need for information and

A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265 257

service sharing. This section focuses on the contributions ofthe previous researches on data and service integration andmessage oriented middleware. It also includes a brief elabo-ration on business intelligence and visualization techniques,used to transform data into useful patterns. These techniquesare related to the decision making process, and they signifi-cantly impact our decision support system.

2.1. Data integration

Data integration approaches work on a set of decentral-ized data, develop a single unified schema and allow a ser-ies of transformation or source mapping to describe therelationships among each data source and mediated sche-mas. It can be achieved in different ways: Data Warehous-ing (Materialized Views), Custom Integration code (InHouse Development), and Federated Architecture (VirtualViews).

The warehousing solution requires the building of aphysical centralized database – a subject-oriented, integrat-ed, non-volatile collection of data in a single database –and writing programs to load the data from the data sourc-es to the warehouse periodically via ETL (Extract, Trans-form, and Load) tools. This approach is relevant whendata does not change frequently or when the integratedview does not need to be up-to-date. Hence, the full con-tents of the global schema are pre-computed and storedin a separate database. However, using ETL tools, refresh-ing the warehouse is typically expensive and generally doneoff-line.

The custom integration approach or ‘‘in-house’’ devel-opment – chosen at the beginning of the integration pro-cess – seemed to be an interesting and economicaloption, but gradually becomes a heavy-burden for manyreasons such as: not well-documented or not documentedat all; does not take care about the scalability of the sys-tem since it was done to fix temporary problems, etc.

Fig. 1. Data integration: Federa

Thus, this solution itself turns into another legacyapplication.

The other approach for data integration is the federat-ed architecture. This approach defines one or more med-iated schemas, which enquires the data-sources, howeverkeeps their local autonomy and creates a virtual reposi-tory enabling real-time on-demand data access. Thisapproach is well suited and almost inevitable in largemodern enterprises. In fact, the different parts of theorganization use different systems to produce, process,store, and search their critical data. Yet, it is only bycombining the information from these various systemsthat the enterprise can realize the full value of the datait contains [7]. Moreover, the federated architecture fitswell when the global schema changes frequently, whichis a real need to make educated decisions based on up-to-date information. Fig. 1 illustrates the federated archi-tecture approach.

Initial implementations of these approaches are mostlysuffering from high-level vendor lock-in, inextensibilityand other dependencies. Afterwards, the standard JavaAPIs came as Java Database Connectivity (JDBC) [9] thatallows connection to relational databases. Once the con-nection is established, the fetched data are sent to theirrequestor via a communication protocol in a tightly cou-pled and synchronous environment. In the next step, theasynchronous communication was addressed with therelease of Java Message Service (JMS) [7], enabling looselycoupled and reliable communication. However, IT commu-nity continued the research to integrate the legacy systems.A survey shows that 50% of the software market expendi-ture goes to integrate legacy applications, and 80% ofworldwide data is stored in mainframes [12]. Finally,J2EE Connector Architecture API (JCA) is released recent-ly as an open standard solution to access almost all thestandard Enterprise Information Systems (including legacysystems) but still in a tightly coupled synchronous/asyn-chronous way.

ted Architecture Approach.

258 A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265

2.2. Service integration

Retrieval of information is not enough to design a com-plete decision support solution in the absence of servicesharing.

Initially, technologies like electronic data interchange(EDI) [11] have been used for many years to successfullyperform business transactions between partners [4]. EDIrelies on formatted messages (based on defined stan-dards) and proprietary network protocols for data trans-port. Companies have been reluctant to invest in thesetechnologies, because of the large underlying investmentsthat are required in terms of software, hardware, andconsultancy [4]. Afterwards, with the advancement intelecommunications and due to high organizational con-cern of computing industries, in the early 90s; manyinitiatives have been introduced to facilitate the commu-nication between application components in a distributedcomputing environment. Common Object RequestBroker Architecture (CORBA) [10] from Object Manage-ment Group (OMG), Distributed Component ObjectModel (DCOM) [2] from Microsoft and Remote MethodInvocation (RMI) from IBM and SUN Microsystems areexamples of these initiatives. All these technologiesallowed organizations to integrate applications in a dis-tributed infrastructure using RPC-based mechanisms tobind application clients to a server [4]. However, interop-erability between these RPC-based mechanisms is stillcomplex and limited. For instance, CORBA and DCOMcan not communicate easily and may need a bridge toallow such a communication. This limitation is due tothe fact that each infrastructure uses its own communica-tion protocol (IIOP for CORBA, ORPC for DCOM,and JRMP for RMI). In addition, within thesetechnologies, the application is statically bound to a sin-gle address and tightly coupled with request/responsemode [6].

Finally, with the emergence of XML (Extensible Mark-up Language) as a cross-platform, extensible, and text-based standard language for representing data [11], the ser-vice integration is leaned to the Service Oriented Architec-ture (SOA). Hence, the concept of web services wasintroduced first by HP in its product e-Speak, in 1999 [8].Shortly afterwards, many competing frameworks and pro-posals for web services were provided such as Microsoft.Net, IBM webspheres and SUN’s J2EE web services.The SOA vision is based on a four-layered architecturenamely, (a) object-based application-level communicationprotocol, (b) description of web services, (c) discovery ofweb services and (d) execution of web services. The releaseof Extensible Markup Language (XML) based schema rep-resentation eased the language of web services and conse-quently the standard technologies were mostly definedwith the similar formats in the last five years. Simple ObjectAccess Protocol (SOAP) for web services protocol, WebServices Description language (WSDL) for service descrip-tion, Universal Description, Discovery, and Integration

(UDDI) and Electronic Business Extended Markup Lan-guage (ebXML) for service discovery, and finally BusinessProcess Execution Language for Web Services (BPEL4WS)in service execution have been proved as standard technol-ogies to implement the notion.

2.3. Real-time data processing

Analysis and visualization of the integrated data areinseparable parts of the integration middleware. Nowadaysthey are quite sophisticated than the so-called data analysis(as done in MsExcel) and user-interfaces. Industrialresearch on business intelligence (BI) based analysis isintensely motivated by the Online-Analytical Processing(OLAP) technologies and its different variations, such as:MOLAP (Multi-dimensional OLAP) and ROLAP (Rela-tional OLAP). The role of the OLAP tools is to analyze,report and show trends and to generate relevant informa-tion that may be directly used to the decision-making pro-cesses. Using BI tools like OLAP, very complex analysisand synthesis capabilities can be incorporated that clearlyoutweigh traditional queries and generation of reports.Visualization, on the other hand, is favored by lot of com-mercially available APIs (e.g. EspressChart from Quad-base) that eases the deployment with applets, servlets,JSPs, and Java applications. However, the middlewarerequires a new dimension of web-based display technolo-gies that must be activated with and without user-interven-tion and should view graphical representation of freshinformation as it is better understandable than tedious tab-ular display of piles of data.

3. Architecture

The present world of information technology is runningon a multi-tier architecture that fills the desideratumbetween the users and the sources of information and ser-vices. The choice of a proper middleware among them willsignificantly speed up the retrieval of data and/or services,reduce integration complexity and increase the perfor-mance as well. Architecturally, the proposed middlewarerepresents a distributed structure on the top of existing cli-ent–server architectures as available within intra-depart-mental networks.

This middleware model abstracts the information sourc-es and helps the user to get information without caringabout their locations. Since the solution is assumed toaddress the data that changes frequently with time, themodel is designed on federated architecture which is capa-ble to retrieve present values of data substantially reducesthe integration complexity. Second, the model takes careof automatic notification to the dependent representationof the same information in local or remote client machines.Actually, we leverage a Message Oriented Middleware(MOM) that allows the following capabilities:

A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265 259

• Autonomy of information: The model has the ability topublish information as per user’s wish within a particu-lar domain. Two organizations may communicatethrough messages that are loosely coupled with theirown domain of environments and share information asper their permissions previously agreed between them.

• Real-time sharing of information: MOM architectureallows real-time display of the changing information,one of the most important objectives of organizations.

• Performance: The reliability of the message communica-tion is high and the architecture supports asynchronouscommunication. Therefore it does not stall the processesat the user-end.

• Scalability: The model supports easy incorporation ordeduction of an organization into the infrastructureand removes the necessity of tedious mapping of all itsinformation sources using tightly coupled technologies.

• Security: MOM allows the security modules to beimposed more freely than the RPC-based communica-tion models. It allows the privacy of the message as wellas supports the data encryption and certificates mecha-nisms for secured communication.

Fig. 2 shows our layer-based integration approach. Itconsists of four principle layers: resource, integration,acceleration, and presentation tiers. The resource tier –the lowest layer – is responsible for the persistent storageof data, and holds multiple heterogeneous sources of infor-mation such as relational databases, spreadsheets and leg-acy applications. The integration tier is responsible forapplication servers that provide adapters for informationsources. For example, in case of J2EE technology, thisincludes JDBC and JCA. The MOM has the main role inthis layer, it receives data provided by the integration tierand pushes them to the acceleration layer. This accelera-

Fig. 2. Layer-based Int

tion layer is associated to each client of the system and con-tains a receiver of information, called ‘subscriber’. Thesubscriber integrated information inside the client’s sideas per user’s choice. It relies on a purely message-based sys-tem and confers this information to the presentation layerafter processing, if needed. This last layer consists of a setof web-based components that is responsible for the dis-play of structured, graphical and navigational representa-tion of the information fetched by the other tiers.

Finally, Fig. 3 depicts the architecture of the middlewarefor integrating the data sources. Here, we have mentionedsome relevant technologies that support our architecture.The model illustrates the communication between twodepartments having clients and databases local to theirenvironments. Initially the architecture allows a client toretrieve information locally or remotely according to his/her privileges. The model includes an integrator componentto facilitate the fetching of data. We propose a semblanceof message-based point-to-point asynchronous inter-orga-nizational communication as supported by Java MessageService (JMS) and a tightly coupled retrieval of informa-tion inside the department using JDBC and/or JCA tech-nologies for the purpose of retrieval of local information.In the beginning client system requires huge amount ofdata to start a component. The infrastructure provides adirect peer-to-peer communication mechanism (e.g. JMS-Queue) between the requested client and related server/s.Once the client system starts displaying the retrieved infor-mation, it only requires to gather real-time notification ofchanges. With the update of data, once again, integratorwill automatically trigger a publisher module to publishinformation in a common namespace named ‘‘topic’’, aJMS publish-subscribe component. On the other hand,the client-end software solution invokes a listening processin the background and listens to the changes published in

egration Approach.

Fig. 3. Architecture of data integration.

Fig. 4. Four phases of web services.

260 A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265

the required topic. As the changes are found, they receivethe information as a message and update the visualizationof the information in client’s side.

The performance is expected to be high as the networkdeals only with the change of an information. The follow-ing formal equation clearly prove the superiority of mes-sage-based middleware over the tightly coupled RPCapplications.

Suppose an application has N threads and r requests onaverage to the resource tier. If each request takes t secondsto complete and the pre-request works of threads require w

seconds then an RPC-based application manages N simul-taneous threads on average (r Æ t + w) seconds for each ofthem. So, the time taken by the system to serve R requestsis:

time ¼ ððR div NÞ þ 1Þ � ðr � t þ wÞ;

where div is the integer division without remainder.For message-based middleware, as proposed here, each

thread can simultaneously send multiple requests and waitsfor the later tier by the amount of time [1]:

d ¼Maxrk¼1ðtkÞ

Since the time thread is simultaneously servicing differentrequests while it is waiting for other tiers, we assume thata single thread is servicing c (c P 1) simultaneous requests,and the time required to serve the same R requests will be[1]

time ¼ ðR div c� NÞ � d

The result clearly shows that message-oriented middlewaretakes less time than the so-called RPC-based data integra-tion mechanisms.

Data integration alone does not offer a complete systemas the data always require a service to be processed in a

meaningful way. Use of remote services via intranet/inter-net is vital as the user often requires lightweight services tosynthesize data while the services are not available locallyto his/her computer. However service integration infra-structure is typically complex in the global architecturalpoint of view. The Fig. 4 intends to highlight the phasesof web-service integration.

Here we describe the service integration with the avail-able APIs before establishing our proposed architecture.Every web-service requires a complete description of itsobjects and functions. The intention here is to define com-mon data-interchange formats for each of the needed trans-action. This may be achieved by the use of Web Service

Fig. 5. Proposed architecture of service integration.

A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265 261

Description Language (WSDL). Actually, WSDL is themost promising language and the emerging standard. Asof the technical logistics for WSDL, we used Axis APIfrom the Apache foundation [5].

Concerning the discovery of services, the most populartechnology is to adopt a registry/repository mechanismfor allowing the dynamic discovery of the set of availableservices. Once a service is registered, i.e. added to the reg-istry, the other departmental clients may access that servicein a remote server provided that their requests must matchwith all the conditions stated in the provider’s servicedescription. Dealing with different registries requires acommon interface as provided by the Java API for XMLRegistries (JAXR API) for the java implementations. ThisAPI is an open-standard provided by Java CommunityProcess (JCP), and supports both of the standard registryrepository systems: UDDI and ebXML (Electronic Busi-ness Extensible Markup Language). However, WSDL isa stateless language and therefore it is not able to capturethe execution of business processes. IBM and Microsoftjointly proposed BPEL4WS while Sun released WSCI,two different languages in order to model the process exe-cution while the service is described before in WSDL syn-taxes. As of the service protocols, the proven W3C openstandard is Simple Object Access Protocol (SOAP) [3].SOAP is essential to carry out the XML-request and theservice description from one location to another. As we dis-cussed before the AXIS API supports SOAP messagingover different communication protocols (e.g. HTTP/S)

and messaging services (e.g. JMS). Fig. 5 depicts a generalarchitecture of the service integration, as proposed.

4. Security

As the proposed Message-Oriented Middleware (MOM)seamlessly allows connecting applications and sharinginformation, on the other hand, it raises critical securityissues that must be taken care to conform a secured andtrustable architecture. Actually, the necessity of the distrib-uted nature for information integration complicates thesolution of the security requirements more than the so-called certificate-based secured software system. This sec-tion leverages a detailed discussion on the security require-ments of such a loosely coupled middleware and an idea ofpossible solutions.

First of all, this architecture requires to keep the localautonomy of the information and users of the systemshould be bound to the organizational scope. More precise-ly, each department in the architecture has its own usersand sources of information maintained by it. This idea isdirectly inherited from the generic business model of anyorganization. However, it suffers to identify an authenticuser outside the scope of own department/organizationbut within the system. The available security infrastruc-tures work well within the scope of an institution in orderto identify a local user but unable to recognize a permitteduser from other organization due to the lack of informationstructure. The research establishes a need of predefined

262 A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265

handshaking between two organizations in terms of certifi-cation policy and public/private key pair that allows iden-tification of one institution to another and thereby scopesto identify the inter-organizational users.

The implementation of such multi-tier end-to-end infor-mation integration must be capable for keeping the sharingof data secured among the set of right privileged users. Wehave implemented this idea through a role-based accesscontrol system on the top of this architecture. Each ofthe client terminals should be provided a list of permittedcomponents he/she can view. This list should be generateddepending on the role of the users to the system and anychange (addition of new components) of this access-controllist always requires the intervention of the local server thatassigns and keeps the list in its local storage for securitypurposes.

The secrecy of information is one of the main perspec-tives from the security viewpoint. This architecture sup-ports publishing the information in the name-space (e.g.JMS Topic) local to the departmental server. Therefore,it allows the department to enforce stronger security mech-anisms over the ‘topic’, the namespace for publishing infor-mation. It is, of course, a better approach than publishingremotely outside the scope of the department. Although,the details of these security mechanisms are out of thescope of this paper however the proposed architecture sup-ports all kinds of authentication, authorization techniqueson this name space in order to share the information onlyamong the permitted users. Even the information may alsobe classified to be accessible to certain group/s of users,while the others cannot even read from the ‘topic’.

All the events and activities related to the architecture(for example: sending information to an external client)within the department must be logged for future traceabil-ity. Certain activities often have serious impact on theorganization, however cannot be identified later if nottracked. In the implementation of the system, we have suc-cessfully developed a database dedicated to track thesestrategic moves that keeps the track of user events.

Finally, we claim that our architecture supports robustsecurity infrastructure on the top of a distributed environ-ment. It allows users to send and receive real time view ofinformation as per his/her credentials in the integratedarchitecture. Moreover the distributed nature of the archi-tecture reduces the possibility of denial of services attack,therefore increases the availability of the system. We dealtthe security at the level of messaging services, therefore didnot explore the sockets, and tunnelling through the fire-walls. In the implementation, proper choice of messagingservices and the communication protocols will take careof the communication of messages in the inter-organiza-tional Business-to-Business Integration (B2Bi) level.

5. Implementation

This section focuses on the high level design of a project,called ‘‘Digital Cockpit’’, that realizes a significant part of

the aforementioned architectures. The project is fully fund-ed by the Defence Research and Development, Canada.Actually the digital cockpit project accomplishes an effi-cient and useful decision support system mainly based onthe information and service integration. In this discussion,we also intend to establish the huge potential lies in thefusion of the two explicit research areas: information inte-gration and decision support system. The underlyingdesign and implementation phases of the developed mid-dleware are summarized below.

• Integration: to connect all the information and servicesources within and across the organization, for an infor-mation sharing purpose.

• Display: to take the data from different sources, aggre-gate them and present the synthesized information intoa meaningful, structured and big navigational ‘‘picture’’that offers the ability to drill down into the details.

• Monitor: to design and implement the capabilities thatallow the active monitoring of the information systemstate for the purpose of testing the organization’sassumptions, reactive and proactive measures, andresponse to dashboard thresholds, etc.

• Analyze: to bring the system to the business intelligencelevel, i.e. to design and implement the capabilities forpattern and trend analysis, simulation of ‘‘what-if’’ sce-narios, etc.

• Control: to optimize procedures, events, and scenariosthat will enhance the used processes, methods, andstrategies.

Security is not an exact phase of this paradigm, howeverconsidered as a vital quality attribute that must be takencare of at each phase of this paradigm. Fig. 6 depicts theideology more clearly.

The integrator is in charge of gathering the requiredinformation by interacting with the different data sourcesas required by the user. It retrieves from the local sourcesdirectly as well as uses Java messaging technology in thecase of remote sources. There is a subscriber module, pro-posed at the client’s end that is used to express interest inthe needed information and therefore open a new connec-tion depending on user privileges. Using JMS point topoint subscription mechanism, the subscriber is also ableto provide the end-user with the capability of subscribingto the information of interest directly from the remote datasources. On the other hand, if the digital cockpit clientupdates any information in the data sources, the integratorinterface associated to the sources on server side will triggera publish mechanism that uses a common JMS topic topublish the necessary changes as mentioned in Fig. 2.When such information is produced in the topic the mes-saging service notifies the relevant subscribers and suppliesfresh information to them. The monitor module is in char-ge of tracking the organization’s assumptions with thischange of information and responds actively to dashboardthresholds without any direct user-intervention. The client

Integration Display Monitoring Analysis Control

Security

Security

Fig. 6. Digital cockpit 5-phases paradigm.

A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265 263

module also contains some local services to analyze andoptimize the different scenarios comprised with the aggre-gated data. The analyzer module is responsible for per-forming the needed simulation, pattern and trendanalysis, while the controller is the module that optimizesthe different scenarios and processes as required by theuser. Finally at the user-end, the display manager takescare of the graphical layout and the production of struc-tured and navigational ‘‘big picture’’ of the system. Fromthe experience we understood that the client modulerequires a consolidated security foundation in order to bedeployed commercially. We implemented a security man-ager module that enforces the required security propertiessuch as authentication, authorization, secrecy, integrity,non-repudiation, and availability. The architecture of adigital cockpit client is made of the following modules:the integrator, the subscriber, the display manager, themonitor, the analyzer, the controller, and the securitymanager.

The issue of the service integration is lately added as anextended capability in this project. We extend the integra-tor module that uses ‘‘hook’’ to connect the light-weightservices situated in the remote servers. With the limitedscope of the project we exclude the idea of implementinga general registry to register web services and call the ser-vice directly using JMS on top of http/https communica-tion protocol. As mentioned before, AXIS is usedthrough out the implementation. This API successfullybinds the user request with the services defined in WSDL.However, for the global architecture of service integration,the use of a registry is inevitable as the location services aremostly unknown.

In what follows, we explain, the underlying design andimplementation in different phases of the digital cockpitto explain the implementation strategies briefly. However,the detailed description of the digital cockpit is beyondthe scope of this paper.

5.1. Integration

Integration of information systems is the key issue fordesigning the digital cockpit prototype. We defined inter-faces and communication protocols of this message-basedmiddleware in three phases: data integration, service inte-gration, and messaging service.

Data integration is related with the retrieval of datafrom the structured, semi-structured, or unstructuredsources of information inside and outside the organization.

Moreover, they are heterogeneous in term of data storage,query procedures, operating systems, and the type of net-work. We used two free Java APIs: Java database connec-tivity (JDBC) and the J2EE Connector Architecture (JCA)Java APIs for the querying of information sources. Actual-ly, JDBC is the de facto API, used in accessing relationaldatabases. JCA is suggested mainly to access legacy sys-tems (e.g. mainframes), unstructured (e.g. flat files), orsemi-structured (e.g. web pages) information sources. Therationale behind this recommendation is that JDBC hasshown its merits in terms of performance, convenienceand ease of use. As of JCA, it is the API of choice sinceit allows accessing legacy systems. Besides, JCA caters foran asynchronous mode of fetching information and astrong pooling mechanism that significantly improves sca-lability. On the other hand, using XML documents, weare in a position to have multiple views on synthesizedand/or aggregated data.

The digital cockpit platform is endowed with the capa-bilities that cater for web-based service integration. Asper the need, we implemented the design using Axis APIfrom the Apache foundation [5]. Axis receives SOAPrequest, and binds the respected service if there is a matchbetween the request and the WSDL description of the ser-vice itself.

As of the messaging service, we implement the idea withJava Message Service (JMS) API [7]. JMS is the messagingstandard in Java for the asynchronous information sharingas required for the architecture of digital cockpits. Again,the choice of JMS is also motivated by: cost-effectiveness(freely available API from JCP); Standard (Java Specifica-tion Request 914); Reliability (guaranteed delivery); Per-formance (outperforms other communication solutionssuch as RMI and RPC).

5.2. Display

As mentioned before, display of digital cockpit is moresophisticated and complex than a classical, conventionaland static graphical user interface (GUI) as it collects thefrequent changes of information and notifies the user inalmost real-time. The display of such synthesized informa-tion is also required to be performed in a meaningful struc-tured, navigational, and graphical way. We incorporateddynamic graphical objects and representations such ascharts, curves, knobs, histograms, reports, animated maps,etc. The user can also customize the display according tohis privileges: adding/removing (a) component(s), changing

264 A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265

its properties, etc. Furthermore, the display screens providethe user with some utilities that operate on screen elementssuch as: saving, zooming, navigating, etc. We used Espress-Chart API from Quadbase Inc.

5.3. Monitoring

This phase reflects the active monitoring of the variousorganizational system state. It allows the testing of theorganization assumptions, proactive and reactive mea-sures, and responses to the cockpit thresholds. We intro-duced java listeners as well as suitable APIs according tothe nature of the action or reaction. For example, JavaMail API was used for sending e-mails.

5.4. Analysis

The main intent of this phase is to design and implementa suite of procedures that will endow the digital cockpit cli-ent with analytical capabilities like pattern identification,simulation of what-if scenarios, trend analysis, probabilis-tic and statistical analysis, cause-effect analysis, etc. Actual-ly, such capabilities will bring the digital cockpit to thebusiness intelligence level. Implementation of the analyticalcapabilities is done using various Online Analytical Pro-cessing (OLAP) tools.

5.5. Control

This phase offers optimization of business processes,methods, strategies, and scenarios to the digital cockpit,

Fig. 7. Display/monitoring: d

that increase the productivity of decision makers by intro-ducing automated decisions for the organizations. Optimi-zation problems are known to be hard. Generally, somekey techniques-like stochastic processes with techniques-like operation-research and game-theory are used for pre-cise decision making.

5.6. Security

The digital cockpit model requires mechanisms toenforce security properties such as authentication (provingidentities of the cockpit users), secrecy (not leaking sensi-tive information to inappropriate users), integrity (prevent-ing data from corruption and alteration), non-repudiation(preventing users from denying their execution of cockpitoperations), and authorization (giving only authorizedusers the right to access information and to executeservices).

We wish to deploy the required technologies in thedigital cockpit according to the required security level.We implemented a security infrastructure using the JSSE(Java Secure Socket Extension) API with X509 certifi-cates. As of non-repudiation, it can be enforced by hav-ing adequate audit and logging mechanisms. The Javalogging API seems to be appropriate for this need.However, the logs themselves need to be protected.Concerning integrity, we adopted encryption and hash-ing in order to detect any illegal modification of sensi-tive data. Authorization could be implemented byusing JAAS (Java Authentication and AuthorizationServices) API.

igital cockpit prototype.

A. Benssam et al. / Knowledge-Based Systems 20 (2007) 255–265 265

Within the scope of that prototype, we integrated theinformation from a few number of remote informationsources (parts of other digital cockpits) into the digitalcockpit model running on the top of J2EE applicationserver. Fig. 7 shows an user-interface of theimplementation.

6. Conclusion

This paper presents a middleware architecture for a net-centric information system decision support environment.The proposed design includes an infrastructure of web ser-vices and provides capabilities for data/information/serviceintegration, visualization, monitoring, analysis, and con-trol. Multi-layer solution and implementation have beendescribed in details. Accordingly, information sourcesdependencies, relationships and integration are explained,security issues are briefly discussed, and finally servicesand tools to exploit data and information and perform avariety of analysis are depicted.

Future work will address applications for targeted mili-tary problem domains. It will consist in first achievingdata/information integration and then provide some visu-alization (asset visibility), monitoring and analysis capabil-ities through application (including legacy) integration andweb services composition. Suitable solution will be devel-oped and explored to meet challenges posed by servicecomposition and system performance limitations. Anassessment on the value of net-centricity on performance

for planning tasks will also be carried out for selected mil-itary domains.

References

[1] Blumenfeld Brian Maso and Inc., Maso, Jms: a solution in search of aproblem? http://archive.devx.com/java/free/articles/MasoJMS02/Maso02-5.asp, February 2005.

[2] C. Davis, Distributed objects and components, UCL ComputerScience, UK, http://www.cs.ucl.ac.uk/staff/W.Emmerich/lectures/3C05-02-03/aswe19-essay.pdf, May 2003.

[3] World Wide Web Consortium, Simple object access protocol(soap)1.2, http://www.w3.org/TR/soap, 2003.

[4] E. Cerami, Essentials of Web Services, O’Reilly publications, 2002.[5] Appache Foundation, Web services-axis documentation, http://

ws.apache.org/axis/, 2003.[6] David S. Linthicum, Next Generation for Application Integration:

From Simple Information to Web Services, Addison Wesley publi-cations, Reading, MA, 2003.

[7] SUN Microsystems, Java message service specification [jsr 914],http://java.sun.com/products/jms/docs.html, 2000.

[8] Judith M. Myerson, Web service architectures, Technical report, Tect,http://www.webservicesarchitect.com/content/articles/webservicesar-chitectures.pdf, 2002.

[9] Java Community Process, Java database connectivity 3.0 specification[jsr 054], http://jcp.org/en/jsr/detail?id=54, 2002.

[10] S. Vinoski, Corba: integrating diverse applications within distributedheterogeneous environments, IEEE Communication Magazine 35 (2)(1997), http://www.cs.wustl.edu/schmidt/PDF/vinoski.pdf.

[11] Inc, The Sports Authority, Electronic data interchange, http://www.sportmart.com/corp/pdf/Chapter2VRGJuly2004.pdf, 2004.

[12] Jack McCarthy. Special report: Six great myths of it. (33) (2004) 35.http://www.infoworld.com/pdf/special_report/2004/33SRmyths.pdf.