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.