Panel Does SOA Help Interoperability

1. www.oasis-open.org PanelDoes SOA Help Interoperability

2. Does SOA Help Interoperability Chair Martin Chapman, Oracle Goran Zuric, Semantion Miko Matsumura, Infravio Ash Parikh, Raining Data Robert Carpenter, Intel Michael Evanoff, ManTech e-IC

3. www.oasis-open.org Does SOA help or hinder interoperability? • Common definition? • Is SOA concrete? • What interop features exist? • Any hindrances to interop? • Improvements in SOA needed?

4. www.oasis-open.org FERA-SOAGoran Zugic, Chief Architect, Semantion Inc.

5. What Makes up a SOA? • Service Oriented Architecture (SOA) is a set of components, guidelines and principles for execution of business processes as a continuously evolving network of value added services. SOA relies on an integrated framework that includes a repeatable methodology, open standards, best practices, a reference architecture and a configurable run-time architecture to provide semantically reconciled model time and run time environments for a fast enterprise.

6. What Value SOA Brings? • Common semantics - Business people and the technologists speak the same language. • Business and IT alignment - SOA links business and technology using a methodology that enables a service-based business process modeling in a business language and ontology that is transparently translated into the SOA reference architectural components that are directly mapped into the run-time SOA virtual machine that deploys and executes business processes.

7. What Value SOA Brings? (cont.) • Improved effectiveness - SOA increases agility of the business by enabling both online (real-time) and offline efficient deployment of changes with minimal human involvement; lower cost and improve error-rates/operations using technology and minimizing human involvement. • Reduced development cost - Services are reusable components and they can be combined into new composite applications. • Reduced risk - For those concerned about extensive investments and changes across all IT systems, an incremental deployment is supported.

8. What Value SOA Brings? (cont.) • Improved quality of service - New services can reuse existing services that have been already tested, tuned and used in production. Since SOA is a loosely-coupled architecture, services can run where it makes the most sense in a context of quality and performance. • Outsourcing - Organizations can provide services to each others. • Price/performance optimization - Open standard based systems enable flexible technology, platform, and location selections. Many options exist to be considered from an investment point of view.

9. What Value SOA Brings? (cont.) • Extendibility - Extended ability to expose some enterprise processes to other external entities in inter-enterprise collaborations; open new channels, acquire new customers, differentiate products by the use of patterns and technology

10. Is SOA Concrete Enough to be of Use? • Yes. FERA-SOA provides the answer. Semantion contributed FERA-SOA specifications to OASIS ebSOA TC in September 2005.

11. What Features are Required for Interoperability ? • Open standard-based meta-data for business entities • Open standard-based business documents formatting and translation between different formats • Service-oriented process semantics with information model • Open standard-based interfaces and protocols for the plug-and-play architectural components • Semantic-based reference and run-time architecture

12. FERA-SOA Introduction • Based on Federated Enterprise Reference Architecture (FERA) • Semantic-based solution with SOA Information Model (SOA-IM) and SOA Collaboration Semantics (SOA-CS) supporting all SOA layers from message exchanges to complex orchestrations • Loosely coupled architecture that does not require coding. FERA-SOA “compose” applications • Defines complete reference and run-time architecture. All architectural components are plug-and-play. • Supports different types of processes • external collaboration oriented business processes (collaborations with partners, suppliers, customers, etc.) • Internal collaboration oriented processes (integration and interoperability in mid-size and large enterprises)

13. FERA-SOA Introduction (cont.) • enterprise information integration processes (data and metadata management) • infrastructural processes (IT infrastructural management based on either widely accepted models like ITIL or proprietary models) • Any combination of above processes

14. What is FERA? • Federated Enterprise Reference Architecture (FERA) defines seven generic SOA components and provides a set of guidelines and principles for using their functional capabilities to support any collaborative process • Collaborative processes in FERA are loosely coupled utilizing a service oriented semantics for process execution

15. Brief Background on FERA • In 2001/2002 D.H. Brown Associates conducted several research projects in the area of value chain collaboration (funded by IBM and HP) • Projects pointed out to major misconceptions in technology approaches by leading trade exchanges • Projects pointed out that there were a finite number of collaborative process patterns in practice (HP Key Chain, Daimler Chrysler SNC,…) • In 2002/2003 DHBA analyzed over a hundred of use cases involving collaboration in product development and supply chain management (funded by HP, Intel and Microsoft) • Consolidated first FERA definition • Emergence of service orientation

16. Brief Background on FERA (cont.) • In 2004/2005, CPDA (PLM Group of DHBA) detailed out FERA model and guidelines, reconciled methodology with VCOR • Started with the SCOR/PD4SC/VCOR • Intel IPTF direction for the SOE • ebSOA emergence

17. FERA-SOA Principles • A common integrated semantic framework with a full methodological and technical support from business process requirements to the run-time SOA architecture. The integrated semantic framework preserves fidelity of requirements by direct translation from business models to the run-time environment. It takes the requirements directly from the domain expert, using their language to describe how a process does or should work. • Code development free integration of all process elements and/or sources of enterprise information. • Open standard-based architectural solution with standard-based components providing reusability and avoiding proprietary expensive vendor-locked solutions.

18. FERA-SOA Principles (cont.) • Standard convergence that enables full interoperability between different standards and technologies and at the same time supports the consolidation of standards (Web Services, ebXML, etc.) used in SOA.

19. Elements of FERA • Reference Architecture • 7 basic components required for collaborative process execution • 31 functional categories • 92 capabilities • Over 200 features and functions

20. federated users Choreography Administration Portal federated administrators Event Management Collaborative Services Agent Framework Federation Server Gateway federated systems Seven Basic Components

21. activities produce perform feed inputs outputs roles can be feed generate make produce decisions trigger metrics evaluated by govern rules events trigger generate Basic Process Flow Representation Elements

22. Interoperability in FERA-SOA • Protocols, interfaces, meta-data, security, content formats, content transformations and process-based collaborative standards are critical for enabling open plug and play communications. Many of the standards that are being used do not necessarily inter-operate with each other to enable composition to achieve a higher level solution. • FERA-SOA enables deployment and execution of collaborative processes. At the same time, it provides a semantic-based foundation for interoperability among SOA-related standards and overall SOA architectural integration.

23. Interoperability in FERA-SOA (cont.) • The semantic approach of FERA-SOA directly reconciles business process definition with a set of architectural components based on open standard specifications. This semantic approach to open standards interoperability and integration is enabled by three FERA-SOA specification components: • Run-time SOA Architecture • SOA Information Model • SOA Collaboration Semantics. • In FERA-SOA, all required interfaces for data and information exchanges are supported by already available open standards such as SOAP, ebXML Messaging, WS-* standards, ebXML Registry, UDDI, UBL, XACML, SAML, process-based collaborative standards such as ebBP, BPEL, and others.

24. Interoperability in FERA-SOA (cont.) • FERA-SOA architectural components’ protocols and interfaces defined in SOA Collaboration Semantics enable their mutual interoperability what directly reflects standards interoperability since all these components are already defined using previously mentioned accepted standards. • FERA-SOA is enabling creation of the first semantic-based SOA Virtual Machine (SOA-VM). FERA-SOA utilizes FERA patterns of collaborative (business) processes that classify and categorize any process according to the structural definition of its flow.

25. Interoperability in FERA-SOA (cont.) • Structural patterns enable direct mapping of process characteristics into the underlying run-time architecture using ontology that enables automatic generation of the run time execution instructions directly from the business process definition. • Thus, FERA-SOA supports business process of any type and complexity, always utilizing a common set of standard-based components, functions and interfaces, open internal and external information exchange, and deployment of process orchestrations in the SOA Virtual Machine. The initial process deployment and all subsequent deployments do not require coding.

26. FERA-SOA Integrated Framework Business process and return on investment analysis (e.g., VCOR, ITIL, etc.) BPM (FERA ontology) SOA-VM

27. SOA Information Model • Federation Information Model (FIM) – Content and Context • FIM is an informational bridge between public and private world. • Definition of federate profiles, business process specifications, collaboration protocols and agreements, security policies, etc. Information that supports public processes and documents of any type for both public and private collaborative processes. • Collaborative Process Information Model (CPIM) • Supports complete CP context. • The main CPIM entities are: CP Flows, CP Roles, Metrics • Collaborative Process Flow Information Model (CPFIM) • Supports definition of the possible flows of activities, decisions and events within the CP • The main CPFIM entities are: Services, Activities, I/O-s, Events, Triggers, Decisions, Sequences, References, etc.

28. SOA Collaboration Semantics • SOA Collaboration Semantics defines protocols and all interfaces with methods required for the collaboration data (SOA Information Model) manipulations and interactions between SOA architectural components providing a full interoperability in FERA-SOA.

29. Run-time FERA-SOA (SOA Virtual Machine) P O R T A L (HTTPS,JSP,HTML) Federation Gateway ebXML BP, CPPA WSBPEL, WS- Choreography, WSDL,XSD WS Management SOA Federation Single WS (WSDL) Federation Server SOAP Federation Manager (SOA IM, SOA CS, ebXML Registry, UDDI, CAM,UBL,CPPA,WSDL) Agent Interface Manager (SOA IM, SOA CS) SOAP WS-Security WS-Reliability WS-based System (UDDI,WSBPEL, WS-Choreography, WSDL,XSD, Cougaar) Federation Registry (ebXML Registry, UDDI) Security Provider (SOA IM, SOA CS, XACML, SAML) ebXML Msg Agent Framework SOAP WS-Security WS-Reliability ebXML-based System (ebXML Registry, ebXML BP,CPPA) CP Flow Controller ebXML Msg Process Flow Manager (SOA CS) SOAP WS-Security WS-Reliability Client/Server Event Manager (SOA CS) Activity Manager (SOA CS) Decision Manager (SOA CS) ebXML Msg Proprietary Process Flow Registry (SOA IM) Mainframe SOAP Built-in Services Data Collection Analysis Reporting Other Built-In Services

30. Where SOA Needs To Improve? • Missing Standards • Business Rules • Service Model • Agent Framework • Security • More sophisticated aspects of security are needed. SOA security should be further developed in the context of four levels: resources, information, context, intelligence • Reliability • Many factors are involved in SOA deployment and execution of processes (systems, humans, applications, network, legal, etc.)

31. Summary • SOA relies on an integrated framework that includes a repeatable methodology, open standards, best practices, a reference architecture and a configurable run-time architecture to provide semantically reconciled model time and run time environments for a fast enterprise. • FERA-SOA provides a complete reference and run-time architecture for SOA. It also enables business process modeling based on FERA ontology. • Semantic-based architecture is a key interoperability enabler

32. Summary (cont.) • When the components and interfaces are standardized, the focus shifts from technology to methodology • Using common semantics, business people and the technologists speak the same language. • No-coding FERA-SOA virtual machine and hot swapping of the business orchestration logic

33. SOA Panel Miko Matsumura, Infravio

34. Ash ParikhRaining Data Corporation

35. The SOA Experiment "Sometimes I Lie Awake at Night, and I Ask, 'Where Have I Gone Wrong?' Then a Voice Says To Me, 'This is Going to Take More Than One Night.' " - Charlie Brown.

36. SOA Implementations Today • Most IT Departments are Simply Testing the SOA Waters • Many SOA Implementations are Prototypes and do Not Address Scalability, Security and Governance • Prototypes Demonstrate Benefits, But the Path to Enterprise-Grade SOA Appears Daunting

37. SOA Goals • Break down Application, Departmental and Trading Partner Silos • Effectively Manage and Reuse Enterprise Services and Data • Align the Business and IT groups to Achieve Organizational Goals

38. Challenges for a Successful SOA • Breaking Down Silos Necessitates Cultural Changes • Potential for Confusion about Owners of Data and its Veracity • Burgeoning Services Lead to Scalability Issues with Data Management • SOA is Many things to Many People, Adding to the Confusion

39. Components of an Enterprise-Grade SOA • Service Layer and Registry is the Focus Today… this is Simply Not Enough • Strict SOA Governance…Policies for Regulating and Managing Data is Imperative • SOA Repository...Fine-Grained Control of your Data, Not Just Metadata, is the Key

40. Implement SOA the Right Way • SOA Repository Must be the Core of Your SOA Implementation • XQuery is a Powerful and Natural Language for XML Metadata Querying And Manipulation • An XDMS Provides Native XML Storage and Retrieval • Fast, Scalable SOA is Possible With Native XDMS and XQuery

41. Implement SOA the Right Way • A SOA Repository Must be the Core of Your SOA Implementation • An XDMS Provides Native XML Storage and Retrieval • XQuery is a Powerful and Natural Language for XML Metadata Querying, Manipulation, Federation, Aggregation, Data Repurposing, Policy-Based Caching, Mid-Tier Caching • Fast, Scalable SOA is Possible With a High-Performance XDMS and XQuery

42. SOA Panel Richard Carpenter, Intel

44. DOES SOA HELP INTEROPERABILITY? SOA is a broad concept that encompasses reference models, blue prints and architectural styles, as well as a plethora of vendor products and tools to help organizations build and manage SOA environments. Given this broad nature, does SOA help or hinder interoperability? Is there a common definition of what makes up a SOA, and is it concrete enough to be of use? This panel will explore what value SOA brings, what features are required for interoperability, and where SOA needs to improve. By Michael D. Evanoff Technical Director ManTech Enterprise Integration Center (e-IC) Tuesday May 9th, 2006 OASIS Symposium: The Meaning of Interoperability

45. DOES SOA HELP INTEROPERABILITY? • What do we mean when we say SOA? • Are we talking about the abstract or the concrete? • What do we mean when we say Interoperability? • Are we talking about architectures, or services, or data?

46. SOA in the Concrete • There are numerous definitions for the term SOA and hence SOA implementations vary widely as well • The U.S. Department of Defense is embracing SOA via the Global Information Grid (GIG) Enterprise Services (ES) area, which includes the Net Centric Enterprise Service (NCES) program • Early pilot implementations vary • Lack of design to support shared services and reuse • Lack of implementation guidance for the DoD Data Strategy • Working towards a common vision is helping in understanding what it will take to transition from today’s legacy environment to SOA

47. SOA in the Abstract • Agreement on SOA concepts are a help to solving the interoperability problem • The OASIS SOA RM TC has developed the SOA Reference Model Public Draft • This document provides a detailed set of defined concepts and a framework describing the relationships of these concepts • Some new and needed areas of note include: • Visibility • Execution Context, etc.

48. Interoperability • Architectures • Standards for defining Enterprise Architectures • DoD Architecture Framework (DoDAF) • Core Architecture Data Model (CADM) • DoD Architecture Repository System (DARS) • Net Centrity (aka SOA) • Paradigm change in posting and sharing of information • Web Service Stack • Services • Need to educate target audience on best practices for designing with reuse and shareability in mind • Need standard approaches for how to go about retrofitting legacy systems to plug and play • Course grained vs. fine grained services • Enterprise Service Bus, etc. • Data • DoD Data Strategy • Semantic Web

49. SOA Reference Model Conformance Motivating Factors SOA Interoperabilty SOA Tools, Techniques, and Methodologies SOA Target Environment Implementation Guidance

50. For More Information ManTech International Corporation Point of Contact: Mike Evanoff, Technical Director – Enterprise Interoperability (304) 368-4137, evanoffm@mantech-wva.com