SOA strives to be business-relevant – driven by the business and implemented to support the business. SOA solutions need to be connected to the business requirements that they fulfill. We need a way to formalize business requirements so that SOA can more closely resemble business services and how those services might meet business objectives – this ties the deployed SOA solution to its intended business value. We also need a way to isolate business concerns from the evolving SOA platforms that support them.
Models allow us to abstract away from the implementation details and focus on the issues that drive business and architectural decisions.
Usually one begins by describing the business motivation that establishes the business objectives. One then models high-level business processes that are business requirements to meet the objectives. We are now ready to create a model to meet these requirements – by identifying capabilities, exposing appropriate candidate capabilities as services, and then defining the architecture for how the services interact.
To identify services, one treats the business process as a Service Requirement contract – then service specifications and service providers are designed and connected together in a manner that fulfills the business requirements while addressing software architectural concerns.
This process of identifying candidate services from a business model is also known as domain decomposition.
SoaML provides several ways of identifying services. The requirements from the business process could be viewed as a service architecture, thus indicating the participants in the business processes, the service contracts that specify how they interact, and the choreography of their services and requests.
A service architecture is a formal specification of the business requirements that are performed by interacting service participants.
The example we will use in our series on SoaML is based on the Purchase Order Process example taken from the OMG SoaML standard, and it is based in the BEPL 1.1 specification.
Scenario: A consortium of companies has decided to collaborate to produce a reusable service for processing purchase orders. These are the goals of the 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
We will skip over the discussion of how to identify services in Amsden’s original article, as our primary interest is using SoaML to model a vocabulary of government service, including a vocabulary derived from schema.org.
There are five main packages in the PurchaseOrderProcess model:
- org::ordermanagement – contains elements concerned with order management
- org::crm – contains the data model and common interfaces for some envisioned customer
- com::acme::credit – contains elements concerned with invoicing and credit management
- com::acme::productions – contains elements that are concerned with productions and scheduling
- com::acme::shipping – contains elements concerned with shipping
These packages divide the problem domain into different functional areas. This helps manage complexity, establishes required name spaces, facilitates reuse, and keeps separate concerns in different packages. Here’s the package dependencies diagram for our service model:
This organization could be called the dominant organization of the service model. Perspective packages can be used to document other ways of organizing the same model elements.
Service identification consists of determining which capabilities should be exposed as services. The IBM SOMA method provides a Service Litmus Test that can be applied to capabilities to determine which ones should be exposed as services. The Service Litmus Test examines each capability and applies various configurable metrics to determine which one(s) should be exposed as services. See RUP for SOMA for details.
We close with Amsden’s figure that shows the service architecture for processing purchase orders at the end of the exercise of identifying services:
SoaML may be used to identify services that are connected to business requirements:
- capture the business objectives necessary to realize the business mission
- model the business processes that are necessary to meet the business objectives
- use the business requirements and business processes to identify the required capabilities and the potential relationships between them
Capabilities are treated as candidate services. The capabilities that passed the service litmus test were used to identify the required service interfaces. This ties the service interfaces back to the business requirements.
The result is a formal structure for identifying business-relevant capabilities that are linked to the business objectives that that they are intended to fulfill.
Previous: Service oriented architecture Modeling Language
Next: SoaML – Specifying services