SWIM-SUIT & ICOG Technology Selection Dario Di Crescenzo (Selex SI) David Scarlatti (Boeing) 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 1

Overall SWIM-SUIT Technology Selection Process 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 2 Requirements (WP 1.5) Set of Criteria Scenarios (WP 1.6) Architectural Patterns Candidate Technologies Selection Matrix

Set of Criteria for evaluation of technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 3 Technical knowledge available at partner Applicability for Wide Area Network (WAN) Scalability Robustness Flexibility Reliability Message overhead Portability Manageability Interoperability Suitability for Near Real Time COTS selection Use of standards Availability of IDE Support for Security Requirements (WP 1.5) Set of Criteria

Set of Criteria for evaluation of technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 4 Requirements Set of Criteria Technical knowledge available at partner Applicability for Wide Area Network (WAN) Scalability Robustness Flexibility Reliability Message overhead Portability Manageability Interoperability Suitability for Near Real Time COTS selection Use of standards Availability of IDE Support for Security The different criteria are grouped by topics having different weights: Network Performance e.g. Message overhead Efficiency e.g. Reliability, Robustness, Scalability Maintainability and Management e.g. Flexibility, Manageability.. Stability and Evolutivity e.g. Interoperability, Use of Standards.. Security Support for Security

Scalability Robustness Use of standard Message Overhead …  For each property a value in the range from 0 to 4 has been assigned 0 - Technology does not lean on standard Technology leans on a new standard (durability not guaranteed) Technology leans on mature and widespread standards.  The Criteria are divided in two groups: the Swim Criteria are those that must be considered allocated to the SWIM project, while the SWIM-SUIT Criteria that are related to SWIM- Prototype aiming to more pragmatic issues in the short time. Set of Criteria for evaluation of technologies

15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 6 5.4ROBUSTNESS Section of "Information Content and Service Requirements" defines robustness and details eleven requirements for SWIM. Some of these requirements will drive to specific design practices and architecture patterns, especially those related to redundancy and fault tolerance (stress conditions). Other will impose special functional design, mainly the ones related to cope with erroneous or corrupt data (invalid input). Here we consider the impact of the requirements on the underlying technologies to be used; mainly its level of support to distributed and redundant architectures. Robustness can be improved too if the technology shows some self-testing capabilities. Related Requirements: SWIM-SYS-ROB-010 TO SWIM-SYS-ROB-110 Each technology will be scored this way: 0 - Technology does not support redundancy Technology supports redundancy Technology supports redundancy, has self-testing capabilities and a record of stability (support invalid inputs gracefully)

Architectural Patterns from scenarios 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 7 synchronous coupled Request / Reply asynchronous decoupled Publish / Subscribe Scenarios (WP 1.6) Architectural Patterns

Initial Candidate Technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 8 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DATA DISTRIBUTION SERVICE (DDS) J2EE CONNECTOR ARCHITECTURE (JCA) ENTERPRISE SERVICE BUS (ESB) WEB SERVICES ELECTRONIC BUSINESS USING EXTENSIBLE MARKUP LANGUAGE (EBXML) MESSAGE ORIENTED MIDDLEWARE (MOM) COLLABORATIVE DATABASES

Initial Candidate Technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 9 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DATA DISTRIBUTION SERVICE (DDS) J2EE CONNECTOR ARCHITECTURE (JCA) ENTERPRISE SERVICE BUS (ESB) WEB SERVICES E LECTRONIC B USINESS USING E X TENSIBLE M ARKUP L ANGUAGE (EBXML) MESSAGE ORIENTED MIDDLEWARE (MOM) COLLABORATIVE DATABASES Collaborative Databases are not standardized, federation service is linked to a specific product

Initial Candidate Technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 10 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DATA DISTRIBUTION SERVICE (DDS) J2EE CONNECTOR ARCHITECTURE (JCA) ENTERPRISE SERVICE BUS (ESB) WEB SERVICES E LECTRONIC B USINESS USING E X TENSIBLE M ARKUP L ANGUAGE (EBXML) MESSAGE ORIENTED MIDDLEWARE (MOM) COLLABORATIVE DATABASES Collaborative Databases are not standardized, federation service is linked to a specific product JCA connectors are not further since they seems a weak alternative to other technologies like CORBA or Web Services

Initial Candidate Technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 11 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DATA DISTRIBUTION SERVICE (DDS) J2EE CONNECTOR ARCHITECTURE (JCA) ENTERPRISE SERVICE BUS (ESB) WEB SERVICES E LECTRONIC B USINESS USING E X TENSIBLE M ARKUP L ANGUAGE (EBXML) MESSAGE ORIENTED MIDDLEWARE (MOM) COLLABORATIVE DATABASES Collaborative Databases are not standardized, federation service is linked to a specific product JCA connectors are not further since they seems a weak alternative to other technologies like CORBA or Web Services WebServices and ebXML are using the same technology, Web Services are more flexible

Final Candidate Technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 12 COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DATA DISTRIBUTION SERVICE (DDS) ENTERPRISE SERVICE BUS (ESB) WEB SERVICES MESSAGE ORIENTED MIDDLEWARE (MOM)

Final Candidate Technologies.vs. Architectural Patterns 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 13 CORBA ESB Web services (J2EE) Request / Reply JMS Web services Notification ESB CORBA Notification Service DDS Publish / Subscribe

Split of set of Criteria for evaluation of technologies 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 14 Applicability for Wide Area Network (WAN) Scalability Robustness Flexibility Reliability Message overhead Portability Manageability Interoperability Suitability for Near Real Time Use of standards Support for Security Availability of IDE Technical knowledge available at partner COTS selection SWIM Criteria SWIM-SUIT Criteria

Selection Matrix 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 15

Selection Matrix 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 16

Selection Matrix 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 17

Selection Matrix 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 18

Selection Matrix 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 19

Selection Matrix – Final Selection 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 20

Why this technologies Matrix is useful, but there is not clear “winner” technology (most could work) A mix of pragmatic reasons (see 3 last criteria) plus research interest has influenced to choose: –Web Services (request/reply) –DDS (publish/subscribe) –JMS (publish subscribe)

 For request/reply pattern:  Web services (J2EE) and ESB Req/Rep have been considered substantially equivalent for the SWIM criteria  For the prototype implementation a better knowledge by the partners leads to Web Service selection.  For publish/subscribe pattern:  DDS has been considered more suitable with respect to efficiency, network performance group criteria (better QoS support, scalability …)  For the prototype implementation a better availability of IDE integration and maturity of technology leads to experiment both JMS then DDS.  One of the objectives of the SWIM-SUIT is to demonstrate technology independence of the solution Why this technologies

Why 2 technologies for publish subscribe One of the objectives of the SWIM-SUIT is to demonstrate technology independence of the solution We plan to run the publish/subscribe scenarios with any of the two technologies: –DDS –JMS

SWIM-SUIT ICOG Tecnology Selection 13/05/2008 WP2.4 Meeting, Bruxelles

Technology candidates CORBA OMG Data Distribution Service (DDS) Web services JMS compliant MOM Distributed database FTP 15/05/2008 AP4 Meeting, Bruxelles

Introduction – Technology decisions Several technology decision: –Technology for describing the payload –Technology for providing request/reply pattern –Technology for providing publish/subscribe pattern For FO and ENV data 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Technical Capability Support Request/Reply –That feature measures the availability to support the service/response pattern Support publish/subscribe –That feature measures the availability of a data distribution (one to many) service in the technology WAN failure recovery –That feature measures the ability of the technology to provide backup strategies in case of WAN failure 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Performances Performances on WAN request/reply –This criterion measures the behaviour of the technology when processing a service request through a wide area network. This behaviour is measured regarding its latency times, capacity figures, response times Performances on WAN pub/sub –This criterion measures the behaviour of the technology when publishing or subscribing to events through a wide area network. This behaviour is measured regarding its latency times, capacity figures, response times Multi-cast –This criterion determines if the technology allows messages distribution by the IP multicast protocol 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Portability & evolutivity (1/2) Multi-OS supported –This criterion measures the ability of the technology to be implemented over different operative systems Multi-language supported –This criterion measures the range of programming languages that can implement the technology Multi-versioning/extensibility –This criterion measures the ability of the technology to face multiples IOP interfaces at the same time and also the capability to support the increments in the number of IOP stakeholders and their interfaces 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Portability & evolutivity (2/2) Standardized multi-source solution and protocol interoperability –That feature measures whether or not all the actors must use a unique solution. A standard based solution provided by several vendors is preferable. It evaluates, in case the technology requires third party vendors, the availability of several sources Evolutivity of infrastructure –This criterion measures the ability of the technology to be adapted or keeping on working upon potential infrastructure changes 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Security Security (authentication) –This criterion measures the capability of the technology to provide an efficient method for identifying the users of the IOP network Data Security (encryption) –This criterion measures the capability of the technology to provide a method of data encryption that avoids non-authorized users to decrypt and understand the data being transferred 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - Cost related Cost to purchase –That criterion evaluates the relative cost to acquire development and/or runtime licences in case the technology requires a COTS with charge Administration & maintenance –This criterion measures the technology-derived cost related to administration, deployment and maintenance operations or even IOP functionality or capabilities upgrade 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria - IT market related Maturity –This criterion is used to evaluate the grade of the confidence that the technology has acquired through its use in other successful projects and the grade of standardization that it has reached Forecasted market impact –This criterion is used to evaluate the expected level of use of the technology in the Information Technology (IT) market in the coming years. This criterion is defined to reflect how emerging technologies that may not be very widely adopted today might pick-up as the solution of tomorrow 15/05/2008 AP4 Meeting, Bruxelles

Selection criteria – Programmatic Consistency with CoFlight/iTEC middleware –That criterion evaluates the suitability of the IOP middleware with regards to the internal system middleware 15/05/2008 AP4 Meeting, Bruxelles

Analysis – Web Services XML (Req./Rep.) The W3C defines a Web service as a software system designed to support interoperable Machine to Machine interaction over a network. Web Services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks –Great interoperability and extensibility –Natively based on XML –Can be combined in a loosely coupled way in order to achieve complex operations Thanks to SOAP protocol, platform independent Language independent Extensible 15/05/2008 AP4 Meeting, Bruxelles

Analysis – DDS XML (Pub./Sub.) Data-centric communication model assures efficient data distribution, with robust and highly configurable capabilities –Rich set of QoS: Durability, Reliability, Timeliness, Partition, Ownership, Resource_limits … –Interoperability between vendors assured by RTPS Wire Protocol –DDS is widely considered as the future technology for data distribution over large distributed networks with a large market impact. Use of XML payload strategy overcome multi- versioning and interface evolution issues that are present using IDL 15/05/2008 AP4 Meeting, Bruxelles

Benchmarking results 15/05/2008 AP4 Meeting, Bruxelles

Conclusions FO Distribution and Dynamic ENV data –XML on DDS thus combining the flexibility and evolutivity features of XML together with performance and reliability features of DDS FO Request –Web Services considered as a more forward-looking solution by the ATM community –XML on DDS Static ENV Data –AIXM on JMS (SonicMQ) (adopting already existing solutions??) 15/05/2008 AP4 Meeting, Bruxelles

Thanks