OMG 9/16/2008 UPMS – UML Profile and Metamodel for Services – RFP Revised submission: SoaML Service oriented architecture Modeling Language SOA SIG Orlando, September 23rd, 2008 Dr. Arne J. Berre, SINTEF, Oslo, Norway e.mail:

SoaML Specification – Revised UPMS Submission Object Management Group The SoaML submission team  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 –Inherit –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

SoaML Specification – Revised UPMS Submission Object Management Group 3 Find the document here:

SoaML Specification – Revised UPMS Submission Object Management Group UPMS – SoaML Timeline Event or ActivityActual Date Preparation of RFP by TFSept 4, 2006 TC votes to issue RFPSept 27, 2006 LOINov 28, 2006 Initial submission presentationsJune 4, 2007 Merged submission dueJune 25, 2008 Revised SubmissionAug 25, 2008 ErrataNov 12, 2008

SoaML Specification – Revised UPMS Submission Object Management Group 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

SoaML Specification – Revised UPMS Submission Object Management Group SoaML Overview  SoaML metamodel and UML Profile  Service capabilities  Services, services contracts and service specifications  Service data  Services Architecture  Service Classification  Unifying collaboration modeling and composite structures  Milestones  Integration with other submissions –BMM Integration

SoaML Specification – Revised UPMS Submission Object Management Group SoaML Metamodel for ServiceInterface and Participants

SoaML Specification – Revised UPMS Submission Object Management Group SoaML Metamodel for ServicesArchitecture and ServiceContract

SoaML Specification – Revised UPMS Submission Object Management Group UPMS SoaML UML Profile

SoaML Specification – Revised UPMS Submission Object Management Group SOA Marketplace Example Order Conformation Ship Req Shipped Physical Delivery Delivered Status GetItThere Freight Shipper Mechanics Are Us Dealer Acme Industries Manufacturer

SoaML Specification – Revised UPMS Submission Object Management Group ServiceCapability realised by Participants ServiceCapabilities represent the services or capabilities of some system or architecture. These ServiceCapabilities may then be linked to the Participants that actually provide the capabilities through UML2 Realizations

SoaML Specification – Revised UPMS Submission Object Management Group Services and Service Participants. A Service is a capability offered by one entity or entities to others using well defined “terms and conditions” and interfaces. Those entities may be people, organizations, technology components or systems – we call these Participants. Participants offer capabilities through services on Ports with the «service» stereotype. The service port is the interaction point where consumers of the service go to use that service.

SoaML Specification – Revised UPMS Submission Object Management Group Service Interface 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.

SoaML Specification – Revised UPMS Submission Object Management Group Participant with Service port A service port is 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 service port is the point of interaction for engaging participants in a service via its service interfaces.

SoaML Specification – Revised UPMS Submission Object Management Group Participant with Service and Request ports The type of a Request port is also a ServiceInterface, or UML Interface, as it is with a Service port. The Request port is the conjugate of a Service port 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.

SoaML Specification – Revised UPMS Submission Object Management Group Participants may be assemblies of other Participants Participant Participant part Service – capabilities typed by ServiceInterface Request – needs typed by ServiceInterface

SoaML Specification – Revised UPMS Submission Object Management Group MessageTypes MessageTypes represent service data exchanged between service consumers and providers. Service data is often a view (projections and selections) on information or domain class models representing the (often persistent) entity data used to implement service participants.

SoaML Specification – Revised UPMS Submission Object Management Group Marketplace Services Order Conformation Ship Req Shipped Physical Delivery Delivered Status Provider Consumer Provider Consumer Provider GetItThere Freight Shipper Mechanics Are Us Dealer Acme Industries Manufacturer

SoaML Specification – Revised UPMS Submission Object Management Group Services Architecture A ServicesArchitecture (or SOA) is a network of participant roles providing and consuming services 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. A community ServicesArchitecture is defined using a UML Collaboration.

SoaML Specification – Revised UPMS Submission Object Management Group Compound services

SoaML Specification – Revised UPMS Submission Object Management Group 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.

SoaML Specification – Revised UPMS Submission Object Management Group Ordering ServiceContract communication protocol

SoaML Specification – Revised UPMS Submission Object Management Group Services architecture for a participant A participant ServicesArchitecture specifies the architecture for a particular Participant. A services architecture illustrates how sub-participants and external collaborators work together and would often be accompanied by a business process. A ServicesArchitecture (both community and participant) may be composed from other services architectures and service contracts.

SoaML Specification – Revised UPMS Submission Object Management Group Agent and Milestones  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

SoaML Specification – Revised UPMS Submission Object Management Group BMM with MeansRealizations

SoaML Specification – Revised UPMS Submission Object Management Group Classification and categorization of services SoaML introduces a generic mechanism for categorizing elements in UML with categories and category values that describe some information about the elements. This mechanism is based on a subset of RAS (Reusable Asset Specification). Categories may be organized into a hierarchy of named Catalogs. The same element may be classified by many Categories, and the same Category or CategoryValue may be applied to many elements. This is intended to be a very flexible, dynamic mechanism for organizing elements in multiple, orthogonal hierarchies for any purpose the modeler needs.

SoaML Specification – Revised UPMS Submission Object Management Group Categories to denote ownership of service participants

SoaML Specification – Revised UPMS Submission Object Management Group SoaML / UPMS (core) SoaML/UPMS Service Variability UPMS WSA PIM4 SWS PIM4 Agents P2P/Grid/ Components UPMS 2.0 ? WS, WSMO, OWL-S, JACK, JADE, JXTA, OGSA, J2EE, CORBA J2EE, NetWeaver,.Net BPMNBPDMBMMEPC PIMs for different Architectural Styles Realisation Technologies PSM Models CIM Business Models PIM Models EDA

SoaML Specification – Revised UPMS Submission Object Management Group Errata – agreed name changes  service -> service point (ref. SOA endpoint for provider)  request -> request point (ref. SOA endpoint for consumer)  ServiceCapability -> Capability (harmonise with UPDM)  Connectable Elements, attribute “isUsable: Boolean” - for modeling conjugate types

SoaML Specification – Revised UPMS Submission Object Management Group Extensions to UPMS and SoaML New RFPs – to be presented at the OMG TC meeting, September 22-26, 2008  AMP – Agent Metamodel and Profile  EMP – Event Metamodel and Profile - for Complex Event Processing  … others ….  SoaML/UPMS: Send e.mails to or report issues through