| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |
Cherinka, Robert D.
Ph.D. , MITRE Corporation , 1 Enterprise Parkway, Suite 100, Hampton Virginia U.S.A.
Email: rdc@mitre.org
Dr. Robert Cherinka is a Lead Information Systems Engineer for the MITRE Corporation, located in Hampton, Virginia. His expertise is in software and process engineering technology. Prior to joining MITRE in 1993, he was an Officer performing software engineering duties in the United States Air Force at the Air Combat Command Computer Support Squadron, Langley Air Force Base, Hampton, Virginia.
Miller, Robert W.
Ph.D. , MITRE Corporation , 1 Enterprise Parkway, Suite 100, Hampton Virginia U.S.A.
Email: drbob@mitre.org
Dr. Robert Miller is the Information Interoperability Project Leader for the MITRE Corporation in Hampton, Virginia. His expertise is in Information Management having worked extensively in the area of information exchange among Joint and Coalition military systems. Dr. Miller participated in the Air Force Scientific Advisory Board's study on the implementation of the Joint Battlespace Infosphere. Prior to joining MITRE in 1983, he was Associate Professor of Mathematics and Computer Science at the College of William and Mary, Williamsburg, Virginia.
Digital information is rapidly becoming integrated into all aspects of military activities, and this presentation highlights work being done for the US Department of Defense. The fundamental requirement addressed by the Joint Battlespace Infosphere (JBI), extracted from the 1998 Scientific Advisory Board report, is "To provide the right information at the right time, disseminated and displayed in the right way, so that decision makers can do the right things at the right time in the right way." The concept of building and interconnecting systems around the information that they manage and exchange (i.e., "information-centric") is a vision for the future of the JBI. There is much more information that can be fed around the systems today than a decision-maker can assimilate. As a result, there is a need for technologies to sort out the "right information" from the "nice to have" and the "irrelevant" information. This new technology will characterize systems (and all participants) as both consumers (subscribers) and publishers of information. Between the publisher and subscriber lies a broker (similar in concept to a search engine), which can recognize the subscribers true needs and make the appropriate connections manipulate and transfer published information. JBI-enabling a system allows it to communicate with the JBI and build XML information objects. A brokering capability would permit systems to find and communicate with each other adaptively, by providing Web Services to enable systems to describe themselves and UDDI to facilitate automating the connections among them. Operationally, this means that if a participating system had need of a service (e.g., weather or position information) and its normal source for that service was made unavailable, it could automatically search for and connect to an alternative provider of the service. MITRE is prototyping the application of these technologies to a military-specific set of problems to explore how this commercial technology can be used to improve interoperability among military systems. This paper presents a brief introduction into how MITRE is helping the DoD prototype the JBI vision through the use of the commercial web services model and points out some lessons learned in using this approach.
Digital information rapidly is becoming integrated into all aspects of military activities. As a result, operations are becoming increasingly fast-paced and diverse as the management of information moves closer to the center of military power. To provide commanders with the knowledge required to make decisions in this environment, a greatly enhanced C2 concept for information gathering, dissemination and visualization is needed, based on revolutionary new information-age concepts and technologies.
The Joint Battlespace Infosphere (JBI), as described in the December 1998 Scientific Advisory Board (SAB) report Information Management for the Warrior [1], has been proposed as a vehicle for realizing this goal. The fundamental requirement addressed by the JBI, extracted from the 1998 SAB report, is "To provide the right information at the right time, disseminated and displayed in the right way, so that commanders (and "crew warfighters") can do the right things at the right time in the right way." Included, as an objective is to do this "faster than the other guy", thereby ensuring information superiority. Underlying this basic goal the JBI will provide a mission commander, at any level, with the ability to enforce his/her operational intentions via a set of actionable information policies. In addition, the JBI must allow for innovation and rapid acquisition of new mission web services as well as the optimization of all IT resources used in the process of collection, transformation, and delivery of standardized collections of information, called information objects. The presentation of information and end user interaction tools with such information objects are still the responsibility of end user application developers.
The JBI technical architecture is modeled after the World Wide Web (WWW), the primary information capability residing on the Internet. In other words, the JBI would establish an easy-to-use, globally available, virtual C2 information environment. The JBI functions as an information "supermarket" that provides one stop information shopping by consumers and a one-stop information outlet for producers. The goods and services available for exchange are all information-based products. While the JBI may appear to users as one virtual information space, the JBI is a distributed capability. The information products available through the JBI may actually reside on an infrastructure of connected information servers located wherever necessary.
The JBI also is a knowledge management capability. That is, it supports the warfighter with the means to find and retrieve information, to combine and manipulate it, and thus to leverage its use (i.e., create knowledge) for the decision making process. For a variety of reasons (e.g., speed, cost, repetitiveness) portions of this process can be automated via intelligent agents, also called "fuselets." Another important aspect of the JBI as a knowledge management device is the human's "visualization" of information in the JBI, referred to as an "operational picture."
This paper presents a brief introduction into how MITRE is helping the US Department of Defense adopt the use of the commercial web services model to improve interoperability among military systems and points out lessons learned in using this approach.
Most previous attempts to "manage" information have been task or system-based. That is, developers made decisions about how to define, organize, manipulate, store and transport information based on what was optimal for the system under development. What generally results is termed a "stovepipe" system: one that is unable to interoperate (share and use information as intended) effectively with other systems. The real economic result here is increased costs through the inability of systems to work together.
Communities now are recognizing that, for systems to work together effectively, an "information-centric" approach is needed. This approach allows the construction of a loosely coupled network of systems and services that support a wide variety of information producers and consumers. Interoperability is enhanced through the use of common information objects, such as military message text formats (MTFs), and mechanisms for their interpretation and understanding. In addition, systems need to be "adaptable," in that they should be able to accept input from older object definitions. It is important to recognize this necessity, as "legacy" systems will still need to share information with more state-of-the-art ones.
The information-centric approach emphasizes information objects and middle tier services. This middle tier represents a capability that brings together all of the information necessary to support information consumers and their missions. To make another analogy, this layer functions as an "information supermarket" or "infomart" [2]. Although essentially distributed, the infomart provides one-stop information shopping for consumers and a one-stop information outlet for producers. The goods and services available for exchange are all information-based products.
The infomart is distinct in its organization, process, and usage from the communications infrastructure on which it rides and from the user application systems that it serves. It is a place where information is brought together under coordinated management, independent of the management of communications and systems. The infomart must rely on an underlying transport network - the infrastructure through which information is stored and transported. This distributed infrastructure includes telecommunication networks, servers, routers and the like. The purpose of the infomart is to provide a virtual, centralized market for the exchange of information and service commodities by application systems. These systems include both producers and consumers of these information commodities, some of which do both functions simultaneously.
The infomart should supply certain core information-oriented services through its operation. For example, it should contain or support processing functions to allow for storage, access, retrieval, fusion, and management of information. This is similar to a food supermarket that supplies rows of foodstuffs on shelves (storage and indexing) for easy shopping (access and retrieval) as well as delicatessen services to repackage (filtering and fusing) luncheon meats and cheeses.
The commodities and services of the infomart are based on commonly used information units called information objects. While there is standardization in such an approach, it does not imply that there is only one kind of information object for a particular function, just as we would not expect to find only one kind of soup at the supermarket. Information objects are based on the needs of decision makers in various functional domains. Core services (for example, query) and technologies (for example, schemas) are provided to allow application systems to interpret the meaning of these objects and effectively use them. An underlying theme of this vision is the exploitation of emergent web-based commercial off-the-shelf (COTS) technology and tools, (such as those mentioned below in the commercial alternatives section), to provide many of these core services, with the accompanying benefits of reduced costs and scalability.
Fundamental to the success of the infomart mission is a universal method for information producers and consumers to share information commodities. Information producers place their information products into the infomart by "publishing" while information consumers receive information products available through the infomart by "subscribing". (Consumers also can receive information products through "query" discussed below.) In general, publishing and subscribing occur through (standardized) information objects rendered via a common representation. Information producers must be capable of providing their information products via the common representation and information consumers must be capable of reading such standardized products. Thus producers and consumers must have an interface in order to be able to use the infomart and its services.
Commercial technologies and tools are now becoming available that address these issues. These are actually cheaper than requiring each consumer to devise his or her own interface to each producer's information format. Of course, producers (in particular) and consumers are free to continue to use their proprietary information formats in pre-negotiated, point-to-point information transfers. However, doing so will prevent wider distribution of available information and will not address interoperability concerns.
Information consumers typically find ways to use and combine information which producers never considered. Consequently, information consumers require the capability to locate and extract only the information they require. It must also be possible for consumers to manipulate retrieved information into more meaningful forms, say to match their internal system representation or to combine it with other information. Consumers search for and retrieve precisely the needed information through the infomart's query services. In addition, commercial technologies are now available to assist consumers to reformat and translate retrieved information into a user-specified organization.
Finally, just as a regular supermarket requires a staff to manage and run its operation, the complexity of the infomart requires a trained professional information management staff to keep it operating smoothly. Staff is needed to manage the informational content. The infomart's management staff would address the needs of the user applications that interact with the infomart, solving information related issues such as access privileges, security concerns, information location, information translation, troubleshooting, and so on that may not be handled properly or automatically by its infrastructure.
We define web services as loosely coupled software components that can be accessed using Internet standard technologies. We further define web services as having the following characteristics:
Encapsulated. Encapsulated means the implementation of the function is never seen from the outside
Loosely coupled. Loosely Coupled means a change in the implementation of one function does not require change to the invoking function
Contracted. Contracted means there are publicly available descriptions of the functions behavior, how to bind to the function, it's input and output parameters
Based on standard protocols. Standard protocols are open, widely published and freely available for anyone to implement
Web services are transactions initiated automatically by a program, not necessarily by using a browser and can be described, published, discovered, and invoked dynamically in a distributed computing environment. There are many variations of a web services stack that can be found in the literature. We divide our stack into four broad categories: Adapter, Infoservice, Interact, and Infomediate. In turn, we subdivide these into sub-layers for the convenience of highlighting applicable XML technologies. Our web services stack that we have adopted looks as such, starting from the bottom:
Servlets and component technologies. Component technologies are used to provide encapsulated distributed services in a client-server architecture. COM/DCOM, CORBA and Java RMI are the most common object models
eXtensible Markup Language (XML). XML is an international industry standard for describing and sharing structured information
Simple Object Access Protocol (SOAP). SOAP is an XML protocol for web services. SOAP provides a service-oriented architecture for server-to-server and server-to-device communication
Web Services Description Language (WSDL). WSDL is used to describe web services and web service providers
Universal Description, Discovery and Integration (UDDI). UDDI is used for the advertisement, cataloging and integration of web services
Brokering. Brokering is used for the matchmaking of information needs to information service providers
Workflow. Workflow technology is used for the orchestration of collaborative business processes
To help understand the role of each of these standards and technologies with respect to the adoption and use of web services, we examine several "leading questions" concerning the web service model.
The first question is how will loosely coupled software components represent the information they need to exchange (Infoservice)? The answer we have adopted is XML. XML is particularly well suited for web environments and allows the information to be both human readable while able to be processed by a machine. The W3C [3] is attempting to rapidly evolve common specifications for the Web's information space so that organizations from many diverse fields can exploit and build upon it. An area of intense activity is the W3C's work on XML, which began in 1996. Designed to meet the challenges of large-scale electronic publishing, XML is playing an increasingly important role in the exchange of a wide variety of data on the Web.
XML is a data markup language like HTML [4], using bracketed tags to describe the treatment of the data in the document. With HTML, the tags primarily relate to the formatting and display of the text. With XML, the tag repertoire is extensible; anyone can define a tag to describe some attribute of the text. If applications agree on their use of these extended tag definitions, then they are able to understand the context of the text exchanged between them. The use of XML also implies the use of a family of technologies, such as XSLT, XQuery, SOAP, DOM/SAX, XML Schemas, Namespaces, RDF and WAP/WML to name a few.
How will they share information and services between one another (Interact)? SOAP is used for portable communication between web services. It provides machine-to-machine operations, automatic processing of eBusiness activities, and offers high level, controlled access to the logic inside applications. SOAP is message based and less intrusive than distributed object processing (CORBA, EJB, COM+). It can run in parallel to normal web operations, and can be added incrementally to a solution as necessary.
The cost for implementing SOAP is that "Providers" (information servers) and "Consumers" (client servers or systems) must add one or more SOAP components to their servers or systems. Consumers must integrate the SOAP results into web pages, application logic or RDBMS. SOAP integration makes part of the Consumers' applications dependent on the performance and reliability of the Provider, and the connection to the Provider, and as additional applications integrate "Provider" SOAP based services, the Provider system performance may degrade. However, in our research prototypes, we have seen that this performance hit is relatively small compared to the portability value gained.
How will they describe what information and services they have available (Interact)? WDSL is used to describe web services. WSDL is an XML vocabulary, similar in purpose to the interface definition language for component technology used to describe how to use and configure a web service. A WSDL file describes abstract concepts, such as port types (e.g., shopping basket), operations (e.g., add, remove, list), messages (i.e., inputs, outputs and faults) and data types (i.e., schemas). It also describes concrete bindings, such as data encoding styles (e.g., SOAP encoding), transport protocols (e.g., HTTP, SMTP), and network addresses (e.g., http://myservice.net/cart).
How will they find one another's information and services (Interact)? This will occur through the use of registries. A registry is a storage mechanism that allows owners to submit, classify, register and update business metadata, and also allows consumers (human and applications) to query and retrieve registered metadata in various ways. On a grander scale, a repository represents a location or set of distributed locations where items pointed at by a registry reside, and from which they can be retrieved by conventional (http, ftp) means. We see several types of registries being used in support of web services:
XML Vocabularies. This would store XML elements (tags) and business documents (structure)
Service Advertisements. This would store who provides what service by which technical means
Subscriptions. This would store the expression of consumer information and activity needs
Business Processes Models (Workflows). This would store information that describes document choreography and overall process interfaces
Others Registries for Advanced Functions. There are other potential reasons for storing information in support of activities such as execution status, personalized agents, advanced mediation (policy, security, resources), and semantic mediation
UDDI is currently being looked at as the registry standard for service advertisements and as such has great impact of the web services model. UDDI uses XML, SOAP and other related standards to implement a registry for describing, discovering and integrating web services. UDDI works as follows: 1) SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services, 2) Businesses populate the registry with descriptions of the services they support, 3) The operating registry assigns a programmatically unique identifier to each service and business registration, 4) Marketplaces, search engines, and business apps query the registry to discover services at other companies, and 5) Businesses uses this data to facilitate easier integration with each other over the Web. The information stored in the registry range from high-level business descriptions to detailed service descriptions.
How will users and applications get "matched" with the services they need (Intermediate)? The matching of information needs to services that could satisfy those needs is brokering. There are three types of brokering that we consider are self brokering, mediated brokering and agents.
In self-brokering, an application searches for advertised information services in a registry and executes a direct request to the service. Examples of self-brokering include UDDI with WSDL and SOAP, and ebXML.
In mediated brokering, an application registers information needs (subscriptions). A mediator then matches subscriptions to advertised services and instructs both parties on how to connect. At this point, the broker may monitor and optimise future requests. Examples of mediated brokering include I-Markets matching RFQ to vendors (GE TPN), and the JBI information broker discussed in our research.
Agents represent one step beyond mediated brokering. They directly fulfill subscriber's information needs by acting as the information service. They provide added value through advanced searching, transformations, aggregations, calculations, and the like. Examples of agents include JBI fuselets, FIPA, advanced I-Markets "shopping bots".
How will the loosely coupled software components be coordinated to perform a distributed, yet collaborative process (Intermediate)? Coordination can take place as a result of an executable workflow. A workflow is made up of tasks that follow routes, with checkpoints represented by rules (tasks can be web services). Workflows are typically constructed using commercial workflow tools within a graphical business process-capturing environment. They are then saved in a form, such as XML, which can be executed by some process engine. We consider several types of workflows:
Simple. 2 party, short transaction life, simple exception handling, unmanaged
Complex. multiple parties, long term transactions, brokered, graceful error recovery, managed
Static. predefined to support process automation, may be stored in a registry
There are several emerging standardization efforts for workflow technology. In support of simple workflows, WSDL can be used to capture basic end-point communication. For complex workflows, several competing initiatives are underway, such as BPML, TPA-ML, XLANG, OASIS Business Transaction Protocol (BPT), ebXML (eBTWG), and the Workflow Management Coalition (Wf-XML ).
What is an example of a framework for integrating the various aspects of Web Services? Sponsored by the United Nations body for e-commerce (UN/CEFACT) and Organization for Advancement of Structured Information Standards (OASIS), ebXML provides a coherent XML infrastructure needed for global e-business. ebXML consists a set of open technical specifications that define an interoperable eBusiness framework and represents the potential future evolution of the web service model.
In 1997, the World Wide Web Consortium (W3C) endorsed the eXtensible Markup Language (XML) as a future standard for data interchange. For the first time ever, we have an internet standard for transmitting data along with its interpretation criteria that is platform independent, programming language neutral, both machine and man readable, and is emerging as an industry standard.
The United States Department of Defense (DoD) recognizes the potential XML may have to enhance interoperability and information exchange among Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems. Many initiatives are now underway within the DoD to use XML for this purpose. MITRE, a US government-owned non-for-profit research and development corporation, has been instrumental in helping the DoD realize the potential of this new family of technologies. In particular, this realization is comprised of several key ingredients, including:
XML-MTF: An XML Message Text Format application supporting military information exchange requirements, operational procedures, and terminology across Joint and Allied boundaries
JBI: An enterprise platform implementing commercial web services for publishing, subscribing, transforming and personalizing information objects necessary for information exchange
To address the C2 information interoperability problem, the US and its allies have invested a great deal of time and resources formalizing information standards to reduce the ambiguity of natural language and increase opportunities for automation. One of the most prolific of these standards is the Message Text Format standard, which was begun over 20 years ago. Today, the MTF program governs a significant portion of all structured text information exchanged to support the full spectrum of military operations, including intelligence, air operations, fire support, maritime operations, logistics, medical, etc. It includes an actively managed repository of Information Exchange Requirements (IERs) describing over 600 information products drawing on over 7000 standard data element definitions.
The United States Air Force and MITRE are leading an initiative, called XML-MTF [5], to drastically improve the quality, capability and affordability of MTFs. This initiative promotes the adoption of XML to make MTF information available in a critically important industry standard format. Organizations who share a common terminology typically refer to the collection of common terminology as "vocabularies" when used as common "element" or "tag" names in XML. In this case, the MTFs represent this common vocabulary. The XML-MTF initiative capitalizes on the military's investment in IERs and leverages industry standards to improve our ability to find, retrieve, process and exchange large amounts of information easily across system, organizational and format boundaries (that is, the right information at the right time in the right format). In addition, it enables us to use low cost, high quality, rapidly evolving, mainstream commercial software for processing military information. The following highlights the XML-MTF effort:
The concept of building a system around the information that it manages instead of the processes that manage information (i.e., "information-centric") is a vision for the future of the JBI. There is much more information that can be fed around the systems today than a decision-maker can assimilate. As a result, there is a need for technologies to sort out the "right information" from the "nice to have" and the "irrelevant" information. This new technology will characterize systems (and all participants) as both consumers and publishers of information. Between the publisher and subscriber lies a broker (that is, similar in concept to a search engine), which can recognize the subscribers true needs and make the appropriate connection among the published objects.
JBI-enabling a system allows it to communicate with the JBI information broker and build XML information objects. The brokering capability would permit systems to find and communicate with each other adaptively, by providing Web Services to enable systems to describe themselves and UDDI to facilitate automating the connections among them. Operationally, this means that if a participating system had need of an information service (e.g., weather or position information) and its normal source were made unavailable, it could automatically search for and connect to an alternative provider of the service.
MITRE is currently working on a prototype to construct and demonstrate what may be thought of as an initial phase of JBI capability [6]. The objectives of this project were to define and perform and initial product integration of the minimal core components of a JBI information broker. The broker currently consists of five sub-components: Participant Registry, Publish/Subscribe Management Service (Needs Registry), Matching Complex, Selection Service, and Executor. These five sub-systems or components of a "broker" are the key to making publish/subscribe work in a web-service based architecture. The communication between broker and participant services is done using SOAP and XML-based information objects. In fact, the architecture exploits XML in direct support of common core capabilities, including:
User Personalization Services. These are services to support security, user authentication and user profiles
Publishing Services. These are services to provide upload and publishing of services, information objects and the advertisement of those services
Information Transformation Services. These are services to provide transformation, conversion and subscription processes
Retrieval and Presentation Services. These are services to provide download and service usage processing
It was these main services that were implemented for use in several prototype applications.
One of the more interesting results of this work was the acknowledgement of the potential to allow different "Executor" core service components for different communities. The Executor is the core service that coordinates the behaviors of a set of web services that gather information, manipulate it, and delivery it to the requested end user application(s). It is possible for different communities, with their own deployed brokers, to use different COTS products to implement this execution coordination. This allows the DoD community to select a range of products and change products over time thus allowing more competition within the architecture. By selecting a set of open standards like UDDI and SOAP, the current design represents a highly flexible and adaptable architecture that actually promotes competition and evolution of good ideas. The key was to view the coordination or brokering role as independent from the actual execution of information flows or threads. By logically separating these tasks the brokering process could be independent of the execution of an exchange of information. Thus one community could use a commercial workflow product to actually manage their web services while another could use a CORBA or .NET based approach if they had an existing investment or trained staff in these technologies. In all cases, the overall brokering interfaces would be consistent and allow web service developers to have some commonality across different domains.
The next section will provide some lessons learned in applying the commercial web services model to the JBI prototype.
As mentioned previously, MITRE is prototyping the application of these technologies to a military-specific set of problems to explore how this commercial technology can be used to improve interoperability among military systems. In so doing, we are attempting to raise and address some key issues in doing this, such as interoperability, description and discovery, web services profile languages and matchmaking, quality of service (QoS) and context. Some of the lessons learned from this research are described below.
Although it is relatively easy to "hook into" the JBI environment, many System Program Offices are looking for specific requirements and guidance before doing so. We are making a thorough introduction to the JBI and a guidance document available. This will include more visualization capabilities in demonstrations so audiences can more easily gain a deeper understanding. We also need to provide a comprehensive Software Developers Kit (SDK) to lower the barrier for getting on board. Until there are sufficient tools to enable all development organizations with the knowledge they need to make sound design decisions and keep abreast of changes to their environment, we need humans with "big picture" knowledge providing certain key guidance to those development organizations. We need to have tools which will help us track usage statistics vis-a-vis the design characteristics for existing participants, and have resources and processes in place to analyze this information and feed back recommendations to development organizations.
Letting participants evolve on their own may take too long, the environment may become unstable, and participants may have no clear direction of capabilities to provide. For the military, we feel that a single entity should have oversight - a bird's-eye view - of the using population to ensure the environment is suitable for participants to flourish as well as to provide direction as to the capabilities a given participant will need to have.
The following lessons illustrate that information management often gets overlooked when building IT systems and networks. The adoption of the web service model does not alter that. For example:
Definition and Standardization of shared meta-data is still important! New technology does not remove the need for communities to agree on what information will be exchanged and how it should be described [7]
Decide on what information you want to provide. Interface documents or contracts are still relevant, but generalize these to derive common collections of information to meet as many requirements as possible. Focus on information content, not presentation
Pursue XML representations of the information you provide. Take advantage of existing efforts to modernize standards you already use and don't develop or adopt in isolation - participate in a community of interest
Collaborative experimentation yields great benefit! Interact with potential consumers of your information early on in your web-enablement efforts, and offer to provide feedback to your potential information providers in their web-enablement efforts
We need to enforce, or as a minimum encourage, the inclusion of semantic definitions in XML schema [8] in a consistent manner. Also required are schema repositories and tools for browsing, searching, pattern matching, etc on the information in the repositories. XML documents should be validated with respect to their underlying schema. Our participation in various military exercises has shown that many information objects are invalid. Currently validation is left up to the end user/application. Although this may be the most expedient, it may degrade overall system performance as multiple versions of schemas come into existence. At the very least, assumptions should be documented and guidance provided relative to validation. If nothing else, there could be a preferred provider status for producers that validate the documents.
There is much concern over the amount of bandwidth available to access information, especially in the case of using XML. While it is true that the size of XML documents is usually much larger than the source text document from which the XML is based, the information-centric approach discussed here helps to address these concerns. For example, in many of today's message passing interfaces, the complete message is usually passed from one system to another. In the information-centric approach, this method should be used only when absolutely necessary. Instead, consumers subscribe only to the information they need, which will usually mean that some transformation must occur to produce a subset of the information.
In addition, XML can be significantly compressed in a number of ways. There are commercial tools, such as Pkzip (everyone's favorite), or the AT&T smart compression tool: xMill [9]. Alternatively, Knowledge Based Compression [10] can be used - a MITRE concept which uses knowledge about message structure to direct compression/decompression. It can be combined with other techniques and could be used for legacy binary transmission. Also, optimized markup languages (for example, Wireless Markup Language (WML)) can be exploited where bandwidth is narrow. In addition, XML is being extended to allow transmission of binary data objects within XML elements. This will allow transmission of compressed messages within an XML wrapper. It will also further enable transmission of encoded and encrypted data and messages within XML elements. This is an important development that is significant for DoD developers.
Somewhat related to bandwidth is the level of granularity for products. Even when the basic information object schema and product type are the same, there may be differences in the levels of information granularity of the product that may affect the JBI's matching algorithms, throughput, and other aspects of system behavior; for example, consider the differences in the following:
weather observation for a period of time for a single station
weather observation for a period of time for a set of stations
We need to investigate ways to express and operate on these characteristics. We also need tools to track usage statistics and feed back recommendations to development organizations.
Information services must be developed and made available to transform information. These would be made available through service providing participants, who would free the developers of mission-specific participants from having to expend resources on developing mundane functionality (e.g., calendar, lat-long conversions, data format). Until common utilities are available, participant developers are each going to have to do conversions, adaptations, etc internally, which takes time away from developing their unique capabilities.
An information producer or service provider will likely require many different ads and products if it interacts with more than one other participant. Tools are needed to track usage statistics vis-a-vis the characteristics of the ads/needs, and resources and processes in place to analyze this information and feed back recommendations to development organizations so they can maximize the utility of their profiles and how the profiles are managed.
Participant developers will have to map among various information object schemas; that is, map between internal schema(s) and external ones used by Communities of Interest for information products and labels. We need to investigate ways to capture, track, manage, and dynamically configure these mappings.
When a data collection is made available in the JBI, there is a temptation to subscribe to the entire collection of data and hold it locally rather than just dynamically request the particular subset that is needed at any given time. This brings up a tradeoff of staleness versus performance. Having adequate bandwidth would reduce or eliminate performance issues associated with requesting data only on an as needed basis. Case studies of early participants are needed to determine if more general guidelines can be developed relating the characteristics and requirements of a participant to whether central collection, ad hoc distribution, or automatic distribution works best.
We need to broaden the community's focus from pure, single-link publish-subscribe activities to include value-chains of information comprising any number of service participants (e.g., aggregators, filters, translators, adapters) in addition to the originating publisher and end-user subscriber.
The efficiency of brokering requires further study and experimentation. For example, should we re-run the match making process when a new ad satisfying an executing need is received? How do we rate the quality of an identified "match" and determine whether we want to continue to search for better solutions? How do we judge whether it's wise to interrupt an executing flow in order to attempt to set up a supposedly better flow? So we rely only on templated (predefined) workflows or dynamically construct new ones? We need to identify the information associated with a workflow, which supports these concepts, and extend the workflow metadata to capture this information for processing.
Should we allow or encourage the specification of abstract needs? Specifying at registration time the general properties of needs that will be specified during execution of a workflow would enable the JBI core to "pre-process" a participant. This preliminary processing could save time and resources at run-time, but it is still unclear to what extent pre-processing can take place and how much benefit can be realized. We need to have clearer understanding of how the core functions affect or are dependent upon one another. Preliminary matching is relatively straightforward; it is the ranking or selection process that may not be practical to perform up front. We need to investigate potential approaches to when/how needs are submitted and the types of pre-processing that are possible through experimentation with different approaches and scenarios.
Timing and ordering of events is unpredictable, as with any event-driven system. There is no way to guarantee the time frame in which requests will be processed. When multiple requests are made simultaneously, the order in which responses are received is indeterminable, which makes the requesting participant's code more complex at the very least, and possibly has a ripple effect through other participants up and down the chain. Even though this is not a new problem particular to the JBI, it should be documented as a system constraint in the guidance given to JBI participant developers to help ensure they deal with it explicitly. Adding a requirement to provide levels of service may alleviate the problem in some cases, but at the cost of increased complexity (also, many B2B tools apply a transaction model that does not inherently support different levels of priority relative to transaction processing). Resource monitoring needs to be enabled throughout the environment. The Resource Manager should provide some sort of indication that things are working, albeit slowly.
How much control over end-to-end system is really needed, is desirable, or is practical? We need to gather statistics to learn about the system and investigate the costs and impacts of various approaches. JBI systems should be designed with configurable "debugging" modes, providing varying levels of usage statistics.
Security requirements are important in military networks. The current JBI security requirements are ill-defined. Do we need to separate static versus runtime configurations? What is required for (pre-) authorizing a participant for registration in a JBI as well as for validating its identity at runtime? What is required for pre-validation of ads and needs? What degree and amount of auditing is required? Since security requirements are specific to a system, until we have strong Concept of Operations from the communities using JBI, we are going to continue to have ill-defined security requirements.
Information management, retrieval and delivery technologies and processes can be used to help increase access to information, awareness of that information, and ultimately the timely delivery of that information to the consumer. This is especially important for decision makers who have to respond to dynamic situations and make key decisions that will significantly impact the outcome of some business transaction. The key to this success is effective information management. To do this requires:
Standardization of the information in user communities of interest is still important and must be pursued. Effective information management also requires services for publishing, subscribing to, transforming, personalizing, and presenting information objects. Web standards and technologies are helping to address this challenge, as organizations and systems begin to adopt Web services for information exchange.
We have learned that many challenges to implementing a web service architecture remain. Questions such as "Who provides the services and where are they provided?" or "What levels of security/quality of service can/should be provided?" need to be answered by a given community of interest. Still, we feel that a standards-based approach to web services can be effective for achieving information interoperability. UDDI, ebXML, XML, SOAP and WSDL are examples of open initiatives that can help make a difference.
Air Force Scientific Advisory Board, Information Management for the Warrior (report), 1998
Dr. R. Miller, Dr. M. A. Malloy, E. Masek, and Dr. C. Wild, Towards and Information Management Framework (2001), submitted Information Knowledge Systems Management
World Wide Web Consortium's XML Special Interest Group, Frequently Asked Questions on XML, www.ucc.ie/xml
M. J. Heller, Dr. M. A. Malloy, Dr. R. W. Miller, J. C. Schneider, Exploiting Web Information Standards for Interoperability (2201), submitted for publication.
Robert D. Cherinka, Enabling the Joint Battlespace Infosphere - A Case Study in Using XML to Enhance Information Interoperability, WROX Web Developer's Conference, Amsterdam, Nov 2000)
Dr. Arnon Rosenthal, Dr. Len Seligman, and Amy Kazura, XML and Interoperability: What it Does (and Doesn't) Solve, briefing presented to XML and Future Information Systems (XFIS-99) Technical Exchange Meeting, The MITRE Corporation, Reston, VA, 4 February 1999
World Wide Web Consortium's XML Schema Working Group, XML Schema Requirements, W3C Note, 15 February 1999, www.w3.org/TR/NOTE-xml-schema-req
xMill, An Efficient Compressor for XML, http://www.research.att.com/sw/tools/xmill/
Robert D. Cherinka, John A. Ricci, and John Schneider, Applying Knowledge-Based Compression (KBC) to Reduce Department of Defense (DoD) Bandwidth Requirements, MITRE WN 96B0000139, July 1996
| |
Table of contents | Author | City | Company | Country | State/Province | Term | Interchange | |