1 / 50

SOA SIG presentation/demonstration Øystein Haugen/Arne J. Berre, SINTEF,

OMG SoaML Service oriented architecture Modeling Language - UML Profile and Metamodel for Services. SOA SIG presentation/demonstration Øystein Haugen/Arne J. Berre, SINTEF, Jim Amsden, IBM, Cory Casanave, ModelDriven Solutions. Submitters 88Solutions Adaptive EDS Model Driven Solutions

janna
Download Presentation

SOA SIG presentation/demonstration Øystein Haugen/Arne J. Berre, SINTEF,

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OMG SoaMLService oriented architecture Modeling Language - UML Profile and Metamodel for Services SOA SIG presentation/demonstration Øystein Haugen/Arne J. Berre, SINTEF, Jim Amsden, IBM, Cory Casanave, ModelDriven Solutions

  2. Submitters 88Solutions Adaptive EDS Model Driven Solutions Capgemini Fujitsu Fundacion European Software Institute Hewlett-Packard International Business Machines MEGA International MID GmbH Rhysome Softeam Telelogic AB Supporters Everware-CBDI General Services Administration VisumPoint Mega BAE Systems DERI – University of Innsbruck DFKI France Telecom R&D NKUA – University of Athens Oslo Software SINTEF THALES Group University of Augsburg Wilton Consulting Group The SoaML submission team

  3. SoaML Goals • Intuitive and complete support for modeling services in UML • Support for bi-directional asynchronous services between multiple parties • Support for Services Architectures where parties provide and use multiple services. • Support for services defined to contain other services • Easily mapped to and made part of a business process specification • Compatibility with UML, BPDM and BPMN for business processes • Direct mapping to web services • Top-down, bottom up or meet-in-the-middle modeling • Design by contract or dynamic adaptation of services • To specify and relate the service capability and its contract • No changes to UML

  4. Service • Service is defined as an offer of value to another party, enabled by one or more capabilities. • Here, the access to the service is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service contract. A service is provided by a participant acting as the provider of the service—for use by others. The eventual consumers of the service may not be known to the service provider and may demonstrate uses of the service beyond the scope originally conceived by the provider. [OASIS RM]

  5. MDA Terms Computation Independent Model Platform Independent Model Refinement & Automation Line-Of-Sight Platform Specific Model Business Focused SOA Using Model Driven Architecture Business Concerns Goals Policy Customers Costs Agility Business Model Enterprise Services (e-SOA) Roles, Collaborations & Interactions Process & Information Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Technology Specification JMS, JEE, Web Services WSDL, BPEL, XML Schema

  6. Incorporating Legacy Analysis

  7. Value derived from the architecture Component Acquisition Specification Web Services Test & Simulation OMB 300 Components FEA/FTF BRM SRM DRM* Adapters Deployment Data Business Driven Technology Facilitating Business Processes

  8. Focus on the Business Model Business Concerns Business Model Business Services (e-SOA) Roles, Collaborations & Interactions Process & Information Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema

  9. SOA Marketplace Example Physical Delivery Order Conformation Shipped Mechanics Are Us Dealer Acme Industries Manufacturer Status Ship Req Shipped Delivered GetItThere Freight Shipper

  10. Marketplace Services Physical Delivery Order Consumer Provider Conformation Shipped Mechanics Are Us Dealer Acme Industries Manufacturer Status Ship Req Consumer Consumer Shipped Provider Delivered Provider GetItThere Freight Shipper

  11. Services Architecture Purchasing service Shipping service Ship Status service A ServicesArchitecture (or SOA) is a network of participant roles providing and consumingservices to fulfill a purpose. The services architecture defines the requirements for the types of participants and service realizations that fulfill those roles. The services architecture puts a set of services in context and shows how participants work together for a community or organization without required process management. A community ServicesArchitectureis defined using a UML Collaboration.

  12. Order Processing Accounting Service Inside the Manufacturer Order Conformation Shipped Ship Req Shipped Delivered

  13. Services architecture for a participant ParticipantArchitecture is the high-level services architecture of a participant that defines how a set of internal and external participants use services to implement the responsibilities of the participant. A participant will also frequently have a business process.

  14. Participants Participant Participant Participants represent logical or real people or organizational units that participate in services architectures and/or business processes. In SoaML participants provide and use services, defining their external contract

  15. Participants with ServicePoint and RequestPoint Participant Participant RequestPoint – point where the dealer uses the purchasing service ServicePoint – point where the manufacturer offers the purchasing service

  16. ServiceContract A ServiceContract defines the terms, conditions, interfaces and choreography that interacting participants must agree to (directly or indirectly) for the service to be enacted - the full specification of a service which includes all the information, choreography and any other “terms and conditions” of the service. A ServiceContract is binding on both the providers and consumers of that service. The basis of the service contract is also a UML collaboration that is focused on the interactions involved in providing a service. A participant plays a role in the larger scope of a ServicesArchitecture and also plays a role as the provider or user of services specified by ServiceContracts.

  17. Information processed by order processor Service interface corresponding to role type type Service interface corresponding to role Information received by orderer Service Contract Service Contract Role within service Role within service The service contract specifies the details of the service – what information, assets and responsibilities are exchanged and under what rules

  18. Simple Protocol Choreography for Ordering Service Contract

  19. Compound services type type Each composed service becomes a port on the service interface Compound Services are defined by using more granular services to “build up” an enterprise scale service

  20. Real Example - Financial Management Enterprise Context • The service-oriented business architecture of an enterprise is modeled as a Collaboration of enterprise-level Participants. External enterprise level participants This is the use of A service contract specification Our Focus

  21. Inside Financial Management Service representing delegated responsibility for interaction with an external participant. Service representing interaction with another participant within Financial Management. Roles of participants inside of finance

  22. A Composite Service Contract Financial Management is responsible for providing a number of Acquisition Accounting services.

  23. Simple Bill Submission Service Contract • A service contract is modeled as a UML Collaboration. • The required conversation may be specified using an Owned Behavior (e.g., Interaction or Activity) Indicates ownership Note that, while one Participant requests the service and the other responds, information may flow both ways during the interaction. First the submitter submits a bill to the receiver… …then either the bill is successfully delivered or it is returned.

  24. Process Activities Inside a Participant (Outside of SoaML) • Workflow is modeled using UML Activities. Activity Sent event Received event Information flow

  25. Record Unfilled Customer Order Behavior • Ultimately, behavior can be specified using basic UML Activity Diagrams. Control flow

  26. Information Model – For Messages and Entities A term in the vocabulary represents a class of things to be described. A relation between terms is described by an association between classes. Entities may be described as having a unique identity. Attributes specify descriptive information having simple types. An un-shaded class is not detailed on this diagram. This means “zero or more” A class may be specialized into sub-classifications. This indicates a compositional (as opposed to referential) association. This means “one or more” This is a constraint that defines the sub-classification.

  27. Integrating the Information Model with SOA The process model describes how business activities are (or are to be) carried out. Workflow Business transaction Activities Business transaction Implicit memory of business information State changes due to the activities The information model details the vocabulary of the business entities and transactions used in the process model.

  28. Technology Architecture Business Concerns One GSA/FMEA Business Model Business Services (b-SOA) Roles, Collaborations & Interactions Process & Information Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema

  29. Participants may be assemblies of other Participants Participant ServicePoint – capabilities typed by ServiceInterface RequestPoint – needs typed by ServiceInterface Participant part

  30. Receivables Accounting Component Architecture User of a consumed service by multiple internal parts.

  31. Technology Architecture Business Concerns Business Model Business Services (b-SOA) Roles, Collaborations & Interactions Process & Information Logical System Model Technology Services (t-SOA), Components Interfaces, Messages & Data Technology Specification JEE, JMS, Web Services WSDL, BPEL, XML Schema

  32. 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>

  33. 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>

  34. Implementation of service components <provisioningContext name="service“…> <projectRef folder="EjbClient"/> <projectRef folder="AppClient"/> <projectRef folder="Ejb"/> <projectRef folder="ear"/> <projectRef folder="JbossConfig"/> </provisioningContext> Note – stereotypes for provisioning are not part of SoaML – this shows one way to do it.

  35. Implementation of service components public class Asset_Completion_Establishment_ConsumerAsset_Completion_Establishment_Provider_InterfaceInternal{ … … staticpublic Document establish_asset_completion(Document request) throws CheckedException { …… return gov.gsa.fmea.Asset_Record_Manager. Asset_Completion_Establishment_ProviderAsset_Completion_Establishment_Provider_InterfaceInternal. establish_asset_completion(request); }

  36. Mapping – Classes <Organization__Schema identity=”http://ocfo.gsa.gov/fmea/organization/1”> <Organization> <approved>true</approved> … </Organization> </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>

  37. End result – this executes Service representing delegated responsibility for interaction with an external participant. Service representing interaction with another participant within Financial Management. Roles of participants inside of finance

  38. On this infrastructure

  39. Modeling Services with Capabilities • Capabilities model the service contract combined with the capability to provide it • A network of capabilities helps to identify and define services • Capabilities can then be assigned to participants

  40. ServicePoints and Service Participants A ServicePoint is the offer of a service by one participant to others using well defined terms, conditions and interfaces. A ServicePoint defines the connection point through which a Participant offers its capabilities and provides a service to clients. A ServicePoint is a mechanism by which a provider Participant makes available services that meet the needs of consumer requests as defined by ServiceInterfaces, Interfaces and ServiceContracts. A ServicePoint is represented by a UML Port on a Participant stereotyped as a «ServicePoint», .

  41. ServiceInterface a ServiceInterface can be the type of a service port. The service interface has the additional feature that it can specify a bi-directional service – where both the provider and consumer have responsibilities to send and receive messages and events. The service interface is defined from the perspective of the service provider using three primary sections: the provided and required Interfaces, the ServiceInterface class and the protocol Behavior.

  42. Participant with ServicePoint A ServicePointis the point of interaction on a Participant where a service. On a service provider this can be thought of as the “offer” of the service (based on the service interface). The ServicePoint is the point of interaction for engaging participants in a service via its service interfaces.

  43. Participant with ServicePoints and RequestPoints The type of a RequestPoint is also a ServiceInterface, or UML Interface, as it is with a Service point. The RequestPoint is the conjugate of a ServicePoint in that it defines the use of a service rather than its provision. This will allow us to connect service providers and consumers in a Participant.

  44. Participants may be assemblies of other Participants Participant ServicePoint – capabilities typed by ServiceInterface RequestPoint – needs typed by ServiceInterface Participant part

  45. Document and RPC Style service operation parameters

  46. Agent autonomous entity has its own lifecycle behavior can adapt to the environment also through modification of its definition Milestone defines a value of progress attached to behavioral elements is used especially for dynamic analysis of behavior that does not necessarily end Agent and Milestones

  47. Milestone A Milestone is a means for depicting progress in behaviors in order to analyze liveness. Milestones are particularly useful for behaviors that are long lasting or even infinite. A Milestone can be understood as a “mythical” Signal. A mythical Signal is a conceptual signal that is sent from the behavior every time a point connected to the Milestone is passed during execution. The signal is sent to a conceptual observer outside the system that is able to record the origin of the signal, the signal itself and its progress value.

  48. Business Motivation Model (BMM) integration • Business requirements can be captured using the OMG Business Motivation Model (BMM). • Any UML BehavioredClassifier including (for example a ServicesContract) may realize the BMM Motivation concept of motivation realization. This allows services models to be connected to the business motivation and strategy linking the services to the things that make them business relevant.

  49. BMM with MeansRealizations

  50. Relating to other standards • SoaML integration with BPMN 2.0 and BPDM will be related to the ongoing BPMN 2.0 standardization • Extensions for Agents and semantic services will also relate to semantics, ontologies and other OMG metamodels like ODM and SBVR • Limited BMM integration is included to tie services to the business

More Related