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:
- Deciding which service providers provide which services
- Designing the service implementations
- 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 Executive||Convey business goals and objectives||IBM® Rational® RequisitePro®|
|Business Analyst||Analyze business requirements||IBM® WebSphere® Business Modeler|
|Software Architect||Design the architecture of the solution||IBM Rational Software Architect|
|Web Services Developer||Implement the solution||IBM® 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
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
Figure 3 shows the complete
specification. This service specification is a simple interface, because there is
no interesting protocol for using scheduling services.
Figure 3. The Scheduling service specification
Figure 4 shows the
Figure 4. ShippingService service specification
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
ShippingService interaction owned by
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
Figure 5 shows the
Figure 5. The InvoicingService service specification
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 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.
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
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 Invoicer service provider will provide the
InvoicingService service. We model this by adding a
<<service>> port to the
Invoicer, which is of the type
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
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.
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:
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
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
Figure 9. Invoicer service implementations
completePriceCalculation activity is the method
operation. It uses an opaque action to calculate the total price, and then it
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.
initiatePriceCalculation opaque behavior is the
method for the
operation. This operation is implemented by using Java™ code captured in
the body of the opaque behavior.
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 service operation methods are the
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
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
interface. Figure 12 shows the conjugate of InvoicingService, called
Figure 12. ~InvoicingService, the conjugate of InvoicingService
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
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.
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 model||RSM_sample_model.zip||60KB|
- Modeling SOA: Part 1. Service identification by Jim Amsden is the first in a series of five articles about developing software based on service-oriented architecture (SOA). (IBM® developerWorks®, October 2007).
- Modeling SOA: Part 2. Service specification by Jim Amsden is the second in a series of five articles about developing software based on service-oriented architecture (SOA). (IBM® developerWorks®, October 2007).
- Service-oriented modeling and architecture: How to identify, specify, and realize services for your SOA by Ali Arsanjani is about the IBM Global Business Services' Service Oriented Modeling and Architecture (SOMA) method (IBM® developerWorks®, November 2004).
- IBM Business service modeling, a developerWorks article by Jim Amsden (December 2005), describes the relationship between business process modeling and service modeling to achieve the benefits of both.
- "Using model-driven development and pattern-based engineering to design SOA: Part 2. Patterns-based engineering," Part 2 of a planned 4-part IBM developerWorks tutorial series (2007).
- "Design SOA services with Rational Software Architect," a 4-part IBM developerWorks tutorial series (2006-2007).
- "Model service-oriented architecture with Rational Software Architect: Part 3. External system modeling ," Part 3 of a planned 6-part IBM developerWorks tutorial series (2007).
- Modeling service-oriented solutions is Simon Johnston's great article describing the approach to service modeling that drove the development of the UML Profile for Software Services and the RUP for SOA plug-in (developerWorks, July 2005).
- UML 2.0 Profile for Software Services, also by Simon Johnston (developerWorks, April 2005), describes the UML profile for software services, a profile for UML 2.0 that allows for the modeling of services, service-oriented architecture (SOA), and service-oriented solutions. The profile has been implemented in IBM Rational Software Architect.
- SOA programming model for implementing Web services, Part 1: Introduction to the IBM SOA programming model, by Donald Ferguson and Marcia Stockton (developerWorks, June 2005), describes the IBM programming model for Service-Oriented Architecture (SOA), which enables non-programmers to create and reuse IT assets. The model includes component types, wiring, templates, application adapters, uniform data representation, and an Enterprise Service Bus (ESB). This is the first in a series of articles about the IBM SOA programming model and what is required to select, develop, deploy, and recommend programming model elements.
- Service Data Objects simplify and unify the way applications access and manipulate data from heterogeneous data sources.
- See Business Process Execution Language for Web Services for more about the BPEL 1.1 specification.
- Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
- Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
- Download the Rational Unified Process plug-in for the SOMA method: IBM RUP for Service-Oriented Modeling and Architecture . You must have IBM Rational Method Composer to install this plug-in.
- Download RUP plug-in for SOA, Rational Unified Process plug-in for services modeling using the IBM Software Services Profile.
- IBM SOA Sandbox The IBM SOA Sandbox provides a mix of full-version software trials and "try online" hosted environments where you can explore tutorials and get architectural guidance.
- Download the trial version of IBM Rational Software Architect V7.
- Download IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.
- Check out developerWorks blogs and get involved in the developerWorks community.
- Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect.