Copyright © 2008 Model Driven Solutions. Standards for Service Architectures SOA for e-Government...

Copyright © 2008 Model Driven Solutions.

Standards for Service Architectures

SOA for e-Government Conference

Cory Casanave

cory-c (at) modeldriven.com

May 2008

A division of Data Access Technologies, Inc.

Copyright © 2008 Model Driven Solutions

Topics

• Object Management Group (OMG) Modeling Standard Efforts for SOA

• SOA and Model Driven Architecture (MDA)

• Overview of SOA-Pro by Example

• Tie to Web Services – Executable Architectures

• Model Driven Solutions


Who Are OMG?

Adaptive

BEA

Borland

Boeing

CA

Citigroup

Compuware

DaimlerChrysler

Data Access

EDS

Everware

Fujitsu

GSA

Harris

Hewlett Packard

Hitachi

IBM

io Software

Kennedy Carter

Kaiser Permanente

klocwork

Metamatrix

Model Driven Solutios

NASA

NEC

NIST

NTT DoCoMo

Northrop Grumman

OASIS

Oracle

PRISM

Sandpiper

SAP

Satyam

Select

Sun

TCS

Unisys

Visa

W3C


OMG’s Mission Since 1989

• Develop an architecture, using appropriate technology, for modeling & distributed application integration, guaranteeing:

– reusability of components– interoperability & portability– basis in commercially available software

• Specifications freely available

• Implementations exist

• Member-controlled not-for-profit

• See more at: www.OMG.org


What is Model Driven Architecture?

• A Better Way to Specify and Design & Develop– Based on modeling standards like UML, MOF

– Is extensible to all modeling problems

– Supports full lifecycle: analysis, design, implementation, deployment, maintenance, evolution & integration with later systems

– Builds in Interoperability and Portability

– Lowers initial cost and maximizes ROI

– MDA Models are Executable and Actionable


OMG Modeling Standards

• OMG is the première standards organization for architecture and modeling. Some OMG Specification Examples:– Model Driven Architecture (MDA)– Unified Modeling Language (UML)– Business Process Modeling Notation (BPMN)– Systems Modeling Language (SysML)– Meta-Object Facility for Metadata Management (MOF)– Enterprise Distributed Object Computing (EDOC)– Common Object Request Broker (Corba)– Semantics of Business Vocabulary and Rules (SBVR)– Business Motivation Model (BMM)– Records Management (RM)– Air Traffic Control– Federal Transition Framework (FTF)


Current SOA Related Standards

• Unified Modeling Language (UML-2)– Provides basis for modeling, but little specific to SOA. “Out of the

box” it is hard to know how to use UML for SOA or business modeling and has no support for mapping to web services

• Enterprise Distributed Object Computing (EDOC)– Encompasses many SOA concepts but pre-dates SOA and UML-2

– concepts are being merged into newer standards

• Business Process Definition Metamodel (BPDM)– Pure meta model for BPM and some SOA concepts – SOA part

does not have a diagram standard people can readily use – this is being addressed in BPMN-2

• Conclusion – Current modeling standards do not sufficiently address SOA


SOA-Pro & UPMS

• This presentation is largely a preview of SOA-Pro, the proposed standard expected to come out of the current UPMS processes.

• The UML Profile and Metamodel for Services (UPMS) standards process in in the final stages – adoption can be expected well within this year.

• The discussions are largely over – all the submitters have merged on a common approach and are now working on the final document.

• Submitting team:– 88Solutions, Adaptive, Azora, BAE, CapGemini, EDS, – France Telecom, Everware, GSA, Hewlett Packard, Inherit, – Mega International, Model Driven Solutions, Syntef, – TALES Group, Telelogic

• An early version of SOA-Pro is already in use within the government – in the GSA’s Financial Management Architecture.


What you can expect out of SOA-Pro

• A “UML Profile” which specifies how to use UML for SOA and tailors UML tools for SOA modeling

• A UML Metamodel – which will provide a standard XML exchange format for service architectures

• Separation of concerns between the business systems and technology architectures – executable SOA specifications

• A (non normative) mapping to Web Services – so that Web Service specifications can be generated from a services architecture and Web Services can be reverse engineered into an architecture.

• SOA-Pro will support a variety of SOA methodologies and technology architectures. Commercial and Open Source Tools can then be built for Web services, Java, Corba, .NET, etc.

• SOA-Pro works both “Top Down” and “Bottom Up”.


Architecture - the <A> in SOA

• Architecture is done at two levels in SOA– The technology architecture – service distribution, message structures,

wire protocols, registries, encryption, etc.– The domain (Business/Mission/Systems of Systems) architecture –

service definition, responsibilities and how services work together to meet business needs.

• Our focus today is the domain architecture – what we call the architecture of services. The specification of services and how services work together for a purpose – to support business goals and processes.

• Technology architectures are encompassed in many exiting standards and products, this should be reusable across domains.

• Model Driven Architecture (MDA) provides mechanisms for mapping the domain architecture to the technology architecture of choice. Separation of these concerns is vital!


SOA as a Business and Technology Concept

• Business Services– Business Services connect people, organizations and systems as a

network of services. A business entity is understood in terms of the services it offers and consumes – the “supply chain”.

– The business process shows how the business entity achieves its goals, using and supplying services.

• Technology Services– Technology services connect systems in well defined ways to facilitate

both business services and the technology infrastructure.– Technology services should mirror and facilitate the business services

and should support business processes

• A primary goal of SOA-Pro is to “connect the dots” between the business and technology viewpoints

• SOA can help a “top down” and “bottom up” approach “meet in the middle” through services.


The enterprise as services

• Think about the enterprise as a set of interacting roles providing and using services to enable agility, cost savings and an effective transition framework

• Externally– The enterprise is part of the global supply chain, providing services

to customers and using the services of suppliers

• Internally– Consider parts of the enterprise as providing services to other parts

of the enterprise, and in term using the service of others– Like everything was outsourced as a service, it just happens to be

done inside the organization.

• Business is modeled in terms of interacting roles – providing and using services – the essential concepts of enterprise SOA


Business Concerns

Goals

Policy

Customers

Costs

Agility

Technology SpecificationJMS, JEE, Web Services

WSDL, BPEL, XML Schema



Logical System ModelTechnology Services (t-SOA),

ComponentsInterfaces, Messages & Data



Business Focused SOA Using Model Driven Architecture

Business ModelEnterprise Services (e-SOA)

Roles, Collaborations & InteractionsProcess & Information



Refin

emen

t & A

uto

matio

n

Lin

e-Of-S

igh

tC

om

pu

tati

on

Ind

epen

den

tM

od

el

Pla

tfo

rmIn

dep

end

ent

Mo

del

Pla

tfo

rmS

pec

ific

Mo

del

MDATerms


Value derived from the architecture

ComponentAcquisition Specification

TechnologyInterfaces

Test &SimulationOMB 300

FEA/FTFBRMSRMDRM*

Business Driven Technology

Facilitating Business Processes

Adapters

Components

DataDeployment

Business Concerns

Goals

Policy

Customers

Costs

Agility














Incorporating Legacy Analysis

Copyright © 2008 Model Driven Solutions.

SOA Profile by Example

Using UML for Services Architectures with the SOA Profile

Note: Some of the examples are somewhat out of date with the current proposed standard, but the differences

are minor.

Note: Some of the examples are somewhat out of date with the current proposed standard, but the differences

are minor.


Example use case

• Enable a marketplace of dealers and manufacturers with a services architecture.

• There are many dealers and manufactures that form a “community”. Each dealer may deal with many manufactures and each manufacturer can deal with many dealers. Each may use the services of many shippers.

• We want a way for dealers and manufactures to work together but not get overly “coupled” to each other. Each organization should be independent and agile. Each organization may have its own business processes and systems.

• Our job is to enable this community with a Service Oriented Architecture

• Principles:– Participants proprietary systems should be hidden behind services

– Supplying and using services according to the architecture is the way an organization participates in the community

– The growing set of services should support long-lived and multi-party services

– All relationships are peer-peer, there is no “controller” – the challenge is then reliable interoperability and collaborative behavior within this loosely coupled community

– Services should be specified independently from any technology or organizational structure


SOA Marketplace Community

Mechanics Are UsDealer

Acme IndustriesManufacturer

GetItThere FreightShipper

Order

Conformation

Ship Req

Shipped

Shipped

PhysicalDelivery

Delivered

Status


Marketplace Services




Order

Conformation

Ship Req

Shipped

Shipped

PhysicalDelivery

Delivered

Status

Provider

Consumer

ProviderC

onsu

mer

Consumer

Provider


Community Architecture for the dealer network


Focus on the middle

ServiceContract

ServiceContract

ServiceContract


Similar Example From Financial ManagementService representing

delegated responsibility for interaction with an external

participant.

Service representing delegated responsibility for interaction with an external

participant.

Service representing interaction with another

participant within Financial Management.

Service representing interaction with another

participant within Financial Management.

Roles of participants inside

of finance

Roles of participants inside

of finance


Similar Example From Financial Management


Simple Service Contract

•A Service Contract represents the terms and conditions by which a service is provided and consumed. The Service Contract is the specification of “the middle” – a collaboration between the provider and consumer.

•The service contract specifies the roles each party plays, the interfaces they offer and the behavior of enacting the service.

•The service contract is binding on those participating in the service

•The service interface types, which are the types of the roles, define the interaction points (service ports) for providing and using services.

•The service contract can “scale up” to choreographed and nested asynchronous interactions over an extended time period – which is the norm for business services. Multi-party contracts are easily supported

•The service contract (collaboration and service interfaces) are a unit – a single specification of a service without regard for implementation or dependencies.

Collaborative View

Systems Interface View


[Web] Services Implement the Services Architecture




Order

Conformation

Ship Req

Shipped

Shipped

PhysicalDelivery

Delivered

Status

WebService

WebService

WebService Web

Service

WebService


A bi-directional service contract

Collaborative View

Systems Interface

View May include conditions


Choreography for bi-directional service contract

Choreography View

Data


Compound Service Contract

•Composition reduces complexity while providing for arbitrarily complex service contracts

•Any participant can initiate any sub-service

•Can be built “top down” or “bottom up”


Compound Service Contract Interface View

Each role binding implies a portOn the role’s type

Interface can be mapping to a

technology, such as WSDL or Corba


A Services Architecture (SOA) shows how Participants Provide and Use Services for a Common Purpose.

Service Contract is USED here.


Participants

Participants can “play roles” in multiple community architectures, defining their external requirements. Each service contract they are bound to must interact through a compatible port.

Participant Participant


Inside the Manufacturer

Order

Conformation

Shipped

Ship Req

Shipped

Delivered

Order Processing

Shipping

Production

Event

WebService

WebService

WebService

WebService

WebService

WebService

WebService

WebService


Inside the manufacturer, Participant Architecture


There was an existing Productions service that we can reuse

Imported From anExisting

Web Service


Completed Service Component Architecture for Order Processing


Business Concerns

Technology Architecture

Technology SpecificationJEE, JMS, Web Services




Business ModelBusiness Services (b-SOA)



Example Web Services Generation

<wsdl:portType name=“BillSubmission.BillSubmissionReceiverInterface"> <wsdl:operation name=“submitBill"> <wsdl:input message="tns:BillSubmissionCluster“ name=“billSubmission"> </wsdl:input> </wsdl:operation> </wsdl:portType>

<wsdl:portType name=“BillSubmission.BillSubmissionSubmitterInterface"> <wsdl:operation name=“notifyBillDelivered"> <wsdl:input message="tns:BillDeliveredCluster“ name=“billDelivered"> </wsdl:input> </wsdl:operation> <wsdl:operation name=“notifyBillReturned"> <wsdl:input message="tns:BillReturnedCluster“ name=“billReturned"> </wsdl:input> </wsdl:operation> </wsdl:portType>


Example Transaction Message XML Document<BillSubmissionCluster>

<BusinessTransaction><transactionID> … </transactionID>

</BusinessTransaction><BillSubmission>

<bill><Bill>

<billID> … </billID><principleAmount> … </principleAmount>…

<payer><Party>

<partyID> … </customerID></Party>

</payer>…

<lineItems> … </lineItems>

</Bill> </bill>

<billingAddress><BillingAddressCluster>

<Address> … </Address><BillingAddress> … </BillingAddress>

</BillingAddressCluster><billingAddress>

</BillSubmission></BillSubmissionCluster>

<BillSubmissionCluster><BusinessTransaction>

<transactionID> … </transactionID></BusinessTransaction><BillSubmission>

<bill><Bill>

<billID> … </billID><principleAmount> … </principleAmount>…

<payer><Party>

<partyID> … </customerID></Party>

</payer>…

<lineItems> … </lineItems>

</Bill> </bill>

<billingAddress><BillingAddressCluster>

<Address> … </Address><BillingAddress> … </BillingAddress>

</BillingAddressCluster><billingAddress>

</BillSubmission></BillSubmissionCluster>


Mapping to Web Services



public class Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal {

……

static public Document establish_asset_record(Document request) throws CheckedException {

… …

// for an inbound operation, determine if we delegate or execute

return

gov.gsa.fmea.Asset_Record_Establishment_Transaction_Manager.

Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal.

establish_asset_record(request);

public class Asset_Record_Establishment_ProviderAsset_Record_Establishment_Provider_InterfaceInternal{

… …

static public Document establish_asset_record(Document request) throws CheckedException {

… …

// for an inbound operation, determine if we delegate or execute

return ServiceFactory.getPipeline("Asset_Record_Establishment_Transaction_Manager.

Asset_Record_Establishment_Provider.establish_asset_record.Pipeline").execute(request);

}

Asset_Project_Status_Notification_Transaction_Manager.Asset_Project_Status_Notification_Provider.notify_asset_project_status..xslt

… …



<xsl:sequence select="mdf:Asset_Project_Status_Notification_Transaction_Manager.Asset_Completion_Establishment_Consumer.establish_asset_completion.UsageOut.codehole($changes,$validation.results,$transformedBusinessMessage)"/>

… …

Asset_Project_Status_Notification_Transaction_Manager.Asset_Completion_Establishment_Consumer.establish_asset_completion..xslt

… …

<xsl:function name="mdf:Asset_Project_Status_Notification_Transaction_Manager.Asset_Completion_Establishment_Consumer.establish_asset_completion.UsageOut"

as="node() ?">

<xsl:param name="documentFragment" as="node() ?"/>

<xsl:variable name="document.out">

<xsl:apply-templates select="$documentFragment" mode="mdf.schema.copy">

<xsl:with-param name="namespace"

select="'http://www.modeldriven.org/xsd/FMEA_Asset_Accounting_Implementation_Model.uml/Asset_Completion_Establishment_Message_Elements'"/>

</xsl:apply-templates>

</xsl:variable>

<xsl:sequence select="Asset_Completion_Establishment_ConsumerAsset_Completion_Establishment_Provider_InterfaceInternal:establish_asset_completion($document.out)"/>

</xsl:function>

… …


Information model to XML Schema

<Party__Schema identity=”URI”><Party>

<party_id>ABC123<party_id><legal_address>

<Address><city>Vienna</city><state>VA</state>

</Address></legal_address><organizations>

<Organization__Item identity=”http://ocfo.gsa.gov/fmea/organization/1”/><Organization__Item identity=”…”/>…

</organizations></Party>

</Party__Schema>

<Party__Schema identity=”URI”><Party>

<party_id>ABC123<party_id><legal_address>

<Address><city>Vienna</city><state>VA</state>

</Address></legal_address><organizations>

<Organization__Item identity=”http://ocfo.gsa.gov/fmea/organization/1”/><Organization__Item identity=”…”/>…

</organizations></Party>

</Party__Schema>

<Organization__Schema identity=”http://ocfo.gsa.gov/fmea/organization/1”><Organization>

<approved>true</approved>…

</Organization></Party__Schema>

<Organization__Schema identity=”http://ocfo.gsa.gov/fmea/organization/1”><Organization>

<approved>true</approved>…

</Organization></Party__Schema>


Conclusion

• SOA-Pro takes SOA to the next level, embracing the full life-cycle of business, systems of systems and technology services.

• Having industry standards for SOA at the architecture level will help make the transition to SOA easier and provide a better link to business requirements and SOA governance

• Modeling “above” the technology makes a SOA more approachable for our business stakeholders and able to withstand technology change.

• The combination of SOA-Pro with Web Services provides for a comprehensive System of Systems approach


Model Driven Solutions

• Full Life-Cycle Executable Architectures– Enterprise Architecture– Model Driven Architecture– Service Oriented Architecture– Business Architecture– System of Systems Architecture– Systems & Solutions Architecture– Business Process Architecture– Federal Enterprise Architecture– Semantic Web

• Model Driven SOA Implementation

• Open Source Tools & Infrastructure

• SOA Transformations for a more effective Enterpise

Copyright © 2008 Model Driven Solutions. Standards for Service Architectures SOA for e-Government...

Documents

Transcript of Copyright © 2008 Model Driven Solutions. Standards for Service Architectures SOA for e-Government...