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

2. 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

3. 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

4. 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

5. 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. 1 2 - Technology leans on a new standard (durability not guaranteed) 3 4 - 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

6. 15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 6 5.4ROBUSTNESS Section 3.2.3 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 1 2 - Technology supports redundancy 3 4 - Technology supports redundancy, has self-testing capabilities and a record of stability (support invalid inputs gracefully)

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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)

13. 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

14. 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

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

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

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

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

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

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

21. 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)

22.  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

23. 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

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

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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. Benchmarking results 15/05/2008 AP4 Meeting, Bruxelles

38. 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

39. Thanks