Modeling with SoaML, the Service-Oriented Architecture Modeling Language: Part 1. Service Identification Rohit Goel, Tommy Omen, Ashley Pham

Content Development Process What is SoaML? Purchase Order Process Example Service Project Organization Service Identification

Development Process

What is SoaML? OMG (Object Management Group) Standard Small set of extensions to UML to support SOA modeling Aims to promote integration and interoperability of components created by different organizations at different times Raises level of abstraction to focus on business needs Enables SOA both on and between existing platforms through model-driven architecture (MDA) Decouples solution architecture platform implementations to prevent existing solutions from inhibiting platform evolution

Purchase Order Process Example Scenario: A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. Goals of project: Establish a common means of processing purchase orders Ensure that orders are processed in a timely manner and deliver the required goods Help minimize stock on hand and inventory maintenance costs Minimize production and shipping costs

Service Project Organization 3 modeling steps after requirements Identify capabilities Exposing appropriate capabilities as services Defining the service architecture What do these steps accomplish? Specifies services Defines interfaces Defines implementation (i.e. which service providers provide what services and how).

Package Diagram

Service Identification SOMA defined techniques for Service Identification Goal-service modeling - Identifies capabilities needed to realize business requirements such as strategies and goals Domain decomposition - Uses activities in business processes and other descriptions of business functions to identify needed capabilities Existing asset analysis - Mines capabilities from existing applications

Service Capability Diagram

Service Capability Diagram w/ Exposed Services

Service Architecture Formal specification of the business requirements that are performed by interacting service participants. Contains the same information as the original business process and can be treated as a specification for how to realize that business process. Service architecture answers the following questions: What effect is the requirement intended to accomplish? Who participates to get it done? What are the roles responsible for? What roles interact? What are the rules for how the roles interact? How do we evaluate whether the requirements were met?

Services architecture for processing purchase orders

Service Architecture (Continued) Purchase order process is a Service Architecture with 4 roles. Service architecture takes a role-centered view of the business requirements. Can be used to realize use cases that capture information about the high-level functional and nonfunctional requirements. Provides a more formal way of specifying the participants and contracts governing their interactions. Both approaches can be used together.

References Amsden, Jim. (Ed.). (2010). Modeling with Soaml, the service-oriented. IBM Corporation.