Modeling SOA: Part 3. Service realization

This third article of this five-part series explains how SOA-based Web services are actually implemented. The service realization starts with deciding what component will provide what services. That decision has important implications in service availability, distribution, security, transaction scopes, and coupling. After these decisions have been made, you can model how each service functional capability is implemented and how the required services are actually used. Then you can use the UML to SOA transformation feature included in IBM® Rational® Software Architect to create a Web services implementation that can be used in IBM® WebSphere® Integration Developer to implement, test, and deploy the completed solution.


Jim Amsden (, Senior Technical Staff Member, IBM

Jim AmsdenJim Amsden is an IBM Senior Technical Staff Member with over 20 years of experience in designing and developing applications and tools for the software development industry. He holds a Masters in Computer Science from Boston University. His interests include contract-based development, agent programming, business-driven development, J2EE UML, and service-oriented architectures. He is co-author of "Enterprise Java Programming with IBM WebSphere". His current focus is on finding ways to integrate tools to better support agile development processes.

16 October 2007

Also available in Chinese Russian Vietnamese

About this series

In the first article in this series, "Part 1. Service identification", we outlined an approach for identifying services that are connected to business requirements. We started by capturing the business goals and objectives necessary to realize the business mission. We then modeled the business operations and processes that are necessary to meet the goals and objectives. Then we used the business process as a contract that helped identify the required services and the potential relationships between them.

In the second article, "Part 2. Service specification", we modeled the details of the service specification. A service specification defines everything a potential consumer of the service needs to know in order to decide if they are interested in using the service, and exactly how to use it. It also specifies everything a service provider must know in order to successfully implement the service. That is, a service specification is a mediator or contract between what consumers need and what providers provide. This information is captured in the service specification, making it easy to search asset repositories for reusable services and obtain all the necessary information without having to navigate many different documents or search for related elements.

In this article we'll look at designing how the services are actually provided or, in Unified Modeling Language (UML) terminology, realized. The service realization design starts with deciding what components will provide what services. That decision has important implications in service availability, distribution, security, transaction scopes, and coupling. After these decisions have been made, you can design how the functional capability of each service is to be implemented and, therefore, how the required services are actually used.

The next article in this series, "Modeling SOA: Part 4. Service composition," will describe how these services can be composed to create new services. The final article, "Part 5. Service implementation," will use the IBM® Rational® Software Architect UML to SOA transformation feature to create a Web services implementation that can be directly used in IBM® WebSphere® Integration Developer to implement, test, and deploy the completed solution.

Context of this article

A complete understanding of SOA modeling requires getting to the details for how a service is actually implemented by providers and used by consumers. If the implementation is difficult, then perhaps the specification is incorrect or the wrong services have been identified. This article shows how to design the implementation of each of the service specifications we designed in the previous article. The implementation design consists of three steps:

  1. Deciding which service providers provide which services
  2. Designing the service implementations
  3. Assembling and connecting service consumers and providers necessary to model complete implementations

Deciding which services are provided by which providers (there could be more than one) is driven by many factors, including:

  • Where the services are most likely used
  • Where they are most likely to be deployed
  • What qualities of service are required
  • Stability of the functional area
  • Where the most change is anticipated
  • How much coupling is tolerable in the domain
  • Security issues
  • Applicable platform implementation technologies
  • Integration and reuse of existing systems

A detailed analysis of all of these concerns is beyond the scope of this article, but it is covered fully in the IBM® Service Oriented Modeling and Architecture (SOMA) method. Here, we'll assume that, somehow, the IT architect has decided which service providers will provide what services, so we can focus on how the providers are modeled and assembled into consumer solutions.

As with all of the articles in this series, we'll use existing IBM Rational and IBM WebSphere tools to build the solution artifacts and link them together so that we can verify the solution against the requirements and more effectively manage change. Table 1 provides a summary of the overall process that we'll use in developing the example and the tools used to build the artifacts.

Table 1: Development process roles, tasks, and tools
Business ExecutiveConvey business goals and objectivesIBM® Rational® RequisitePro®
Business AnalystAnalyze business requirementsIBM® WebSphere® Business Modeler
Software ArchitectDesign the architecture of the solutionIBM Rational Software Architect
Web Services DeveloperImplement the solutionIBM® Rational® Application Developer and IBM® WebSphere® Integration Developer

Service identification and specification review

Let's start by reviewing the service specifications that were identified and specified in the previous articles. Figure 1 shows the business services requirements contract that our solution must fulfill.

Figure 1. Service requirements contract
Service requirements contract flow chart

Recall that this service collaboration represents a requirements contract, which is potentially derived from a business process that represents what our service solution must do. It is an architecturally neutral specification of the requirements that does not over-constrain the SOA solution.

Figure 2 shows the service specifications that were identified as needed to fulfill the requirements. Essentially, we are building (buying, reusing, adapting) services that are capable of playing the roles in this business services requirements contract.

Figure 2. Service topology
Service topology flow chart

Figure 3 shows the complete Scheduling service specification. This service specification is a simple interface, because there is no interesting protocol for using scheduling services.

Figure 3. The Scheduling service specification
Scheduling service specification code

Figure 4 shows the ShippingService service specification.

Figure 4. ShippingService service specification
Shipping Service service specification code and flow chart

This service specification is a little more complicated, because it models the interaction between a shipper and an orderer by using a simple callback style interaction. Because this specification includes a behavioral protocol, we model it using an abstract class that defines the roles (properties) involved in the service protocol. The responsibilities of these roles are defined by their types, which are the interfaces provided or required by the service specification. The ShippingService interaction owned by the ShippingService service specification defines the rules for how the shipper and orderer interact. This interaction will be the contract for service channels connected to a service defined by this service interface.

Figure 5 shows the InvoicingService service specification.

Figure 5. The InvoicingService service specification
code and flow chart

This protocol is also a bit more complicated, because the provided and required service functional capabilities must be invoked and responded to in a specific order. In this case, an activity is used to define the service protocol. However, this was simply a matter of choice; we could have used an interaction or state machine.

Figure 6 shows the Purchasing service specification:

Figure 6. The Purchasing service specification
The Purchasing service specification code and flow chart

The Purchasing service specification represents the functional capability specified in the original Process Purchase Order business process. It represents a service identified and designed to realize that business process. Because there is no services protocol associated with this specification, we once more model this using a stereotyped interface.

Now we are ready to design components that provide each of these services.

Service realization

A service defines a set of capabilities, provided by service providers, that meet the needs of service consumers, or users. The first step in service implementation design is to provision the services. That is, to figure out which service providers will be providing what service capabilities. This is a key part of designing an SOA, because choosing providers establishes the relationships between service consumers and providers. Therefore, this establishes both the capabilities of a system and the coupling between its parts.

You could put all of the operations into a single service and have a simple solution. But all clients would depend on that one service, which would result in a very high degree of coupling. Any change in the provider would result in a possible change in all consumers. This was a common problem with module libraries in the old days of C programming. You could also create a separate service for each functional capability, but this would result in a very complex system that would not reflect good encapsulation and cohesion. It would also be difficult to model communication between consumers and providers that follow a protocol for using a set of related functional capabilities.

In the end, deciding on the service participants is something that takes some skill and can be affected by lots of compromises. Distribution can play a key role. It would be great if we could design SOA solutions independent of consumer and provider location, but that generally isn't very practical. Where a service is deployed, in relation to consumers and other required services, can have a profound effect on solution performance, availability, and security. Ignoring this in the solution architecture may result in unacceptable solution implementations down the road.

Our problem here is quite simple, so it is not hard to determine what service participant will provide or consume what services. The following sections provide models of service providers for all of the services shown in Figure 2 and the detailed service specifications that follow that figure. This is a fairly simple example, and many of the service providers provide only one service that has only one capability. This will not generally be the case. Service providers are expected to provide or consume (or both) many services that have many functional capabilities. This example is intentionally simple to focus on concepts without getting bogged down in the details of the example itself.


An invoicing service provider provides the Invoicing interface for calculating the initial price for a purchase order, and it then refines this price when the shipping information is known. The total price of the order depends on where the products are produced and where they are shipped from. The initial price calculation may be used to verify that the customer has sufficient credit or still wants to purchase the products. It is better to verify this before fulfilling the order.

We start the design of this service provider by creating a system use case that defines its requirements and a <<serviceProvider>> component called Invoicer that realizes the use case. The Invoicer component will be in the credit package that imports the CRM (customer relationship management) package to use the common service data (message) definitions. Figure 7 shows what we have so far.

Figure 7. The initial Invoicer service provider
The initial Invoicer service provider diagram

The Invoicer service provider will provide the InvoicingService service. We model this by adding a <<service>> port to the Invoicer, which is of the type InvoiceService service specification. All services are typed by service specifications that define what functional capabilities are provided and required and the protocol for using them. Figure 8 shows the Invoicer with the invoicing service added.

Figure 8. Adding an InvoicingService to the Invoicer service provider
Adding an InvoicingService to the Invoicer service provider screen capture

We can see by the type of the service that it provides the Invoicing interface and requires the InvoiceProcessing interface. From the service's type, we know what consumers connected to the service have to do to use the service and what the Invoicer (or any other provider) has to do to implement it. Any use and implementation of a service must be consistent with the service's specification and its protocol.

The invoicing <<service>> port can also specify the possible bindings provided by the Invoicer component for use in connecting with other components. Different possible binding approaches, such as RMI over IIOP (Remote Method Invocation over Internet Inter-ORB Protocol) or SOAP over HTTP, can again have a profound effect on the performance, availability, and security of a service. Therefore, these concerns should be addressed as part of service design, even though they may be platform-specific. At a minimum, the solution design should address whether connections with the service are local or remote or both.

The Invoicer provides the Invoicing interface, which involves two operations:

  • initiatePriceCalculation
  • completePriceCalculation

The Invoicer must provide a design for the implementation or method for each of these service operations. The method must also invoke the processInvoice operation of the InvoiceProcessing interface when the price calculation has been completed. Figure 9 shows the Invoicer component owns two behaviors that have the same name as the provided operations.

Figure 9. Invoicer service implementations
Invoicer service implementations diagram

The completePriceCalculation activity is the method for the Invoicing::completePriceCalculation service operation. It uses an opaque action to calculate the total price, and then it invokes the InvoiceProcessing::processInvoice operation on the invoicing port. (The target input pin of the processInvoice action is the invoicing port.) Notice that this is consistent with the invoicing protocol as specified by the InvoicingService service specification.

The initiatePriceCalculation opaque behavior is the method for the initiatePricesCalculation service operation. This operation is implemented by using Java™ code captured in the body of the opaque behavior.

Production scheduling

A production scheduling service provider provides the Scheduling interface to determine where goods will be produced and when. This information can be used to create a shipping schedule used in processing purchase orders.

The Productions component provides the Scheduling interface through its scheduling port, as shown in Figure 10. This <<service>> port specifies the possible binding styles available on that port.

Figure 10. The Productions service provider
The Productions service provider screen capture

The service operation methods are the requestProductionsScheduling and sendShippingSchedule behaviors. The details of these implementations are not shown in the diagram and may be left to be implemented by the developer by using more applicable, platform-specific languages.


A shipping service provider provides the Shipping interface to ship goods to a customer for a filled order. It also requires the ScheduleProcessing interface to request that the consumer process the completed schedule.

Figure 11 shows that the Shipper service provides the shipping service as specified by the ShippingService service specification.

Figure 11. The Shipper service provider
The Shipper service provider diagram

Conjugate types

To use the service providers design shown previously, we need to understand the relationship between consumers and providers, how they are connected, how to specify the types of the ports on the connector ends, and how to determine if those types are compatible, resulting in a valid connection.

SOA is about matching consumer needs with provider capabilities. Consumer participants have needs that they meet through requisitions. Provider participants have capabilities they offer through services. Consumer needs are mapped to provider capabilities by connecting requisitions to services. The way consumers use services and the way providers provide them must be compatible with the protocols defined in the service and requisition specifications.

When a service consumer's port (a requisition) is connected to a provider's service port, the ports at the ends of the connection must be compatible. This means that the consumer's requisition must require the providing port's interfaces, and the consumer must provide the required interfaces. Further, the consumer and provider must interact according to the protocol defined in the service interface.

The requisition port can use any class to define its type. It can provide or require (or both) any interfaces, as long as they are compatible with any service ports that it is connected to. That is, consumers and providers are decoupled until they are connected, and they are not required to have a particular service specification corresponding to the provided service specification.

However, there are many cases where the type of a consumer requisition is the exact complement or conjugate of the service port that it is connected to. As a result, it may be convenient to define a convention for easily specifying and designating the conjugate of a service specification that can be used as a type for a consuming requisition port. This type is known as the conjugate of a service specification. The only difference between a service specification and its conjugate is that the provided (realized) and required (used) interfaces are reversed. Everything else in the class is the same, including the behavior that models the service protocol.

For example, consider the InvoicingService service interface. Figure 12 shows the conjugate of InvoicingService, called ~InvoicingService.

Figure 12. ~InvoicingService, the conjugate of InvoicingService
~InvoicingService, the conjugate of InvoicingService diagram

The convention used here is to name the conjugate the same as the service specification, except starting with a ~. (tilde symbol). Any naming convention can be used, but it should be used consistently to make it easy to recognize the relationship between these types. ~InvoicingService has the same internal structure and behaviors as InvoidingService. It simply uses the interfaces provided by InvoicingService and realizes the required interfaces.

A future extension of the IBM Software Service Profile for UML may introduce the concept of a requisition port to distinguish needs from capabilities. Then, a requisition port could use the same type as a service port, thereby eliminating the need to define conjugate types. A requisition port would indicate that the capabilities of the service are being used, while a service port would indicate that they are being provided.

What's next

We have now finished the identification, specification, and implementation (or realization) design of the services, consumers, and providers needed to meet the business objectives. The result is a technology-neutral design model of an architected service solution. But we still haven't created a service consumer that can bring together services provided by the Invoicer, Productions, and Shipper and use them to process a purchase order. The next article in this five-part series, "Modeling SOA: Part 4. Service composition," shows how to assemble and connect these service providers and choreographs their interactions to provide a complete solution for the business requirements.


RSM sample modelRSM_sample_model.zip60KB



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

Zone=Rational, SOA and web services
ArticleTitle=Modeling SOA: Part 3. Service realization