OMG SOA SIG Update: OMGÕs Value Proposition for - SOA Home Page


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • A contract between clients and implementations What roles are played by requestors and providers What they are responsible for The rules or protocol for how they interact Variability handled by: Properties or configuration parameters (control couples again) Delegation Inheritance Patterns Doesn’t directly deal with some important IT concerns Distribution, persistence, transactions, security, QoS, User Experience Doesn’t handle dynamic systems well Have to know complete behavior at development time Can handle some variability through polymorphism, delegation, and state machines But still have to know all possible behavior scenarios at development time Adding new behavior or changing behavior requires rebuilding and redeploying Solutions were static and difficult to change
  • Provide a manageable scope, define core needed to address these additional concerns perhaps in parallel. Most other concerns deal with service discovery, qualities of service or runtime execution.
  • ODM – capture semantics of a domain of interest BMM, OSM, SBVR, BPMN and BPDM – capture business requirements UML2 – The foundation for services modeling with use case, structural and behavioral modeling KDM, IMM – may be relevant for service data modeling RAS – used to describe services as reusable assets
  • How it answers the questions customers often ask… Successive Realization is different than Successive Elaboration in that it is based on formal specification contracts that capture a set of concerns which are then realized by fulfilling the contract while addressing another set of (often lower-level) concerns. These realizations also have formal semantics that tie the pieces together in a manner that is verifiable, repeatable, traceable, and provides rich information for model-to-model and model-to-code transformations.
  • Informal requirements (leading to loose contract fulfillment)
  • Formal requirements representing a possible Service Level Agreement (leading to strict contract fulfillment).
  • The services contract is a collaboration that specifies: What fulfillers are intended to accomplish - Implied by the name of the contract The participants that are required to achieve the intended results – the roles of the collaboration The responsibilities the roles must be prepared to perform – the types of the roles, generally interfaces listing operations representing the responsibilities The connectors between the roles indicate there is some interaction between those roles, they require services of each other. This indicates a coupling in the model. The rules for how the roles interact – a behavior (activity, interaction, state machine, or code) specifying when the roles perform their responsibilities In this case, the services contract is a view of the original business process: The contract corresponds to the process and has the same name The participating roles correspond to the swimlanes in the process The role responsibilities correspond to the definitions of the tasks assigned to those roles (the tasks that are in the swimlanes) The connectors between the roles correspond to control or information flows that cross swimlanes. The rules for how the roles interact is a UML view of the BPMN process (could be shown using BPMN notation on UML or any other way that is semantically equivalent)
  • Rules are captured as an ownedBehavior of the service contract Collaboration that indicates the choreography or communication protocol between participating roles.
  • org::odermanagement – contains the OrderProcessor component which provides the purchase order processing services org::crm – contains the data model and common interfaces for some envisioned Customer Relationship Management standard that service consumers and service providers have agreed upon for developing shared services. This and the following packages would probably use a different model for each of the service specifications. In this example they are kept in the PurchaseOrderProcess model in order to keep the example simple. com::acme::credit – service interfaces and service providers for credit management services. com::acme::productions – services interfaces and service providers for production management and scheduling services com::acme::shipping – service interfaces and service providers for shipping services
  • Customer is both a persistent entity, and a data transfer object exchanged between service consumers and providers. This means the Customer class represents two different usages of the data in different contexts.
  • Looking at the services contract, we find, build or adapt service providers capable of playing the roles in the contract. The Invoicer service provider provides the invoicing service This service provides the Invoicing interface and requires the InvoiceProcessing interface The protocol for using this service is captured in the protocol for the port The protocol is a collaboration that specifies the roles involved (generally just the consumer and producer) A behavior of the profile specifies the rules for how these roles interact
  • Shipper is a service specification. It is realized by the ShipperImpl component.
  • The collaboration use indicates what contract the provider fulfills. The role bindings specify what roles the parts of the provider play in the contract. This provides formal, verifiable, traceability between the business requirements and the services solution without introducing undue coupling between them.
  • Notice that the part shipper is of type Shipper which is a specification. OrderProcessing is therefore an incomplete assembly. Some performer realizing the Shipper specification must be added to the assembly, perhaps at deploy or even run time.
  • The invoicing port of the orderProcessor (initiating the conversation) is playing the consumer orderer role. It invokes and responds to service operations according to the InvoicingProtocol The invoicing port of the invoicer playes the provider invoicing role in the protocol The implementation of service operations (i.e. service methods) in OrderProcessor follow this protocol The contract for the service channel connector between the consumer and provider ports is the invoicing collaboration use (need a change in UML2 to support this) The invoicing collaboration use need not be shown explicitly as it is implied by the type of the provider port’s type.
  • OMG SOA SIG Update: OMGÕs Value Proposition for - SOA Home Page

    1. 1. UML Profile and Metamodel for Services RFP UPMS “Services Metamodel” Overview and Status Jim Amsden, IBM 28-Sep-2006
    2. 2. Problem Statement – Standards driven by business needs <ul><li>Globalization, rapid change, the Internet and the “Flat World” stimulating business innovation and integration </li></ul><ul><ul><li>Each business unit to focus on their key value while leveraging capabilities provided by others for non-core functions </li></ul></ul><ul><ul><li>Requires business agility to respond to market opportunities and challenges </li></ul></ul><ul><li>Evolution in the business parallels evolution in IT solutions </li></ul><ul><ul><li>Complexity Management </li></ul></ul><ul><ul><li>The ability to respond to dynamic change </li></ul></ul><ul><ul><li>Modularity </li></ul></ul><ul><ul><li>Encapsulation </li></ul></ul><ul><ul><li>Separation and integration of concerns </li></ul></ul><ul><ul><li>Deferred commitment </li></ul></ul><ul><ul><li>Solutions through composition of other solutions </li></ul></ul><ul><ul><li>Adaptability </li></ul></ul><ul><ul><li>Reuse </li></ul></ul><ul><li>Each evolutionary step introduces additional capabilities for separation of concerns, loose coupling, and late binding </li></ul>
    3. 3. Facing Business and IT challenges requires SOA <ul><li>A framework for matching needs and capabilities, and combining capabilities to meet needs through services </li></ul><ul><li>A foundation enabling business agility and adaptability </li></ul><ul><li>Promote reuse, growth and interoperability to realize the value inherent in individual assets </li></ul><ul><li>Reflects continuing evolution of computing models to enable reuse and reduce coupling </li></ul><ul><li>Greater focus on separation of concerns and delegation </li></ul><ul><li>Minimize trust and connection assumptions </li></ul><ul><ul><li>Ownership, distribution and implementation </li></ul></ul>
    4. 4. BPM and SOA can help realize business agility <ul><li>Clear separation of the Business operations from services solutions </li></ul><ul><li>Enable integration at the business and IT solution levels independently </li></ul><ul><li>BPM captures and validates business organizational and operational requirements and constraints </li></ul><ul><li>SOA enables flexible solutions to business requirements </li></ul>
    5. 5. But there is a proliferation of protocols, specifications, metamodels and tools <ul><li>Many are incompatible with each other </li></ul><ul><li>SOA platforms are in immature and rapidly changing </li></ul><ul><li>OASIS SOA Reference Model has only just been completed </li></ul><ul><li>As a result it will be harder for companies to realize the BPM and SOA potential </li></ul><ul><li>Without costly conversion tools and runtime adapters and mediators </li></ul><ul><ul><li>Higher development costs </li></ul></ul><ul><ul><li>Requirement for more skilled developers </li></ul></ul><ul><ul><li>Bloat in both development and runtime platforms </li></ul></ul><ul><ul><li>Increased potential for bugs </li></ul></ul>
    6. 6. What is needed is a new Services Standard <ul><li>Enable interoperability and integration at the model level </li></ul><ul><li>At a higher-level of abstraction separate from platform variability </li></ul><ul><li>Address business integration and service interaction concerns at the architectural level </li></ul><ul><ul><li>Architecture is the bridge between the business requirements and IT solutions </li></ul></ul><ul><li>Enable SOA on existing platforms through MDA </li></ul><ul><li>Allows for flexible platform choices </li></ul><ul><li>While preventing existing solutions from inhibiting platform evolution </li></ul><ul><li>Leverage and integrate with existing OMG standards for end-to-end lifecycle development and management </li></ul>
    7. 7. Why WS-* is too much and not enough <ul><li>Semantically thin specifications </li></ul><ul><li>Rapidly evolving specifications, likely to be more churn </li></ul><ul><li>Relatively low-level abstraction rooted in XML </li></ul><ul><ul><li>Communication may be local or remote </li></ul></ul><ul><li>Focused on wire protocols, data interchange, and execution environments </li></ul><ul><li>Represent only one of may possible SOA realizations </li></ul><ul><li>Many standards focused on individual technology segments </li></ul><ul><li>Interdependencies and relationships result from overlaps and gaps </li></ul><ul><ul><li>Leads to vendor variability and interoperability issues </li></ul></ul>
    8. 9. Why UML2 is too much and not enough <ul><li>UML2 covers potentially unrelated modeling domains </li></ul><ul><ul><li>UseCases for requirements </li></ul></ul><ul><ul><li>Many different styles of behavioral modeling </li></ul></ul><ul><ul><li>Deployment modeling </li></ul></ul><ul><ul><li>Many other modeling constructs </li></ul></ul><ul><ul><li>Not particularly service centered </li></ul></ul><ul><li>Need a realization of SOA reference model independent of SOA implementation strategies </li></ul><ul><li>Need better definition of service contracts independent of SOA design </li></ul><ul><li>Need more formal separation of specification and realization </li></ul><ul><li>Need location and binding information for modeling service interactions (because of reduced coupling in a distributed environment) </li></ul><ul><li>Idempotent, long-running, compensation semantics </li></ul>
    9. 10. Component Based Development <ul><li>Separates component specification from realization </li></ul><ul><ul><li>Clients only depend on the specification (interfaces) </li></ul></ul><ul><ul><li>Can substitute evolving realizations to fix bugs or add new features </li></ul></ul><ul><ul><li>Specification captures one set of concerns </li></ul></ul><ul><ul><li>Realization addresses those concerns while handling others </li></ul></ul><ul><li>Adds ports for better encapsulation and isolation </li></ul><ul><ul><li>Better decoupling between requestors and providers </li></ul></ul><ul><ul><li>Component client only depends on what they need not the whole component </li></ul></ul><ul><li>Provides a better unit of reuse </li></ul><ul><ul><li>Component is an autonomous entity </li></ul></ul><ul><ul><li>Specifies what it provided and what is necessary for its use </li></ul></ul><ul><ul><li>More formal support for commonality and variability </li></ul></ul>
    10. 11. Service Oriented Architectures were introduced to: <ul><li>Addresses the effect of application integration across ownership boundaries </li></ul><ul><li>Use Service Level Agreements to capture contracts </li></ul><ul><li>Extends CBD with additional distributed computing and deployment concerns </li></ul><ul><li>Provide more reflective and dynamic systems </li></ul><ul><ul><li>Behavior can come and go </li></ul></ul><ul><ul><li>Clients query for service with acceptable QoS </li></ul></ul><ul><ul><li>Raise exceptions if none found </li></ul></ul><ul><li>Include concepts for publishing, finding, and dynamically binding to services </li></ul><ul><li>Driven by practical implications of the Web and existing middleware platforms </li></ul><ul><ul><li>Integration between J2EE and .Net </li></ul></ul>
    11. 12. This is a good time for OMG to enter the SOA landscape <ul><li>There is common recognition of Business value of SOA </li></ul><ul><li>The importance of WS-* or Web Services as enabling SOA technology is well established </li></ul><ul><li>There are any existing OMG standards that are applicable to SOA </li></ul><ul><li>There is an opportunity for OMG to contribute in order to: </li></ul><ul><ul><li>Make it SOA easier to development, understand and manage </li></ul></ul><ul><ul><li>Provide a more stable SOA environment (through abstraction and separation of concerns) </li></ul></ul><ul><ul><li>Enable business value through standards for agile processes and supporting technologies </li></ul></ul><ul><li>This will be necessary to achieve: </li></ul><ul><ul><li>Interoperability necessary for business integration </li></ul></ul><ul><ul><li>Growth in marketplace of reusable services </li></ul></ul>
    12. 13. Goals of the RFP <ul><li>A common vocabulary and metamodel to unify the diverse service definitions that exist in the industry. </li></ul><ul><li>Clarify UML semantics concerned with services modeling and establish modeling best practices. </li></ul><ul><li>Complement existing UML metamodel by defining an extension to UML to ensure complete and consistent service specifications and implementations. </li></ul><ul><li>Integrate with and complement standards developed by other organizations such as W3C and OASIS </li></ul><ul><li>Support a service contract describing the collaboration between participating service consumers and service providers </li></ul><ul><ul><li>clearly separate service requirements and specification from realization. </li></ul></ul><ul><li>Enable traceability between contracts specifying services requirements, service specifications that fulfill those requirements and service providers that realize service specifications. </li></ul><ul><li>Facilitate the adoption of Service Oriented Architectures through </li></ul><ul><ul><li>more abstract and platform independent services models to speed service development, </li></ul></ul><ul><ul><li>decouple service design from evolving implementation, deployment and runtime technologies, and </li></ul></ul><ul><ul><li>enable generation of platform specific artifacts. </li></ul></ul><ul><li>The ability to exchange services models between tools using XMI.   </li></ul>
    13. 14. Out of scope – for future RFPs <ul><li>Methodologies for service design. </li></ul><ul><li>Services governance or compliance. </li></ul><ul><li>Service metrics, policy, security, trust, performance, or other Qualities of Services </li></ul><ul><li>Wire protocols and/or message transfer encodings or marshalling. </li></ul><ul><li>Message delivery reliability, transaction scopes, or other mechanisms for managing data integrity. </li></ul><ul><li>Service brokering, publishing, discovery, service addressing, service registries, asset management. </li></ul><ul><li>Service runtime configuration and deployment. </li></ul><ul><li>Dynamic binding, service federation, mediation, service bus structure, or other service execution concerns. </li></ul><ul><li>User experience or user interfaces. </li></ul>Focus first on Service Capture
    14. 15. Where the Services Metamodel fits into SOA Atomic Service Composite Service Registry Services atomic and composite Operational Systems Service Components Consumers Business Process Composition; choreography; business state machines Service Provider Service Consumer Integration (Enterprise Service Bus) QoS Layer (Security, Management & Monitoring Infrastructure Services) Data Architecture (meta-data) & Business Intelligence Governance Packaged Application Custom Application OO Application Channel B2B Software Services Metamodel
    15. 16. Relationship to existing OMG specifications <ul><li>ODM </li></ul><ul><li>BMM, OSM, SBVR,BPMN and BPDM </li></ul><ul><li>UML2, OCL, EDOC </li></ul><ul><li>KDM, IMM </li></ul><ul><li>MOF, QVT, XMI </li></ul><ul><li>ODM, RAS </li></ul>
    16. 17. Relationship to other specifications <ul><li>OASIS Reference Model for Service Oriented Architecture </li></ul><ul><li>XSD Specification </li></ul><ul><li>Service Data Objects Specification </li></ul><ul><li>WSDL Specification </li></ul><ul><li>Service Component Architecture Specification </li></ul><ul><li>WSBPEL Specification </li></ul><ul><li>FEA Service Component Reference model (SRM) </li></ul><ul><li>FEA Services and Components Based Architectures (SCBA) </li></ul><ul><li>ebXML </li></ul>
    17. 18. Mandatory Requirements <ul><li>MOF metamodel and equivalent UML2 profile </li></ul><ul><li>Extend, but not conflict with UML semantics </li></ul><ul><li>Notation icons for services extensions </li></ul><ul><li>Platform independent </li></ul><ul><li>Non-normative mapping to Web Services </li></ul>
    18. 19. Service Contracts <ul><li>Specify service contracts (architecturally neutral) </li></ul><ul><ul><li>Interactions between service consumers and providers </li></ul></ul><ul><ul><li>Realize use cases (for requirements) </li></ul></ul><ul><ul><li>Specified functions </li></ul></ul><ul><ul><li>Participants and the roles they play </li></ul></ul><ul><ul><li>Responsibilities of participating roles </li></ul></ul><ul><ul><li>Behavioral rules for how roles must interact </li></ul></ul><ul><ul><li>Constraints for objectives that must be met </li></ul></ul><ul><li>Service contract semantically equivalent to BPDM choreography and collaborations </li></ul><ul><li>Service specifications and providers fulfill service contracts </li></ul><ul><li>Loose and strict contract fulfillment </li></ul><ul><li>Use of service contracts is optional </li></ul>
    19. 20. Service Specification <ul><li>Separate for how services are provided or implemented </li></ul><ul><ul><li>Provided and required service interfaces </li></ul></ul><ul><ul><li>Service operations (distributed, concurrent) </li></ul></ul><ul><ul><li>Operation pre and post conditions, parameters and exceptions </li></ul></ul><ul><ul><li>Constraints service providers must honor </li></ul></ul><ul><ul><li>Interaction points through which consumers and providers connect </li></ul></ul><ul><ul><li>Behaviors service operation methods indicating required semantics of realizing service providers </li></ul></ul><ul><li>Use of service specifications is optional </li></ul>
    20. 21. Service Data <ul><li>Structural information exchanged between service consumers and service providers </li></ul><ul><li>Attachments for opaque information </li></ul><ul><li>Usage semantics make no assumptions with regard to global synchronization, control or shared address spaces </li></ul>
    21. 22. Service Invocation and Event Handling <ul><li>Support synchronous and asynchronous service invocation </li></ul><ul><li>Synchronicity is a property of the invocation, not the service definition </li></ul><ul><ul><li>Clients determine how services are used </li></ul></ul><ul><li>Designate the ability to receive an event </li></ul><ul><li>Generate events targeted at a specific service provider or broadcast to interested providers </li></ul><ul><li>Service operations responding to events are asynchronous, have no outputs, and may raise exceptions </li></ul>
    22. 23. Service Parameters, Consumers and Providers <ul><li>Parameter types are primitive types or service data </li></ul><ul><li>Designate service consumer and services required </li></ul><ul><li>Designate service provider and services provided </li></ul><ul><li>Services only provided through interaction points, not direct connections between service consumers and service providers </li></ul><ul><li>Service provider may realize zero or more service specifications </li></ul><ul><li>Service provider must be conformant to all realized service specifications </li></ul><ul><li>Interaction point of a service provider provides and/or requires one or more service interfaces </li></ul><ul><li>Service provider specifies binding information applicable to all interaction points </li></ul><ul><li>Interaction point can restrict or extend service bindings </li></ul>
    23. 24. Service Realizations and Composition <ul><li>Specify realizations of provided service operations through owned method behaviors of service provider </li></ul><ul><li>Multiple styles for specifying method behaviors – Activity, Interaction, StateMachine, ProtocolStateMachine, OpaqueBehavior, etc. </li></ul><ul><li>Method behavior style may differ from that used by its specification </li></ul><ul><li>Specify how services are composed from other services </li></ul><ul><li>No assumptions about or constraints on the number of recursive levels of composed services, or arbitrary distinctions between composition levels. </li></ul>
    24. 25. Connecting Service Consumers and Providers <ul><li>Service channels for connecting between usages of service consumers and service providers in some containing element </li></ul><ul><li>Support different degrees of coupling between consumers and providers through service provider specified as: </li></ul><ul><ul><li>A service interface </li></ul></ul><ul><ul><li>A service specification </li></ul></ul><ul><ul><li>A particular (concrete) service provider </li></ul></ul><ul><li>Service channel selects from bindings expected by service consumer and provided by service provider </li></ul>
    25. 26. Extensibility and Service Partitions <ul><li>Enable customization and extending services through </li></ul><ul><ul><li>Configuration properties (profile markings) </li></ul></ul><ul><ul><li>Refinement and redefinition through generalization </li></ul></ul><ul><ul><li>Pattern or template specification and instantiation </li></ul></ul><ul><li>Put service specifications and/or providers into logical groupings for organization and management </li></ul><ul><li>Specify constraints on service connections between service partitions. </li></ul>
    26. 27. Service Model Interchange <ul><li>Service model interchange through XMI </li></ul><ul><li>Service models captured by the services metamodel are exchanged according to MOF-to-XMI mapping rules </li></ul><ul><li>Service models captured by the services UML2 profile are exchanged according to the UML rules for exchanging instances of UML models with applied profiles </li></ul><ul><li>Define interchange compliance levels for each of these XMI document formats </li></ul>
    27. 28. Optional Requirements <ul><li>Additional non-normative mappings to existing platforms and languages for service specification and/or execution </li></ul><ul><li>Specify preferred encoding for service data exchange </li></ul><ul><li>Binding metamodel </li></ul>
    28. 29. Issues to discuss <ul><li>Relationship of submission and UML to demonstrate semantic consistency </li></ul><ul><li>How the specification supports automated consistency checks for model validation </li></ul><ul><ul><li>Especially between service contracts and the service specifications and providers that realize them </li></ul></ul><ul><li>Applicability to ESB and common runtime architectures </li></ul><ul><li>Relationship to UDDI </li></ul>
    29. 30. Example – a Purchase Order Process <ul><li>Taken from the WSBPEL (BPEL4WS) specification </li></ul><ul><li>Illustrative only – not intended to suggest any particular submission requirements or recommendations </li></ul><ul><li>The intention is only to illustrate and clarify the submission requirements </li></ul><ul><li>Captured using IBM Rational Software Architect </li></ul>
    30. 31. A simple Business Driven Development Process
    31. 32. Business Motivation/Objectives <ul><li>Establish a common means of processing purchase orders. </li></ul><ul><li>Ensure orders are processed in a timely manner, and deliver the required goods. </li></ul><ul><li>Help minimize stock on hand. </li></ul><ul><li>Minimize production and shipping costs </li></ul>A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. The goals of this project are to:
    32. 33. Business Organizational and Operational Requirements
    33. 34. Business Organizational and Operational Requirements
    34. 35. Service Requirements Contract – from the BPMN process
    35. 36. The rules for how the role interact
    36. 37. We now switch to modeling the services solution
    37. 38. Production scheduling services
    38. 39. org::crm::domain defines the domain information model <ul><li>Domain data used in the implementation of services </li></ul><ul><li>Entities are often persisted in some data source </li></ul><ul><li>Each entity must have properties that can be used to distinguish different instances </li></ul><ul><li>Some entities can also be used as messages </li></ul>
    39. 40. This domain data can also be used to populate messages <ul><li>Messages are data exchanged between service consumers and providers </li></ul><ul><li>Messages may be views on the domain data (selections and projections) </li></ul><ul><li>These views have to be mapped to the domain data somehow </li></ul><ul><li>Service implementations can be responsible for moving data between messages and domain entities </li></ul>
    40. 41. Invoicing services
    41. 42. The rules or protocol for orderer interaction with invoicing <ul><li>The protocol is captured in an ownedBehavior of the Collaboration that is the type of the port </li></ul><ul><li>It models the conversation, protocol or interaction between consumer and provider </li></ul><ul><li>The protocol could be an: </li></ul><ul><ul><li>Interaction </li></ul></ul><ul><ul><li>Activity </li></ul></ul><ul><ul><li>StateMachine </li></ul></ul><ul><ul><li>ProtocolStateMachine </li></ul></ul><ul><ul><li>OpaqueBehavior </li></ul></ul><ul><li>There could be more than one interaction between the consumer and provider </li></ul><ul><ul><li>The Collaboration would have a different ownedBehavior for each one </li></ul></ul><ul><li>The behavior’s specification is the provided operation that is invoked by the consumer </li></ul><ul><li>The contract for a Connector between the requestor and provider is a CollaborationUse whose type is this Collaboration </li></ul>
    42. 43. Shipping services
    43. 44. The protocol for the shipping service
    44. 45. OrderProcessor external or “black box” view
    45. 46. The OrderProcessor internal structure or “white box” view
    46. 47. The processPurchaseOrder Service Implementation
    47. 48. Fulfilling the Service Contract
    48. 49. Assembling the parts into a Deployable Subsystem
    49. 50. A closer look at invoicing and how the protocol is satisfied
    50. 51. Summary
    51. 52. Timeline Nov 28, 2006 LOI March 2008 Final Submission Nov 19, 2007 Revised submissions due June 4, 2007 Initial submission presentations Sept 27, 2006 TC votes to issue RFP Sept 4, 2006 Preparation of RFP by TF Actual Date Event or Activity