SITIS Archives - Topic Details
Program:  SBIR
Topic Num:  A10-098 (Army)
Title:  Adapterless Information Consolidation
Research & Technical Areas:  Information Systems

Acquisition Program:  
  Objective:  Soldiers currently end up with a multitude of information management tools after each successive technological advancement in the field of network management. These tools cause interoperability problems and require the use of adapters that can translate from one tool to another. A high number of adapters causes a network to be complex and also increases the total amount of time information takes to be get from one end to another due the time it takes to process information at each intermediate node along a transmission path. There is a need to develop a solution that takes information from a variety of different sources and processes this information without the aid of adapters. The objective of this program is to develop a software engine that uses specified information about the domain space to automatically process any information from any data source without the need for developing any adapters.
  Description:  The standard solution to the Army's problem of incorporating and integrating different information from a variety of tools and data sources into a unified context and view consists of the development of specific adapters (for each source and tool) that format the data into a common API. This solution has a major problem where an adapter (software) needs to be developed for every new data source or tool; any subsequent changes to the API requires modifications (software changes) to all existing adapters.

  PHASE I: Describe algorithms/techniques that can be used to consolidate information from a variety of tools and data sources into a unified context and view. Bi-monthly status reports and final report should document progress made throughout program.
  PHASE II: Deliver a software prototype based on algorithms/techniques developed during Phase 1. Final report should compare software prototype to products that existed prior to SBIR program, and document test results of software prototype. Target customers of software prototype should be identified in military and/or commercial industry. Acquisition program(s) should be targeted as military customers if software prototype is applicable for use within program(s).

  PHASE III: The "end-state" result of this research would be integration of product into an acquisition program of record such as Program Manager-Warfighter Information Network-Tactical (PM WIN-T). This product is also applicable to application programs of record such as DCGS-A, CPOF as well as commercial network management systems. Integration in the military environment should result in an improvement in the consolidation of tactical network information into a unified context and view. Integration in the commercial environment should result in lower costs for organizations as they upgrade from one network management system to another and greater ease of management for commercial network administrators. Research should have a commercial application, or help enable one or more commercial technology products to be inserted into defense systems.

  References:  ) 'Automated Glue/Wrapper Code Generation in Integration of Distributed and Heterogeneous Software Components' by Wei Zhao, Barrett R. Bryant, Fei Cao, Carol C. Burt, Rajeev R. Raje, Andrew M. Olson, Mikhail Auguston 2) 'Leveraging Federal IT Investment With Service-Oriented Architecture' by Geoffrey Raines 3) 'Measuring Continuous Integration Capability' by Bas Vodde 4) https://ade.army.mil/learn/ADE%20Wiki/Architecture%20Overview%20-%20Interface%20Adapters.aspx 5) 'An Evaluation by SOA Frameworks' by Ramakrishna Raju 6) 'Design strategies for legacy system involvement in SOA solutions' by Jeremy Caine and Joe Hardman 7) 'Building an Integrated Ground Architecture to Respond to Present Challenges' by Pete Rustan

Keywords:  Service-oriented Architecture (SOA), Adapter, Integration, Translator, Netops, Application Programming Interface (API), Automation

Additional Information, Corrections, References, etc:
Ref #8: Additional information from TPOC to clarify requirements for A10-098 (uploaded in SITIS 5/18/10).REF A10_098 Addl Info from TPOC.doc

Questions and Answers:
Q: In reference to following statement: "software engine that uses specified information about the domain space" -- W
1. What would be the source of such information?
2. Is it assumed to be pre-defined or provided by the user.
3. How do you envision maintaining domain spaces as situations evolve?
4. Is it a part of the problem that needs to be addressed by the proposal?
A: 1. The source of such information would include, but not be limited to, data such as Simple Network Management Protocol (SNMP) messages, ASCII text, voice codecs (G.711, etc.) and video codecs (MPEG4).

2. Information is assumed to be provided by the user. The format of the information would be pre-defined (example: xml, text, voice codec, video codec), but the actual information itself would be provided by the user.

3. I assume you as the situations evolve, the domain space is expected to utilize the same type of information. We may use different vehicles, weapons, etc. and the message formats may change, but there may be key aspects of the information (example: GPS coordinates, radio frequency, battery life, voice codec, video codec) that remain the same. The domain space may need to be maintained through upgrades to the adapterless
solution to match changes in the different devices and message types, but the effort required in upgrading this adapterless solution should be less than effort required to create a solution of adapters/translators.

4. How to ease maintenance of domain space is a problem that needs to be addressed by the proposal. The adapterless solution should be modular in nature in order to be extensible to evolving situations, devices, and massage formats.
Q: SBIR 10.2 topic A10-098:
Additional information from TPOC in response to FAQs:

1. As I understand, the objective of this program is to take “specified information about the domain space”. Can you shed any light on what sort of information would be available (text files, application specific files, imagery, and so forth), and as to the makeup of the domain space itself?
A: Such information would include data such as, but not limited to, Simple Network Management Protocol (SNMP), ASCII text, voice codecs (G.711, etc.) and video codecs (MPEG4).

2. Does the developed solution have to navigate layers of network security, or should I consider encryption to be outside the scope of this problem?
A: Encryption is outside the scope of this problem.

3. Would it be correct to characterize this problem as one of cross-platform compatibility?
A: Yes, it would be correct to characterize this problem as one of cross-platform compatibility.

4. The previous answer mention databases, excel spreadsheets and 3rd party applications as different sources of information that are to be integrated. Are general web services (i.e. services defined by some application fulfilling a WSDL contract – perhaps as part of the Net-centric direction) to be integrated by this system?
A: Yes, general web services are to be integrated by this system.

5. The previous answer uses an API as an analogy to the ‘adapter-less’ solution. We understand an API to provide a well defined interface of both the operations/services provided as well as the incoming and outgoing data formats. However, we further associate both platform and/or language specific requirements and limitations with the term API. Presumably, you would ideally wish to avoid such restrictions in a general purpose system. Would we be correct in assuming that a WSDL definition for a SOA based service would fulfill the proper definition of the supported operations and data formats of the ‘adapter-less’ solution to its downstream consumers?
A: Yes, a standard API would definitely have limitations. According to the definitions of WSDL and SOA below,
WSDL: WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint.
SOA: In computing, a service-oriented architecture (SOA) is a flexible set of design principles used during the phases of systems development and integration. A deployed SOA-based architecture will provide a loosely-integrated suite of services that can be used within multiple business domains.
It would therefore be correct to assume that a WSDL definition for a SOA based service fulfills the proper definition of the supported operations and data formats because such an SOA would provide flexibility not available in typical APIs, and would, thus, contribute to an ‘adapterless’ solution.

6. Do you envision providing/specifying, to some degree, the form, structure and content of the WSDL (or API) that is to be supported by the ‘adapter-less’ solution – either now or at some later point in the lifecycle of this solution?
A: Yes, I envision providing/specifying, to some degree, the form, structure and content of the WSDL (or API) that is to be supported by the ‘adapter-less’ solution over the course of this program. I envision that such a WSDL (or API) should be built to handle data such as, but not limited to, Simple Network Management Protocol (SNMP), ASCII text, voice codecs (G.711, etc.) and video codecs (MPEG4).

7. If so, does this logically then imply that a major function of the automated ‘adapter-less’ solution is to algorithmically map the upstream data sources it consumes to the WSDL provided to its consumers?
A: Yes, the objective of this program is to algorithmically map the upstream data sources it receives to the WSDL-based SOA of its consumers such as PM WIN-T, PM FCS, JTRS JPEO, etc.
A: o

Record: of