Semantics are essential in any domain, especially SOA. SOA spans teams and organizations, so agreement upon relevant terms is crucial. This series provides a tour of SOA by defining terms and the key concepts behind them. You'll learn the vocabulary necessary to understand and communicate in the SOA field. For each term, you'll learn its importance, what it means in this context, what the relevant standards are, and how the term differs from others in the SOA field.
Part 1 had a business focus and set the stage by defining terms like service and SOA. Part 2 covered development processes, models, and assets. In this part, the third installment in the series, you explore the terms and techniques associated with designing an SOA at a high level of abstraction (analysis) and how to move forward to a lower level of abstraction (design) that's just above the code level.
The terms listed below are not organized alphabetically, nor are they shown in order of importance. Rather, they are organized in a building-block fashion. Part 1 began with service, because it's probably the most important concept to understand the SOA framework. The next parts of this series build on the service concept and define other terms by grouping concepts that relate to specific disciplines, such as analysis and design in this part.
The IBM® Rational® Unified Process® (RUP®), described in Part 2 of the series, defines a discipline called analysis and design, which sits between requirements and implementation. Analysis and design includes activities that specify the initial IT architecture based on a set of functional and nonfunctional requirements. It's also based on other activities that further detail this initial architecture from an analysis level of abstraction to a design level that's detailed enough for developers to generate and write the implementation code.
SOA analysis and design is also referred to as one or more of the following terms:
- Service modeling
- Service-oriented analysis and design
- Service-Oriented Modeling and Architecture (SOMA)
- Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)
Analysis involves describing what the system to be built is at a high (conceptual) level of abstraction. The input of analysis is a set of requirements and existing assets (or applications or systems). The output is a description of what is to be built. Analysis is critical for SOA, because it's where IT meets the business during service identification. The result of analysis is used as input for design.
Design involves describing what the system to be built is and, more importantly, how to build it.
Most of the architecture (described in Part 1) work is performed during the analysis and design workflow, in the elaboration phase of a project.
Service-oriented analysis and design leverages existing analysis and design principles, such as the ones in object-oriented or component-based development. For example, you may remember that there's something called Object-Oriented Analysis and Design (OOAD). It’s important to note, however, that SOA efforts are always centered on services (as opposed to objects or components).
Note: Analysis-level models often evolve into design-level models, so there's only one RUP discipline for analysis and design.
The main output of a service-oriented analysis and design effort is a service model (previously referred to as service specification) that documents all of the architecturally significant parts of the service-oriented system and a design model that further details how the service model should be realized (implemented). These two models fully specify the SOA design and are enough for developers to unambiguously perform implementation.
In the following sections, you get an introduction to the terms associated with service-oriented analysis and design with descriptions of the associated tasks.
Note: The terms identification and specification were used in component-based development, and the terms specification and realization are defined by the Unified Modeling Language (UML). These three terms form the core activities of RUP SOMA (with the same meaning).
Service identification is the core service-oriented analysis activity. The goal of service identification is to identify groups of conceptual services and their operations.
These identified services are needed by and meaningful for the business. In fact, business analysts help software architects perform this exercise. In the next section about service design principles, you learn about the need for logical groupings of services and business-relevant names for services and their operations. These are decided during service identification, using techniques like the ones described in RUP SOMA.
In Part 1, you learned about the SOA solution stack reference model, with its functional layers — consumers and business processes at the top, services in the center, and operational systems and components at the bottom. Based on this model, you can take different approaches to identify services (depending on whether you start from the top or the bottom of the diagram). Let’s take a closer look at these:
Starting from a set of business objectives and goals, it's typical in SOA projects that the business architecture effort has identified one or more business processes to focus on. As a result of the business modeling effort, there may be designed business processes (the to-be processes) that can be seen as the functional requirements for the system under design.
The top-down approach is about decomposing business elements (mainly business processes and use cases) and refining them into a granularity that makes sense for services. During a top-down approach, you typically identify service operations from business tasks. The advantage of this is that you can be assured that the identified services are business aligned!
The bottom-up approach is about analyzing existing IT assets (such as legacy applications and systems) and finding functionality that could be exposed as services, to be reused by many.
Reuse is an important part of SOA and critical to its success. As you probably know, your legacy applications (that is those that have already been deployed) are your company’s most valuable assets and should be leveraged. For example, the bottom-up approach analyzes existing Information Management System (IMS) transactions or COBOL programs.
A word of caution about bottom-up analysis: You have to be careful not to blindly expose existing IT capabilities. For example, Create Read Update Delete (CRUD) data services may be too fine-grained and not business aligned.
Note also that the use of existing asset-analysis tools, such as IBM WebSphere® Studio Asset Analyzer, is critical because often nobody knows exactly what is deployed and running!
The meet-in-the-middle approach is about reconciling needs (the services identified by the top-down analysis) and what's already provided by existing IT assets.
The meet-in-the-middle approach requires collaboration between business analysts, software architects, and specialists for the legacy applications. Note that although it's valuable to perform bottom-up analysis outside of the context of a specific project (for example, an enterprise architecture team doing inventory of candidate services), in practice, however, efforts usually start with the top-down approach and the decomposition of one or more business process as part of a project. Then, in this context, bottom-up analysis occurs to try and find matches for the required services (meet-in-the-middle approach).
Based on the three described approaches, a set of services and their operations are identified, validated (for example, validation makes sure that services don't already exist or are business aligned), and grouped into logical categories (such as business components or business functional areas). Business items (such as, policy or claim) are also identified, mainly from existing data legacy applications. The next step is to fully specify what these services and their operations are in terms of structure and behavior.
Service specification and realization are the core service-oriented design activities. Service specification is about designing the structure and behavior of the service elements that are architecturally significant.
The main output of service specification is the RUP SOMA work product called service model, which includes artifacts like service specifications (interfaces), service providers, and service collaborations. A service model should be complete enough so that service providers and consumers unambiguously know what the service is.
Specifying services includes designing the following:
From the service model, a service specification artifact is an interface that describes the operations offered by a service.
Optionally, service messages can be designed to act as operation input, output, or fault parameters.
You may recognize the interface and operation concepts from the object-orientated paradigm. The emphasis on messages, collaborations, and policies (described later in this article) can be seen as the evolution provided by service orientation.
A service specification is used as the contract between a service provider and a service consumer. It defines the structure and behavior of a service.
From the service model, a service provider artifact groups a set of related services together.
A service provider includes:
- Required service specifications (when the service is a composite one and part of a collaboration, as described in the following section).
- Provided service specifications.
- Provided services.
For example, there may be a coarse-grained service provider called Sales Management, which supports the sales management functional area. This service provider may provide two services called Account Activation and Application Inquiry, with the Account Activation service typed as the Account Activation service specification.
Service provider design is where principles from component-based development should be leveraged. Service providers are typically represented at UML components and then services as UML ports on these components. Note: The services (ports) are typed with service specifications.
From the service model, a service collaboration artifact represents the communication between two or more services. Service collaboration specifies the dynamic behavior of services within an environment with other services.
Terms related and somewhat synonymous to collaboration are choreography, orchestration, or composition.
Atomic services are fine-grained services that don't require other services. Composite services are larger-grained services that require other services to provide their services. Therefore, composite services act as service consumers and always need to have associated service collaboration.
In Part 1, you saw that the Business Process Execution Language (BPEL) can be used to specify an executable version of a business process flow. It also plays an important role in the area of service collaboration as it can be used to implement a composite service as a collaboration of atomic services.
Note that, although this article doesn't go into it because it’s too detailed, service consumers and service partitions (the structure of the SOA) also need to be addressed by the design.
As with traditional (non-SOA) approaches, the design needs to address both functional (such as use cases and business processes) and nonfunctional (such as quality of service, or QoS) requirements.
A QoS description should be part of the service specification. Also, you should use proven design patterns to address them. (Design patterns are typically heavily used during service realization.)
The policies regarding usage of services need to be tackled at the design level, too. Policy is covered in a later part of this series.
Model-driven development (MDD) approach
For the design to be explicit, complete, and unambiguous, you need to rely on modeling languages, such as UML (see Part 2) to design services. For example, remember that service providers are typically represented by UML components with UML ports. Also, UML collaborations or sequence diagrams support the modeling of service collaborations. More specifically, you should use UML profiles for service-oriented design, such as the UML 2.0 profile for Software Services, introduced in Part 2.
MDD lets you model and specify elements at different levels of abstractions. You've probably noticed that this series goes into lower levels of abstractions as it progresses. It started at the business level, moved to analysis, and now design. In following installments of this series, you'll learn about implementation (at the code level). MDD provides semiautomated transformations from one level of abstraction to another. For example, you'll see that you can generate the Web Services Definition Language (WSDL) files from the service model work product. Also, you can eventually generate the code (usually from the design model) that will be used as the base for your SOA implementation.
The MDD approach also allows traceability, which is basically going from lower to higher levels of abstraction. For example, you can link a design decision to the requirement(s) that it's addressing. This allows rapid analysis of the impact on your design of a change in requirements.
In this domain, I strongly recommend that you look at the following terms, which are described in previous parts of this series. You can also find more information about them in the Resources section at the end of this article:
- The Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA) process
- The IBM Rational Software Modeler (RSM) Rational Software Architect (RSA) tools
- The UML 2 Profile for Software Services
- The SOA design assets and patterns available on the developerWorks RAS repository
- Business services modeling, which provides a mapping between business process modeling elements and UML elements
Service realization is about designing how services will be implemented. It's the most detailed design, just before the code level. It's not about implementing (constructing) services, as Part 3 will describe, but about describing at the design level how the services should be implemented. Service realization is performed by the software architect and the designer.
There's a fine line between specification and realization. Here's an easy way to look at it the difference between them: If service specification is about what, then service realization is about how.
The design model, as defined by RUP SOMA, is the core output work product from service realization. It describes the realization of the SOA and acts as an abstraction of the implementation (including code). The output of service realization, it's used as input for service implementation.
The main design model artifact you should focus on is the service component — which represents how one or more service specification is realized — and how all of the functional and nonfunctional requirements and structural and behavior specifications are addressed.
A lot of new classes are also created during service realization to refine the service components and services. The definition of the structure and behavior of these classes is thus performed as well.
As previously stated, service realization should make heavy use of design patterns (for example delegation, singleton, and factory), which are typically applied to the classes designed during service realization.
During realization, you make decisions about a variety of technologies. Web services have proven to be a reliable platform of choice for SOA. From the service model, MDD tools like IBM Rational Software Architect can generate the Web Service Definition Language (WSDL) for the service providers and specifications as well as the associated XML schema files (.xsd) that define the messages that flow between service providers and consumers. WSDL and XML Schema can arguably be an output of service realization or one of the initial outputs of service implementation.
Making technology choices has a huge impact on quality of service. Some technologies don't support the requirements you may have. An example can be illustrated in terms of reliable message delivery or performance (such as throughput). It's a good practice to map technology choices to partitions, as with traditional (non-service-oriented) design. In the case of SOA, the service partitions that were defined during service specification may need to be revised during realization to have associated service policies (access channels, security, performance, and so on) addressed by specific technologies. Think, for example, of performance requirements that would imply in-memory transactions, or interoperability requirements that would imply the use of SOAP and Web services, or when to use local invocations instead.
After you're done with service design, the next step is to implement (construct) services based on this design, as will be described in the next part of this series.
This section lists four service design principles that you should have in mind when designing SOA solutions. Note, however, that this isn't an official or comprehensive list and that some of the concepts originate in other paradigms, such as object orientation. These principles are important in the design of service-oriented solutions.
Always have reuse in mind when designing services. Usually, you have specific requirements from specific service consumers at design time. However, if you want to reap the benefits of SOA, you want the services you design to be reused by other consumers with slightly different requirements. You don't know these consumers and what their requirements are at the time you create the design, so it's not an easy task!
Some of the things you can consider are:
- Providing a meaningful and descriptive name for services and their operations based on business domain, not technology.
- Making services discoverable by providing complete human and machine-readable specifications published to a service registry (see the following parts of this series for more information).
- Quality of service for usage scenarios that are different from the initial one, for example, plan for increased demands and workloads when the service becomes popular.
- The possibility of extending the initial functionality provided by the service (based on the initial set of requirements) to make the service complete.
- The possibility of implementing a service specification on a number of different platforms.
Coupling refers to how much entities or systems depend on one another. Within the SOA context, you can think of coupling between a service specification and its provider or implementation, or coupling between a service provider and a service consumer. To support the agility promised by SOA, coupling should be loose.
A service provider shouldn't have to know about a specific instance of a service consumer, and vice-versa. Replacing a service provider or the implementation of a service should have only minimal or no disruptive effects on consumers.
To help achieve loose coupling, consider the following:
- Separate service specification (the service and design model described in this article) from service implementation. As described in the MDD section in Part 2, it's important to have full specifications for services, which are independent of a particular implementation. Also, the service contract should be at the specification level (not at the implementation level).
- Using tools, formally describe a service specification in both human-readable and standard machine-readable format (for example, WSDL and WS-Policy) so that code generators can help with the implementation of services (Part 4 of this series will have more information about this).
- When developing service consumer code, keep in mind that there may be service intermediaries or other providers, and don't hardcode any information about an instance of a provider.
Transactional state means that a service needs to have information about things that happened as part of a long-running transaction between a specific instance of a service provider and a specific instance of a service consumer. For example, the result of invoking a service operation is different if the operation has already been invoked, or another operation needs to be invoked before an operation can be invoked. Although it can be found in component-based development, transactional state should be avoided with SOA.
Data (information) state means that the state of data instances needs to be managed. Some services typically need to manage data state. Take the example of a Claim service in the insurance industry. This service has to manage the state of Claim instances, especially because these instances are accessed by many different consumers over distinct business transactions. Note that services that hold state are typically atomic (fine-grained). To address state requirements, you rely on the underlying technology used for implementation, such as Java™ Platform, Enterprise Edition (Java EE) with stateful session beans.
For service-oriented design, you can think of granularity at the service provider level (how many services are provided) or at the service specification level, for example. A service specification is a logical grouping of service operations. Here, logical means that it makes sense as far as the business is concerned. For example, a Claim Processing interface in the insurance domain provides all of the operations needed in claim processing usage scenarios. It also makes sense as far as IT implementation is concerned. For example, all of the service’s identified operations are implemented in the same development iteration.
When designing services operations, consider collaborations, usage scenarios, and
the messages (number and size of them) that will flow between service providers
and consumers. Coarse-grained operations provide more business value and allow for
easier modifications of implementation. Coarse-grained operation parameters (using
messages for input, output, and fault) are less error prone. Using fine-grained
parameters instead of messages, however, is usually more descriptive. For example,
if a service operation signature is
determineEligibility(application: ApplicationMessage),
then you need to look at the definition of
ApplicationMessage. If the signature is
determineEligibility(customer : Customer, product : Product, date : Date, amount :
Amount),
it's more descriptive. Also, the Customer or
Product parameter types, for example, can be reused in
other operations, unlike the ApplicationMessage.
For service granularity, always keep in mind that services should be composable. This is related to reuse and the ability to provide new functionality based on existing functionality. A set of services at a certain granularity level can be choreographed, and the result would be another more coarse-grained service. Think, for example, of having business tasks provided by services and then having a sequence of these business tasks (a business process) provided as a service as well.
At the end, making a design decision on service granularity is always a tradeoff between performance (for example, size and number of messages being exchanged and efficient implementation) and potential for reuse. Also, a typical SOA contains both fine-grained (atomic) and coarse-grained (composite) services.
This article covered the terms that relate to the IT architecture and design of SOA solutions. You saw where IT meets the business needs during service-oriented analysis and moved down the abstraction level path to further detail the design. Starting with a set of requirements, you learned about the activities that take place (and their associated terminology) to design an SOA that meets the requirements. The result is a design that's detailed and unambiguous enough to be used for implementation, which will be the topic of Part 4 of this series. Stay tuned to developerWorks for more (and use the RSS feed link in the Resources section to access the next installment as soon as it's available)!
I would like to thank my IBM colleagues who contributed a lot to SOA. Thanks to my co-authors of "Building SOA Solutions using the Rational SDP," one of the IBM Redbooks®, with whom I've learned a lot in the area of service-oriented analysis and design. Specifically, I would like to thank Alessandro di Bari for his review of this article.
Learn
- Visit the IBM
SOA Foundation page.
- Check out the IBM Systems Journal
"Impact of
service-oriented architecture on enterprise systems, organizational structures, and
individuals."
- Read the
Wikipedia entry
on object-oriented analysis and design.
- Learn about
IBM WebSphere Studio Asset Analyzer.
- Learn more about the
RUP for Service-Oriented Modeling and Architecture Plug-in V2.4
- Get the free trial download for
about
Rational Software Architect (RSA)
- Read "UML 2.0 Profile for Software Services"
(developerWorks, April 2005).
- Check out "Building SOA Solutions Using the Rational SDP," one of the IBM Redbooks.
- Read the "Design SOA Services with Rational Software
Architect" tutorial series.
- Reuse assets from the
IBM developerWorks Reusable Asset Specification (RAS) assets repository,
also available from Rational Software Architect (RSA) wizards.
- Read the article "Business Services Modeling" (developerWorks, December 2005).
- Read "SOA realization: Service design principles"
(developerWorks, February 2006).
- Check out this demo to learn how to Build a UML 2.0 Sequence Diagram with Rational Software Architect
- The SOA and Web services zone on IBM developerWorks hosts hundreds of informative articles and introductory, intermediate, and advanced tutorials on how to develop Web services applications.
- The IBM SOA Web site offers an overview of SOA and how IBM can help you get there.
- Stay current with developerWorks technical events and webcasts.
- Browse for books on these and other technical topics at the Safari bookstore.
- Get an RSS feed for this series. (Find out more about RSS.)
Get products and technologies
- Innovate your next development project with IBM trial software, available for download or on DVD.
Discuss
- Get involved in the developerWorks community by participating in developerWorks blogs.
Bertrand Portier is an IT architect with SOA Advanced Technologies, IBM Software Group. He works in the field on strategic SOA transformation projects and, based on these experiences, works with IBM Software Group development teams. His background is in J2EE and Web services, and he is now heavily involved with asset-based and model-driven development.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
With the no-charge DB2 Express-C, pureXML and evolving your XML schemas you can easily increase development and application performance.
- Try: Download a free trial version of DB2 Express-C, which includes pureXML technology that is ideally suited for managing XML schema and relational data.
- Article: See how to use DB2's pureXML schema evolution capabilities, that evolve schemas without making any changes to your applications.
- Tutorial: This tutorial shows you how using a native DB2 XML database enables changes in an existing XML schema to also appear in your application code.
- Demo: This demo shows you how easy it is to create a DB2 database for storing XML data.
- Buy: DB2 9 for Linux, UNIX and Windows
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
