SOS Concepts in DM2 – SoaML Example

1. 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 • http://lib.modeldriven.org/MDLibrary/trunk/Pub/Presentations/SoaMLBriefing.ppt • www.soaml.org • 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

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

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

4. Marketplace Services Physical Delivery What SOA represents at a high level Order Consumer Provider Conformation Shipped Mechanics Are Us Dealer Acme Industries Manufacturer Status Ship Req Consumer Consumer Shipped Provider Delivered Provider GetItThere Freight Shipper

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

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

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

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

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

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

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

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

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

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

15. Composite Application Components Enterprise systems can be integrated with adapter components This component is defined as a composition of other components. Or, new implementation can be defined inside of 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

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

17. Interface Centric Style in SoaML

18. Definition of a “Service Interface” Interface of consumer (if any) Interface of provider Definition of service

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

20. Components are “used” in structured classes and the ports connected to define composites This is a composite Use of component defined elsewhere that provides a service 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

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

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

23. Concept of “Joint Action” (or interface)

24. Concept of a services architecture or composite

25. Abstract Concept of a “System” Used as a basic for the other models

26. Behavior As a System

27. Relating the logical models to the examples

28. Services Architecture Services Architecture Participant Role Service Channel Connection Connection Service Channel

29. Composite Application Components Generalization Participant Request (Port) Participant Role Service (Port) Service Channel Connection

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

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

32. Simple interfaces Provider (Service Interface) (Interactive Role) Consumer and service contract implied

33. Applicable DM2 models DM2_090827

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