 | Level: Introductory Jim Amsden (jamsden@us.ibm.com), Senior Technical Staff Member, IBM
16 Oct 2007 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.
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
| Role | Task | 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 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
Figure 4 shows the ShippingService service
specification.
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
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
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.
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.
Invoicing
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 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
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
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 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.
Shipping
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
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
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.
Download | Description | Name | Size | Download method |
|---|
| RSM sample model | RSM_sample_model.zip | 60KB | HTTP |
|---|
Resources Learn
-
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
Discuss
About the author | 
| | Jim 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. |
Rate this page
| |
