copyright © 2008 model driven solutions. standards for service architectures soa for e-government...
TRANSCRIPT
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.
Page 2 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
Page 3 Copyright © 2008 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
Page 4 Copyright © 2008 Model Driven Solutions
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
Page 5 Copyright © 2008 Model Driven Solutions
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
Page 6 Copyright © 2008 Model Driven Solutions
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)
Page 7 Copyright © 2008 Model Driven Solutions
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
Page 8 Copyright © 2008 Model Driven Solutions
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.
Page 9 Copyright © 2008 Model Driven Solutions
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”.
Page 10 Copyright © 2008 Model Driven Solutions
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!
Page 11 Copyright © 2008 Model Driven Solutions
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.
Page 12 Copyright © 2008 Model Driven Solutions
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
Page 13 Copyright © 2008 Model Driven Solutions
Business Concerns
Goals
Policy
Customers
Costs
Agility
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
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
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
Page 14 Copyright © 2008 Model Driven Solutions
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
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Technology SpecificationJMS, JEE, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Business ModelEnterprise Services (e-SOA)
Roles, Collaborations & InteractionsProcess & Information
Business ModelEnterprise Services (e-SOA)
Roles, Collaborations & InteractionsProcess & Information
Page 15 Copyright © 2008 Model Driven Solutions
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.
Page 17 Copyright © 2008 Model Driven Solutions
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
Page 18 Copyright © 2008 Model Driven Solutions
SOA Marketplace Community
Mechanics Are UsDealer
Acme IndustriesManufacturer
GetItThere FreightShipper
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
Page 19 Copyright © 2008 Model Driven Solutions
Marketplace Services
Mechanics Are UsDealer
Acme IndustriesManufacturer
GetItThere FreightShipper
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
Provider
Consumer
ProviderC
onsu
mer
Consumer
Provider
Page 20 Copyright © 2008 Model Driven Solutions
Community Architecture for the dealer network
Page 21 Copyright © 2008 Model Driven Solutions
Focus on the middle
ServiceContract
ServiceContract
ServiceContract
Page 22 Copyright © 2008 Model Driven Solutions
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
Page 23 Copyright © 2008 Model Driven Solutions
Similar Example From Financial Management
Page 24 Copyright © 2008 Model Driven Solutions
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
Page 25 Copyright © 2008 Model Driven Solutions
[Web] Services Implement the Services Architecture
Mechanics Are UsDealer
Acme IndustriesManufacturer
GetItThere FreightShipper
Order
Conformation
Ship Req
Shipped
Shipped
PhysicalDelivery
Delivered
Status
WebService
WebService
WebService Web
Service
WebService
Page 26 Copyright © 2008 Model Driven Solutions
A bi-directional service contract
Collaborative View
Systems Interface
View May include conditions
Page 27 Copyright © 2008 Model Driven Solutions
Choreography for bi-directional service contract
Choreography View
Data
Page 28 Copyright © 2008 Model Driven Solutions
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”
Page 29 Copyright © 2008 Model Driven Solutions
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
Page 30 Copyright © 2008 Model Driven Solutions
A Services Architecture (SOA) shows how Participants Provide and Use Services for a Common Purpose.
Service Contract is USED here.
Page 31 Copyright © 2008 Model Driven Solutions
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
Page 32 Copyright © 2008 Model Driven Solutions
Inside the Manufacturer
Order
Conformation
Shipped
Ship Req
Shipped
Delivered
Order Processing
Shipping
Production
Event
WebService
WebService
WebService
WebService
WebService
WebService
WebService
WebService
Page 33 Copyright © 2008 Model Driven Solutions
Inside the manufacturer, Participant Architecture
Page 34 Copyright © 2008 Model Driven Solutions
There was an existing Productions service that we can reuse
Imported From anExisting
Web Service
Page 35 Copyright © 2008 Model Driven Solutions
Completed Service Component Architecture for Order Processing
Page 36 Copyright © 2008 Model Driven Solutions
Business Concerns
Technology Architecture
Technology SpecificationJEE, JMS, Web Services
WSDL, BPEL, XML Schema
Logical System ModelTechnology Services (t-SOA),
ComponentsInterfaces, Messages & Data
Business ModelBusiness Services (b-SOA)
Roles, Collaborations & InteractionsProcess & Information
Page 37 Copyright © 2008 Model Driven Solutions
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>
Page 38 Copyright © 2008 Model Driven Solutions
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>
Page 39 Copyright © 2008 Model Driven Solutions
Mapping to Web Services
Page 40 Copyright © 2008 Model Driven Solutions
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);
}
Page 41 Copyright © 2008 Model Driven Solutions
Mapping to Web Services
Asset_Project_Status_Notification_Transaction_Manager.Asset_Project_Status_Notification_Provider.notify_asset_project_status..xslt
… …
<!--message publish: send results to outgoing operations-->
<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>
… …
Page 42 Copyright © 2008 Model Driven Solutions
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>
Page 43 Copyright © 2008 Model Driven Solutions
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
Page 44 Copyright © 2008 Model Driven Solutions
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