Emerging Standards for SOA Seminar

1. Emerging Standards for SOA Seminar Robert Marcus robert.marcus@sri.com

2. Background of the Seminar

3. Original Motivation for the Seminar • Scheduled as a Seminar for DISA’s Net-Enabled Command Capability (NECC) Program • One in a series of Industry Day Seminars to present expertise from industry, research and standards groups to DISA • An example of a general middle–out strategy for systems of systems development based on Capabilities Mediation • Due to unforeseen circumstances, the Seminar had to be co-located with an OMG meeting • Proceedings are at “http://www.omg.org/news/meetings/tc/special-events-dc/Emerging_Standards_forSOA.htm”

4. Capabilities Mediation Example from DISA Needs sent to Emerging Technology Strategy Needs consolidated, prioritized and documented Clarify need System of System Program solicited for ST&T needs Capabilities Mediation Group Match needs with offerings Consumers Producers Evaluate producers Needs Systems Engineering (Mike Hebert) (1) (2) System of Systems Program Management Contractors (3) Emerging Technology Strategy (Bob Marcus) (3) Vendors (4) (8) (7) Open Source Libraries Ensure offerings meet needs and constrains and final acceptance for Program (7) Offerings (6) (5) Standards Bodies Scrub list of offerings and do final offering selections, Develop list of possible offerings (9)

5. Middle Out Strategy for System of Systems USERS User Requirements and Derived Requirements Set of Requirements New capabilities available Systems Engineering Group Capability specifications (with priorities) and possible new capabilities Capabilities Mediation Group Matchmaking Mediating Capability description (with cost of implementation) and possible new capabilities Emerging Technology Group Set of Services New capabilities needed Existing, Enhanced, Composite and possible new services and/or systems

6. Implementation of Middle-Out Strategy • Organization – Capabilities Mediation Group that includes members of System Engineering and Emerging Technology Strategies Group • Domain – Partially understood problem space • Tools – Matchmaking, modeling and simulation • Process – Performs matchmaking. Reports results of matchmaking to other groups including gap analysis for new technology capabilities that must be developed and/or additional operational capabilities enabled by emerging technology. • Communication – Iterative discussions with both System Engineering and Emerging Technology Strategy Group • Skills – Understanding of technology descriptions and system specifications and the ability to resolve gaps

7. Middle Out Strategy for Federal Enterprise? USERS User Requirements and Derived Requirements Set of Requirements New capabilities available Federal CIOs Capability specifications (with priorities) and possible new capabilities Chief Architects Forum Matchmaking Mediating Capability description (with cost of implementation) and possible new capabilities Communities of Interest Set of Services New capabilities needed Existing, Enhanced, Composite and possible new services and/or systems

8. Agenda: Emerging Standards for SOA • Semantics for Web Service Specification: SDF and OWL-S (Chris Bashioum – Mitre & David Martin – SRI) • WS-Policy (Toufik Boulez - Layer 7 Technologies) • WS-Security and WS-I Basic Security Profile (Michael McIntosh - IBM ) • Service Component Architecture and Eclipse SOA Development Tools (Michael Rowley - BEA & Pat Walsh – Iona) • Service Data Objects and Apache Tuscany (Daniel Murphy – IBM) • Model-based Data Engineering for Services (Michael Hieb - George Mason University) • Collaboration across standards groups on emerging SOA standards (James Odell - OMG )

9. SOA Standards Relationships Development Web Service Standards Open SOA Standards Universal Description, Discovery and Integration (UDDI from OASIS) C2 Model-Based Data Engineering Service Data Objects Apache Tuscany Web Services Description Language (WSDL from W3C) Service Component Architecture Eclipse SOA Development Tools OASIS and WS-I Standards OASIS WS-Security WS-I Security Profiles Submissions to W3C WSDL-S WS-Policy Assertions and Attachment Web Ontology Language (OWL-S) Efficient XML

10. Systems Development and Services Standards Layers Systems - Operations Services - Enterprise FEA-DEA-BEA Federal and Defense Enterprise Architectures Enterprise Architects DoDAF DoD Architectural Framework across multiple levels (Zachman and MoDAF are similar) UPDM Unified Modeling Language (UML) Profile for DoDAF and ModAF SOA Architecture based on services Program Architects SCBA FEA extension to Services and Components SysML UML Extension for Systems Engineering System Architects and Engineers SDF Service Interface Descriptions Software Architects MDA UML Models for SW Architecture, Components and Interfaces SCA Component Interface Description Developers Testbeds such as Federated Development and Certification Environment (FDCE) Including Simulation, Executable Systems, Modules, Components and Services

11. Back-up Slides on Emerging SOA Standards

12. WS-Security and WS-I Security Profiles • WS-Security is a XML-based standard of the Organization for the Advancement of Structured Information Standards (OASIS) supporting signatures, tokens and encryption. “http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wss” • The Basic Security Profile is a collection of interoperable security components that will be specified by the Web Services Interoperability (WS-I) organization “http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity” • The Basic Security Profile will be based on WS-Security specifications • There is also a WS-I Reliable Security Profile that will specify security components for the OASIS WS-ReliableMessaging standard

13. WS-Policy Framework • WS-Policy Framework is a W3C working draft that enable entities (e.g. services) to specify policies (e.g. capabilities, requirements and characteristics) “http://www.w3.org/TR/ws-policy/” • WS-Policy Attachment has been submitted to W3C as a standard for attaching policies within XML descriptions or to general entities “http://www.w3.org/Submission/WS-PolicyAttachment/” • Policies can be used to specify security, QoS and other non-functional constraints • Policies consist of a set of policy alternatives that contain policy assertions

14. OWL-S and Service Definition Framework • The Web Ontology Language for Services (OWL-S) supplies markup capabilities for describing the properties and capabilities of Web Services http://www.daml.org/services/owl-s/1.1/ • OWL-S has been submitted for comment to the W3C. • Relationship of OWL-S to WSDL and UDDI “http://www.w3.org/Submission/2004/SUBM-OWL-S-related-20041122/” • The Service Definition Framework (SDF) uses OWL-S to describe interfaces to services “http://fdce.netcentriclab.com/FDCE_Portal/docs/robohelp/!SSL!/WebHelp/Service_Definition_Framework/GIG_SDF_Implementation_Documentation/1_Introduction.htm#1_1_Background”

15. Service Component Architecture • The Service Component Architecture is a model for building systems in Service Oriented Architectures being developed by the Open SOA Collaboration of most software companies “http://www.osoa.org/display/Main/Service+Component+Architecture+Home” • SCA includes an Assembly model for components and composites that enables the use of multiple middleware connections and languages (e.g. Java, C++) “http://www.osoa.org/display/Main/The+Assembly+Model” • SCA allows Policies to be attached to components and composites to constrain non-functional attributes “http://www.osoa.org/pages/viewpage.action?pageId=215” • The first application of the Policy Framework will be to create SCA Security Policy specifications

16. Service Data Objects • Service Data Objects (SDO) is a data specification that provides a standard format for transporting and accessing data from applications and services written in multiple languages “http://www.osoa.org/display/Main/Service+Data+Objects+Home” • SDO was originally developed independently but is now being maintained by the Open SOA industry collaboration in conjunction with SCA • Data Access Services are used to interface SDO representations with multiple types of data sources including relational and XML databases. “http://incubator.apache.org/tuscany/das_index.html”

17. Apache Tuscany and Eclipse STP • Tuscany is an open source implementation of Service Data Objects and the Service Component Architecture under development by the Apache Consortium “http://www.uddi.org/about.html” • The SOA Tools Platform (STP) is an open source project of the Eclipse Foundation to build frameworks and tools that enabling the design, configuration, assembly, deployment, monitoring, and management of software designed around a Service Oriented Architecture “http://www.eclipse.org/stp/” • There is also an Eclipse framework for Service Data Objects using Java interfaces “http://www.eclipse.org/emf/sdo.php”

18. Model-Based Data Engineering for WS • Interoperability of C2 services requires data integration at multiple levels; conceptual, attribute, and content • Complex data integration will require semantic modeling to support data mappings from heterogeneous sources “http://colab.cim3.net/file/work/Expedition_Workshop/2005_08_16_DesigningTheDRM_forDataAccessibility/Spot_IEEE_Internet_” • A common semantic data model is also necessary for composing C2 Web Services • C2IEDM can be used for initial testing • A Service Data Objects model is an alternative that could also include non-C2 data integration

19. Efficient XML • Standard compressed binary format for XML • Can provide significant benefits to all Web Services applications especially for mobile devices • Alternate approaches are under discussion as possible standards by the W3C at http://www.w3.org/XML/EXI/ • One of the leading proposals is from AgileDelta http://www.agiledelta.com/w3c_binary_xml_proposal.html • Binary <-> text conversions are implemented as a plug-in • No changes are required to applications or XML APIs • Some test evaluations have shown 10 to 100 times compression of XML data transmissions