Page 1 May 2009 SOS Concepts in DM2 – SoaML Example The purpose of this is to refine SOA concepts in DM2 –It is a summary for the DM2/SOA team –Based on SoaML concepts but intended to represent SOA in general – at the business and technical levels –Not intended to fully introduce SoaML or DM2 More SoaML info – LBriefing.ppthttp://lib.modeldriven.org/MDLibrary/trunk/Pub/Presentations/SoaM LBriefing.ppt – Note that there are 2 “styles” in SoaML, one “joint action” focused and the other “interface” focused. We have tried to bring these together in the logical model –Joint action/collaboration style – more top down –Provided and used interface style – more bottom up

Page 2 May 2009 Contents Some SoaML example models A logical SOA model supporting SoaML (Since SoaML is a UML profile it doesn’t have a “clean” logical model) Example models mapped to logical model –Not using IDEAS, but the styles are similar Parts of the DM2 model

Example scenario & models This is the “joint action “/systems centric style

Page 4 May 2009 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 What SOA represents at a high level

Page 5 May 2009 Services Architecture for the Dealer Network 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 services that fulfill those roles. Shippin g service Ship Status service Purchasin g service Manufacturer Participant – provides and uses services Dealer Participant – provides and uses services In a services architecture – the participant roles are defined based on the systems view – top down. The system defines the parts

Page 6 May 2009 Drilling down - Inside a Manufacturer Order Conformation Shipped Ship Req Shipped Delivered Fulfillment Production Accounting Acme Industries Not every manufacturer is going to be the same inside – this shows some of the internals of “Acme”

Page 7 May 2009 Architecture Inside of Acme SOA architectures are able to “drill down” in more detail – this shows the architecture inside of a particular manufacturer, Acme. Other manufactures may have different internal architectures and processes.

Page 8 May 2009 Specifying Services Specification of services includes –The roles each participant plays in the service, such as provider and consumer –The message types that go between the participants when the service is enacted –The interfaces provided and used by each participant for the service –The choreography of the interactions between the participants while enacting the service –Placeholders are provided for service policies and motivation Modeling services –Services are modeled using “Service Contracts” and “Service Interfaces” in SoaML. These use UML interfaces, classes and behaviors.

Page 9 May 2009 High level view of a service This view of a service only identifies the service name and the roles each participant plays in the service. This is a high-level summary view.

Page 10 May 2009 Service Choreography for “Place Order” The role of the consumer (a participant that places orders) and the consumers interface The role of the provider (an order taker) and their interface The optional interaction to request a quote The optional interaction to return the quote The required interaction to place an order The required interaction to accept or reject the order A more detailed look at the same service. Note that this models a fully asynchronous SOA – like most business interactions, the document message types are detailed on the next page.

Page 11 May 2009 Message Detail for Place Order This is the detail for the message types that correspond to the interactions for the place order service. Note that at the technology level this can produce XML schema for the messages.

Page 12 May 2009 Linking messages to business information SOA Messages can reference and include parts of the logical information model – forming a connection between SOA and enterprise data

Page 13 May 2009 Interfaces for Participants Each role in the service that receives interactions has an interface, this is the interface for a logical technology component and is implemented by components providing or using this service. This service is bi-directional - messages flow in both directions. Interfaces will correspond with parts of WSDL in a web services mapping of SoaML

Page 14 May 2009 Logical System Components Components implement the service interfaces providing the link to systems. Participants and services may be used in multiple architectures. “Ports” on the participating components provide and require the service interfaces for each service provided or used

Page 15 May 2009 Composite Application Components Components can be assembled from other components by linking their services. This corresponds to the architecture for Acme. Note that nested components are USE OF an existing component Enterprise systems can be integrated with adapter components Or, new implementation can be defined inside of components. This component is defined as a composition of other components.

Page 16 May 2009 Compositions within compositions This is the inside of the SAP AR component – also a composition, it uses the existing SAP interfaces and adapts them to the enterprise contract. This separates the concerns of a particular enterprise system from the enterprise SOA. Sometimes the system interfaces are used directly or adapted by an ESB.

Interface Centric Style in SoaML

Page 18 May 2009 Definition of a “Service Interface” Interface of provider Interface of consume r (if any) Definitio n of service

Page 19 May 2009 Service Interfaces and Ports ServiceInterface is the “type” of a “RequestPoint” to use service ServiceInterface is the “type” of a “ServicePoint” to provide service Participants provide and use services via ports

Page 20 May 2009 Components are “used” in structured classes and the ports connected to define composites Use of component defined elsewhere that provides a service This is a composite Definition and use are separate – allows for reusable components In a composition the composite is defined in terms of the use of pre-defined “parts” Contrast with services (more top down) services architecture

Page 21 May 2009 Simple case – simple interface A simple (UML) interface can also be used to define a simple service – this interface can be the type of a ServicePoint or RequestPoint

Logical SOA model As a profile SoaML does not have a logical meta model (it is built from UML). This is a logical model, an interpretation of the concepts

Page 23 May 2009 Concept of “Joint Action” (or interface)

Page 24 May 2009 Concept of a services architecture or composite

Page 25 May 2009 Abstract Concept of a “System” Used as a basic for the other models

Page 26 May 2009 Behavior As a System

Relating the logical models to the examples

Page 28 May 2009 Services Architecture Participant Role Service Channel Connection Service Channel

Page 29 May 2009 Composite Application Components Participant Participant Role Service Channel Connection Service (Port) Request (Port) Generalization

Page 30 May 2009 Service Choreography for “Place Order” Consumer (Service Interface) (Interactive Role) Provider (Service Interface) (Interactive Role) Resource Flow inflow Information Resource outflow inflow ownership Service Contract (Joint Action)

Page 31 May 2009 Service Interfaces and Ports Service (Port) Participant Service Contract (Joint Action) Consumer (Service Interface) (Interactive Role) Provider (Service Interface) (Interactive Role) Request (Port)

Page 32 May 2009 Simple interfaces Provider (Service Interface) (Interactive Role) Consumer and service contract implied

Applicable DM2 models DM2_090827

Page 34 May 2009

Page 35 May 2009

Page 36 May 2009

Page 37 May 2009

Page 38 May 2009 Suggested path Review examples and logical model See how examples would be rendered in DM2 today Compare with logical model, Resolve issues