SWIM-SUIT & ICOG Technology Selection Dario Di Crescenzo (Selex SI) David Scarlatti (Boeing)...
-
Upload
lesley-armstrong -
Category
Documents
-
view
212 -
download
0
Transcript of SWIM-SUIT & ICOG Technology Selection Dario Di Crescenzo (Selex SI) David Scarlatti (Boeing)...
SWIM-SUIT & ICOG SWIM-SUIT & ICOG Technology SelectionTechnology Selection
Dario Di Crescenzo (Selex SI)David Scarlatti (Boeing)
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 1
Overall SWIM-SUIT Overall SWIM-SUIT Technology Selection Technology Selection
ProcessProcess
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 2
Requirements
(WP 1.5)
Set of Criteria
Scenarios
(WP 1.6)
Architectural
PatternsCandidate
Technologies
Selection
Matrix
Set of Criteria for Set of Criteria for evaluation of evaluation of technologiestechnologies
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.
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
Set of Criteria for Set of Criteria for evaluation of evaluation of technologiestechnologies
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 6
5.4 ROBUSTNESSSection 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 redundancy12 - Technology supports redundancy34 - Technology supports redundancy, has self-testing capabilities and a record of stability (support invalid inputs gracefully)
Architectural Patterns Architectural Patterns from scenariosfrom scenarios
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 7
Scenarios
(WP 1.6)
Architectural
Patterns
Initial Candidate Initial Candidate TechnologiesTechnologies
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 Initial Candidate TechnologiesTechnologies
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 9
Collaborative Databases are not standardized, federation service is linked to a specific product
Initial Candidate Initial Candidate TechnologiesTechnologies
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 10
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 Initial Candidate TechnologiesTechnologies
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 11
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 Final Candidate TechnologiesTechnologies
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 Final Candidate Technologies .vs. Technologies .vs.
Architectural PatternsArchitectural Patterns
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 13
Split of set of Criteria for Split of set of Criteria for evaluation of evaluation of technologiestechnologies
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 14
Applicability for Wide Area Network (WAN)ScalabilityRobustnessFlexibilityReliabilityMessage overheadPortabilityManageabilityInteroperabilitySuitability for Near Real TimeUse of standardsSupport for Security
Availability of IDETechnical knowledge available at partnerCOTS selection
SWIMCriteria
SWIM-SUITCriteria
Selection MatrixSelection Matrix
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 15
Criteria Weight CORBA
ESB Request/
Reply
Web services (J2EE) MOM (JMS)
Web services
Notification
ESB Publish/
Subscribe
CORBA Notification
Service DDS
Applicability for Wide Area Network (WAN) 10,0% 3,0 3,0 2,0 3,0 2,0 3,0 3,0 4,0
Message overhead 10,0% 3,0 3,0 2,0 2,0 2,0 3,0 2,0 4,0
Network Performance 20,0% 0,6 0,6 0,4 0,5 0,4 0,6 0,5 0,8
Suitability for Near Real Time 5,0% 3,0 2,0 1,0 1,0 1,0 2,0 1,0 4,0
Reliability 5,0% 4,0 3,0 4,0 4,0 4,0 3,0 3,0 4,0
Robustness 10,0% 3,0 4,0 4,0 4,0 4,0 4,0 3,0 4,0
Scalability 10,0% 3,0 3,0 3,0 3,0 3,0 3,0 3,0 4,0
Efficiency 30,0% 1,0 1,0 1,0 1,0 1,0 1,0 0,8 1,2
Flexibility 6,5% 3,0 4,0 4,0 3,0 3,0 4,0 3,0 3,0
Manageability 6,5% 3,0 4,0 4,0 3,0 4,0 3,0 3,0 3,0
Portability 7,0% 3,0 3,0 4,0 2,0 3,0 2,0 3,0 3,0
Mantainability and Management 20,0% 0,6 0,7 0,8 0,5 0,7 0,6 0,6 0,6
Interoperability 10,0% 4,0 4,0 4,0 4,0 4,0 4,0 4,0 4,0
Use of standards 10,0% 4,0 3,0 4,0 3,0 4,0 3,0 4,0 2,0
Stability and evolutivity 20,0% 0,8 0,7 0,8 0,7 0,8 0,7 0,8 0,6
Support for Security 10,0% 3,0 4,0 4,0 2,0 4,0 4,0 3,0 2,0
Security 10,0% 0,3 0,4 0,4 0,2 0,4 0,4 0,3 0,2
Percentage check 100,0%
3,3 3,4 3,4 2,9 3,2 3,2 3,0 3,4
Availability of IDE 35,0% 2,0 3,0 4,0 4,0 2,0 2,0 1,0 3,0
Technical knowledge available at partner 25,0% 3,0 2,0 4,0 4,0 1,0 2,0 1,0 3,0
COTS selection 40,0% 2,0 3,0 4,0 4,0 2,0 3,0 3,0 1,0
Percentage check 100,0%
2,3 2,8 4,0 4,0 1,8 2,4 1,8 2,2
2,8 3,1 3,7 3,4 2,5 2,8 2,4 2,8
SWIM Criteria
SWIM SUIT
Criteria Score
SWIM Criteria Score
Average of SWIM & SWIM-SUIT Criteria
Publish/Subscribe
SWIM-SUIT Criteria Score
Request/Reply
Selection MatrixSelection Matrix
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 16
Selection MatrixSelection Matrix
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 17
Selection MatrixSelection Matrix
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 18
Selection MatrixSelection Matrix
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 19
Selection Matrix – Final Selection Matrix – Final SelectionSelection
15/05/2008 AP4/SWIM Technical Interchange Meeting (TIM) 20
Criteria Weight CORBA
ESB Request/
Reply
Web services (J2EE) MOM (JMS)
Web services
Notification
ESB Publish/
Subscribe
CORBA Notification
Service DDS
Applicability for Wide Area Network (WAN) 10,0% 3,0 3,0 2,0 3,0 2,0 3,0 3,0 4,0
Message overhead 10,0% 3,0 3,0 2,0 2,0 2,0 3,0 2,0 4,0
Network Performance 20,0% 0,6 0,6 0,4 0,5 0,4 0,6 0,5 0,8
Suitability for Near Real Time 5,0% 3,0 2,0 1,0 1,0 1,0 2,0 1,0 4,0
Reliability 5,0% 4,0 3,0 4,0 4,0 4,0 3,0 3,0 4,0
Robustness 10,0% 3,0 4,0 4,0 4,0 4,0 4,0 3,0 4,0
Scalability 10,0% 3,0 3,0 3,0 3,0 3,0 3,0 3,0 4,0
Efficiency 30,0% 1,0 1,0 1,0 1,0 1,0 1,0 0,8 1,2
Flexibility 6,5% 3,0 4,0 4,0 3,0 3,0 4,0 3,0 3,0
Manageability 6,5% 3,0 4,0 4,0 3,0 4,0 3,0 3,0 3,0
Portability 7,0% 3,0 3,0 4,0 2,0 3,0 2,0 3,0 3,0
Mantainability and Management 20,0% 0,6 0,7 0,8 0,5 0,7 0,6 0,6 0,6
Interoperability 10,0% 4,0 4,0 4,0 4,0 4,0 4,0 4,0 4,0
Use of standards 10,0% 4,0 3,0 4,0 3,0 4,0 3,0 4,0 2,0
Stability and evolutivity 20,0% 0,8 0,7 0,8 0,7 0,8 0,7 0,8 0,6
Support for Security 10,0% 3,0 4,0 4,0 2,0 4,0 4,0 3,0 2,0
Security 10,0% 0,3 0,4 0,4 0,2 0,4 0,4 0,3 0,2
Percentage check 100,0%
3,3 3,4 3,4 2,9 3,2 3,2 3,0 3,4
Availability of IDE 35,0% 2,0 3,0 4,0 4,0 2,0 2,0 1,0 3,0
Technical knowledge available at partner 25,0% 3,0 2,0 4,0 4,0 1,0 2,0 1,0 3,0
COTS selection 40,0% 2,0 3,0 4,0 4,0 2,0 3,0 3,0 1,0
Percentage check 100,0%
2,3 2,8 4,0 4,0 1,8 2,4 1,8 2,2
2,8 3,1 3,7 3,4 2,5 2,8 2,4 2,8
SWIM Criteria
SWIM SUIT
Criteria Score
SWIM Criteria Score
Average of SWIM & SWIM-SUIT Criteria
Publish/Subscribe
SWIM-SUIT Criteria Score
Request/Reply
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 SWIM-SUIT ICOG Tecnology SelectionICOG Tecnology Selection
13/05/2008 WP2.4 Meeting, Bruxelles
Technology candidatesTechnology candidates
• CORBA• OMG Data Distribution Service (DDS)• Web services• JMS compliant MOM• Distributed database• FTP
15/05/2008 AP4 Meeting, Bruxelles
Introduction – Technology Introduction – Technology decisionsdecisions
• 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 - Selection criteria - Technical CapabilityTechnical 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 - Selection criteria - PerformancesPerformances
• 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 - Selection criteria - Portability & evolutivity Portability & evolutivity
(1/2)(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 - Selection criteria - Portability & evolutivity Portability & evolutivity
(2/2)(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 - Selection criteria - SecuritySecurity
• 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 Selection criteria - Cost relatedrelated
• 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 Selection criteria - IT market relatedmarket 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 – Selection criteria – ProgrammaticProgrammatic
• 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
clientclientWANWAN
serverserverf(x)f(x)
UDDIbrokerbroker
WSDLWSDL
SOAP SOAP
Analysis – Web Services Analysis – Web Services XML (Req./Rep.)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 Analysis – DDS XML (Pub./Sub.)(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 resultsBenchmarking resultsCriteria Weight
DDSIDL
DDSXML
JMScompliant
MOM
CORBA notifica.
IDL
CORBAnotifica.
XML
Distributed
database
CORBAIDL
CORBAXML
Web Servicesover HTTP
Technical Capability 10%Support Data Distribution 5,0% 5 5 3 3 3 0 0 0Support Request 5,0% 0 0 0 0 0 5 5 5WAN failure recovery 5,0% 5 5 2 2 2 4 4 4
Perfos 15%Performances on WAN request/reply 15,0% 0 0 0 0 0 5 4 3Performances on WAN pub/sub 7,5% 5 4 3 3 2 0 0 0Multi-cast 7,5% 5 5 3 1 1 0 0 0
Portability & evolutivity 30%Multi-OS suppported 2,5% 4 4 5 5 5 5 5 5Muti-language supported 2,5% 4 4 2 5 5 5 5 4Multiversionning/extensibility 10,0% 2 4 4 2 4 2 4 4Standardized multi-source solution 10,0% 3 3 2 4 4 4 4 5Evolutivity of infrastructure 5,0% 5 5 4 5 5 5 5 5
Security 10%Security (authentication) 5,0% 1 1 3 3 3 3 3 3Data Security (encryption) 5,0% 1 1 3 3 3 3 3 3
Cost related 15%Cost to purchase 7,5% 4 4 4 4 4 3 3 5Administration & maintenance 7,5% 4 4 2 3 3 4 4 4
IT market related 15%Maturity 7,5% 2 2 3 5 5 5 5 5Forecasted market impact 7,5% 3 4 4 2 2 2 2 5
Programmatic 5%Consistency with CoFlight/Itec middleware
5,0%5 5 3 5 5 5 5 3
Check 100% Result 353 373 310 325 338 0 390 395 415
Ranking 2 1 5 4 3 6 3 2 1
Request/ReplyPublish/Subscribe
15/05/2008 AP4 Meeting, Bruxelles
ConclusionsConclusions
• 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