Panel Does SOA Help Interoperability

1
PanelDoes SOA Help Interoperability
www.oasis-open.org
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
FERA-SOAGoran Zugic, Chief Architect, Semantion
Inc.
www.oasis-open.org
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
Seven Basic Components
21
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- Ch
oreography, WSDL,XSD WS Management
SOA Federation
Federation Server
Single WS (WSDL)
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, WS
DL,XSD, Cougaar)
Security Provider (SOA IM, SOA CS, XACML, SAML)
Federation Registry (ebXML Registry, UDDI)
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
Built-in Services
SOAP
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 GovernancePolicies 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

43
(No Transcript)
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 todays 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 [phone],
evanoffm_at_mantech-wva.com
51
www.oasis-open.org
ANSWERS?

• Common definition?
• Is SOA concrete?
• What interop features exist?
• Any hindrances to interop?
• Improvements in SOA needed?