Three years ago, a group of us at the former Rational Software Corporation sat down to write a paper on the issues of developing solutions using a service-oriented architecture (SOA) style, ¹ and a lot has happened since then. One of the problems we faced was that Rational Software had a set of modeling tools, but no IDE to actually develop the service implementations we modeled. Well, with the acquisition of Rational by IBM, we now have a world-class IDE in the form of the WebSphere Studio Application Developer (now Rational Application Developer, or RAD). We also faced the problem that a lot of thinking around SOA was immature, and much was hype-driven -- a problem we recognized in the paper. Since IBM's platform support for SOA has matured considerably and our developer tools have increased their capabilities for developing services in a flexible and rapid manner, we decided to revisit the notions of service design that we outlined in that earlier paper.

The result of this discussion was a new understanding: Our value is really not in the development of a model that presents all the gore of WSDL (Web Services Description Language) and XML, but one that allows designers and architects to specify the right services with the right capabilities and realizes the potential benefits of the SOA style. This understanding has led us to some long discussions about 1) the right level of abstraction for presenting a services model, and 2) the ways an SOA style of development would impact the Rational Unified Process®, or RUP®, if at all.

The first third of this paper presents the scope we set for the changes, including the requirements we focused on. I will next describe some of the key themes that we used as a framework for changes to RUP and the additions to Rational Software Architect (RSA) for supporting the development of service-oriented solutions. Finally, I will present some of the scenarios we used in our thinking; these were refined over time but also validated with some key customers.

Setting the right scope

We decided to develop not only a new modeling profile for RSA but also guidance to be added to RUP in order to help practitioners actually use the tools in envisioning and developing service-oriented solutions.

However, as we all know, one of the most critical aspects to any project is setting the right scope: too small and you deliver something of no practical value to anyone (except possibly being able to tick it off your own objectives to get your bonus); too large and it's like trying to boil the ocean. So we established the following criteria:

• The model we develop has to be at a level of abstraction above the current implementation technologies and standards (the WS-* specifications; that is, the various Web Services specs); however, it still has to present the concepts of an SOA as first-class elements.
  
  
• The resulting model has to be extensible to allow for the additional specification of concerns, such as security, quality-of-service, manageability, etc.
  
  
• The model has to be implemented in IBM Rational Software Modeler (RSM) and IBM Rational Software Architect (RSA), initially as a UML Profile.
  
  
• The guidance had to add specific SOA notions to the base RUP. However, we want to leverage as much as possible in the existing RUP, so initially we chose not to change anything that exists in order to allow the update to be added easily to an existing RUP configuration.
  
  
• Our efforts should take into account work already done by IBM in providing SOA guidance, such as the IBM Global Services SOMA techniques. ²

We therefore defined a set of three deliverables, each of which has now been made available through IBM developerWorks:

• A document describing the UML Profile for Software Services, ³ which follows the style of an OMG profile document.
  
  
• An RSM/RSA plug-in that implements the UML Profile for Software Services, ⁴ which allows models to be constructed within the tools and conforms to the profile above.
  
  
• A RUP plug-in that includes all our guidance on SOA architecture ⁵ and design topics, which provides specific guidance on the development of a service design model according to the profile above.

Thanks to the extensibility mechanisms available in the RSM and RSA tools, we were able to deliver not just the UML Profile for Software Services, but also a template model (available when you select File -> New -> UML Model) and a pair of samples added to the Sample Gallery.

This we considered to be a reasonable set of criteria and deliverables. So let's take a look at what we actually delivered in May 2005 to IBM developerWorks.

Back to top

Key concepts and themes

First, what is SOA? There are many definitions floating around, but let's take a software engineering viewpoint for a moment and simply say that SOA is an instance of an "architectural style." Which leads to the question, what is an architectural style? Here is a very good definition from Roy Thomas Fielding:

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style. ⁶

As an example, a documented architectural style is the "pipe and filter" style consisting of independent elements that use pipes as connectors to relate the filters together. There is the obvious, specific constraints that data type have to match between two filters connected by a pipe, and there are characteristics of the style that make it applicable in some contexts and not others.

With this in mind, we can begin to enumerate the architectural elements of an SOA along with the relationships and constraints specific to its style. Along with this useful definition of an architectural style, Fielding also offers this very timely advice:

Design-by-buzzword is a common occurrence. At least some of this behavior within the software industry is due to a lack of understanding of why a given set of architectural constraints is useful. In other words, the reasoning behind good software architectures is not apparent to designers when those architectures are selected for reuse. ⁷

It is this precise behavior that we hope to mitigate by providing concise and timely guidance through a specific set of additional content within the RUP. It is this guidance that describes the architectural style, the elements and relationships, and how these are identified, specified, and managed throughout the development lifecycle. Also note that the goal of architecture in general, and architectural modeling specifically, is to provide an appropriate level of abstraction at which the architectural elements are easily identified and manipulated without being obscured by details that should be added at lower levels of refinement toward actual implementation.

In the next few sections, we will discuss some of the key themes addressed within the RUP update for SOA -- in particular, the elements, relationships, and constraints each theme introduces.

Service identification and specification

Our criteria state that key SOA concepts must be presented through the model as first-class elements, so what are these key concepts? As one might expect, one of these concepts is the service itself; however, rather than being the centerpiece around which the model is built, this actually becomes a secondary element (not in importance, but as a model element, since it cannot exist independently). To construct a model of a service that reflects a WSDL-defined service, we have to first develop a service specification as well as a service provider.

A service specification is a set of three specification elements, all equally important; though, in some cases, they are optional in a model depending on the type of service being modeled:

• A structural specification. This can be thought of in terms of a standard UML or Java interface. It defines the operations that may be called and the messages that are consumer or produced by that operation.
  
  
• A behavioral specification. This denotes any meaningful protocol or conversation expected between a service consumer and the service being specified. For example, a service may require you to log on before calling another operation, which is termed a pseudo-conversational service. A service may also require the consumer to implement a particular interface so that it may be called back, and the protocol can demonstrate this.
  
  
• A policy specification. This denotes policy assertions and constraints on the service. Policy assertions may cover security, manageability, etc.

So, for example if we consider an order management service we might expect to see a structural specification that lists "place order," "cancel order," and "update order," as available operations. The behavioral specification for this ordering service might then describe how you cannot update or cancel an order you did not place, or that after you have canceled an order it cannot be updated. Finally, a policy specification may require that certain elements of the order are to be encrypted, denoting the encryption techniques to be used, certificates to use, etc.

One aspect of the guidance we have delivered in RUP is a set of techniques (described in the new activity identify services) for identifying services from the business process model, use cases, or existing assets of various forms. This activity and these sets of techniques allow architects and designers to produce a model of candidate services, which are service specifications that are often used to describe "idealized" services that would realize either a process or set of requirements.

We introduce the term "candidate service" because many of these services often have to be refactored to 1) fit with existing services, 2) fit within the framework of an existing functional architecture, or 3) be separated out to allow for more fine-grained or parallel development.

Managing a service portfolio

One of the major advantages to an SOA style of solution development is the move away from considering an application as a hard boundary within which development occurs (requirements are gathered, a solution is designed and implemented, and a project is managed). Within SOA, we now see an application as a dynamic entity, a configuration of services to meet a particular set of business requirements. To accomplish this, we need explicitly to design, implement, and manage the set of services in our enterprise as a portfolio of available capabilities.

This need is why we have specified the new identify services activity mentioned above. Not only do we consider the portfolio when identifying candidate services (please, no new wheels), but we also refactor services from their original form to fit with the form of the services in the portfolio. This level of reuse has to be supported not just by design tools, not just by a repository of information on the service portfolio, but also -- and most importantly -- by processes that guide practitioners in developing the right services the right way.

This does lead to one particular problem, which is that traditionally we have focused on the software development lifecycle as a process time-bounded by a project; in turn, a project was time-bounded by the development of some discrete part of a solution. In the case of the service portfolio itself (a combination of metadata about installed services and design models allowing for reuse), we see a lifecycle that cuts across the individual projects that use and contribute to it, as shown in Figure 1.

Figure 1: The service portfolio lifecycle

The service portfolio management process shown in Figure 1 is an ongoing activity. Note the manner in which the individual projects interact with the service portfolio by drawing from it during the Elaboration phase and then contributing to it during the Construction phase.

Partitioning service-oriented solutions

One problem with any model (or in fact any collection of elements) of any size is how to manage the model, how to categorize the elements, and how to organize them in such a way that the different stakeholders reviewing the model can understand.

This organization of the service model becomes important during both the identification of services and the ongoing management of services. Let us consider for the moment the typical method for model management in the UML 1.x -- packages. The problem with packages is that they manage model elements through ownership or aggregation; that is, once an element has been placed in a single package, it may be accessed by elements in a different package but cannot be "placed" in more than one package. Now, for those of us with a programming language background, this does not seem like a major problem; it mirrors the way packages, modules, or namespaces work in languages.

However, what we really need to represent are views into the model, because the set of organizations that are useful to the line of business owner will be different to the set required by the software architect, designer, developer, operations staff, etc. For this reason, we recommend that packages not be used as the primary mechanism for the management of views within the model (this is not to say that services do not appear in packages, just that packages should be used for more mundane organization of the model). Instead, we look to the composite structure notions of the UML 2.0 specification, which provides the ability to denote the internal organization of a classifier using "parts" and "connectors."

We use these techniques to partition the managed services; that is, to organize according to logical classification schemes, without needing the services to be "owned" by any one partition. For example, we might have two different views into the portfolio: one representing the different lines of business, and a second representing the "kinds" of applications providing the services, as shown in Figure 2.

Figure 2: Using partitions to organize according to logical classification schemes, without needing the services to be "owned" by any one partition

Note, the same services (smaller boxes) appear in more than one partition (larger boxes) with the lines of business represented by the top three partitions and the application kinds by the bottom three. From this we can see that although the supply chain line of business "owns" and manages the Shipping, Validation, and Warehouse services, we can see that the Shipping service is provided by our ERP package while the Warehouse and Validation services are custom developed.

This technique can be valuable not only in managing the set of developed services but also during the identification of services. Partitions can be used in this way to represent groupings of services, and as service specifications are being developed, they can be placed into different partitions to visualize the relationships and dependencies between them.

Back to top

RUP update

The RUP update for SOA has been extended in a number of (sympathetic) places to provide specific guidance on the development of architectural and design models of a service-oriented solution. But many areas of RUP remain unaffected by this update. For example, we decided early on in the development of the update that, although some industry writers have introduced new development roles supporting SOA, we believe that the current RUP Software Architect and Designer roles are more than adequate for the updates we require.

New and updated workflows

In updating the RUP to introduce guidance for SOA solution construction, we added only the following two new activities:

• Identify Services. Performed by the Software Architect within the Analysis & Design and Refine the Architecture workflows.
  
  
• Service Design. Performed by the Designer within the Analysis & Design and Design Services workflows.

The Identify Services activity is one activity performed by the software architect while outlining the architecture of a solution, the output of which is a service model. This service model contains a set of identified, yet candidate, services to be further refined by the designer as a part of the Service Design activity.

New and updated artifacts

The entire service model (representing the UML Profile for Software Services) and its enclosed elements are introduced into RUP by this update. The model represents an architectural abstraction for service-oriented solutions that allows software architects and designers to develop models where the notion of a service and the specific concerns of an SOA are first-class model elements. The model is not a direct representation of any implementation technology, such as WSDL.

Figure 3: The UML Profile for Software Services

New and updated guidelines

In addition to specific content describing the artifacts in the service model, the update also includes concept pages relating to the themes described above as well as additional guideline pages reflecting concerns of importance when developing SOA models. These concerns include:

• Message Design and Message Attachments. Designing messages, managing message catalogs for reuse and consistency of message schema.
  
  
• Service Data Encapsulation. Characteristics of service design around management of data within services and the relationship between data schema and service boundaries.
  
  
• Service Mediation. Specific guidance around the notion of mediation components that are commonly described as part of the SOA style (and specifically a part of the Enterprise Service Bus, or ESB, vision).
  
  
• State Management. A discussion of the merits of stateful and stateless services, including techniques for the specification and design of services that manage resource state.

We have also provided the guideline Going from Services to Service Components, which demonstrates one possible transformation from the service design model to a traditional design/implementation model.

The update also includes two report descriptions, an RSA tool mentor that describes creating a service model, and a reasonably complete example showing the development of a service model.

Back to top

RSM/RSA plug-in

The new plug-in for IBM Rational Software Modeler and IBM Rational Software Architect (referred to henceforth as the RSM/RSA plug-in) provides the UML Profile for Software Services, a template model for you to get started with, and a pair of sample models that demonstrate use of the profile. This plug-in can be downloaded from IBM developerWorks and added to the tool using the standard software update mechanism (note that the downloaded zip file represents an archived update site).

Within RSM or RSA, it is easy to create a new service model after the plug-in for software services has been installed. The following steps are steps required (note this works in the Modeling Perspective):

1. If you already have an existing UML modeling project in your workspace, you may add the service model to this project or create a new project (see Step 2).
   
   
• Either right click on the project and select New -> UML Model or from the File menu select New -> UML Model.
  
  
• When you see the New UML Model wizard, as in Figure 4, go to Step 3.
2. To create a new UML modeling project, go to the File menu and select New -> Project, the UML Project is under the Modeling category.
   
   
• In the resulting wizard, give your project a name and select Next.
3. In the New UML Model wizard, shown in Figure 4, ensure the destination folder is correctly set, select the Service Design Model from the list of templates, and name your model.

Figure 4: New UML model wizard

This will create and open a UML model with the UML Profile for Software Services applied to it and a template structure you may use to get started modeling your SOA solution. The model also includes a set of reusable model elements that are useful in creating some of the compound elements; at least using these is simpler than creating them by hand.

Back to top

Three Scenarios

The following sections outline three scenarios that we synthesized from discussion with customers regarding how they expect service-oriented solution development to fit in with their software development lifecycle. We started by identifying three approaches to the development of services, and while these are certainly not mutually exclusive (real projects use a combination of techniques), they are useful in illustrating different approaches and ideas.

Wherever possible, I've aligned the roles described in these scenarios with those defined in RUP.

1. Message-centric design

In message-centric design, the focus is very much on the service domain. Techniques such as domain engineering or Object-Oriented Analysis and Design (OOAD) provide much insight into the development of abstract domain models, and these techniques generally produce highly reusable models for message schema. The service design is usually a secondary activity, although it is sometimes done in parallel. In Electronic Data Interchange (EDI), for example, there is no real notion of a service interface, since EDI systems usually have a single global inbox and outbox for messages.

An example of such an approach might be in the traditional business-to-business arena, typified by EDI standardization. In this case, the primary design activity involves development of the message schema agreed upon in some industry or other scope, which is deemed to be representative of the schema of a class of messages -- for example, an EDI ⁸ Purchase Order, an ACORD ⁹ Claim Inquiry, or a SWIFT ¹⁰ Credit Transfer.

In many modern standards activities, such as SWIFT or RosettaNet, ¹¹ there is often a design process for standards that includes a hybrid message-centric and service-centric approach where techniques, such as use case analysis, are used.

Scenario

In this example, the customer is a large insurance provider developing new applications to support one of its lines of business. The alignment between the business and supporting IT in this company is reasonably good, with a solid focus on delivery of value to the business through IT.

The project in this scenario is the extension of two claims processing systems so that both systems can provide service-oriented interfaces that will enable their tactical integration and allow the company to retire one system and move all claims processing to a single system.

The line of business folks want the services to support some existing business processes, but they've made it clear that these processes change over time, so coupling the services to the process would be impractical. In response, the software architect for this business area believes a more appropriate approach might be to focus on the business artifacts in the process, primarily the claim itself. Besides, he notes, they have already made an investment in IBM IAA, ¹² which offers well-defined and standardized models for artifacts such as the claim.

In this regard, the actual data model for the primary artifacts has been already specified by IAA, so the main effort will be to understand the way these artifacts are used in the current system and how a new facade can be developed for them encompassing their differing implementations.

Activities

The Business Analyst begins to document requirements, using business process models to describe functional requirements of the system as well. Non-functional requirements are described in a requirements database, attached to tasks and items in the business process model. Process models are developed for both current systems and the intersection of both.

The Software Architect takes these models and requirements and works with the Business Analyst to develop more detailed process models that focus on the flow of artifacts in common between the two systems. The Software Architect also works with the Business Analyst in understanding the data requirements of the current systems and their relationship to the IAA data model.

The Data Architect works with the Software Architect in drawing up schema for the logical and physical representations of the artifacts in the new processes.

The Software Architect develops a candidate service model that partitions the process activities into a set of service operations. This model also includes the message requirements for each service and the relationship of these messages to the underlying data model.

The Software Architect works with Integration Specialists (not currently a RUP role, but a description for this role is being planned for RUP) to define the mappings required from this candidate model to the current implementations, where they exist. These mappings will be implemented in the chosen middleware but should not be so onerous as to introduce major performance issues.

2. Service-centric design

In this approach, the designer is concerned with exposing, as a service or set of services, functions expected of the business or application. In this case, we do not necessarily know what the client of the services will choose to do with our service, yet we do know the kinds of interactions such clients will expect. Therefore, in contrast to the first scenario, messages tend to be secondary and are developed in response to the requirements of an operation.

An example of this approach would be the Web Services APIs presented by Amazon (AWS) ¹³ and eBay. Such service interfaces do not impose a business process on the client; in most cases, they do not even impose required interfaces on the client, yet they expose the operations of their respective service providers in a clear and intuitive way to third-party developers.

As mentioned above, service-centric modeling often lends itself well to a use-case driven approach by understanding the needs of actors (external clients of the service) and providing operations that support these needs (browsing catalogs, adding items to a shopping cart, checking out, etc.).

The issue of messages being a secondary concern is evident in the Amazon API, where common schema definitions could certainly be factored out of the current design; this demonstrates that messages were developed individually for each operation request and response.

Scenario

Here our example is an online provider of components for the chemical process industry. A business provides a Web portal through which customers can buy parts and conduct further business through phone and fax. But it needs to provide its customers access to the purchasing portal via more programmatic means than through the Web itself. This access to core ordering capabilities allows the company to be a key element in its customers supply chain, an element that can be directly integrated with the customers core business applications. At one point, the business had attempted to implement an EDI purchasing solution, but the cost of initial deployment as well as the required infrastructure proved prohibitive. The executive team believes that a number of customers are moving to other providers who offer such purchasing portals, because these competitors have been able to integrate them better through their more automated processes.

Compared to our first scenario, this project is far more driven by the IT organization. The project goals, from a business standpoint, are simply to provide a mechanism to perform the same ordering operations without having either the customer spend time entering data into the Web portal or the business entering similar data from faxed order forms. The IT organization is allowed to make many decisions independently, as long as it can produce a solution that's less costly than the previous EDI attempt.

Two important observations affecting design have been made by the senior team in the IT organization.

1. The functionality provided must not be any less than the current capabilities offered via the Web or manual ordering.
   
   
2. The set of operations are not driven by our business processes, but rather are used by a customer as part of their processes. For this reason, we must assume as little as possible about the use of these operations.

The Software Architect produces a set of use case documents describing the kinds of capabilities expected by customers and ensures that the business team agrees to them. The use cases are then broken down into a set of discrete operations and the data requirements (messages) are specified. These operations are then aggregated into a set of three services for search, ordering, and account management. This step tends to be driven more by experience and judgment than by precise metrics and thus may be iterative.

Once the services and the set of operations are known, the team defines the service specifications more formally, including the protocols for each interface and any policy information that is required by service consumers. This step is extremely important: It provides consumers with information that cannot be understood from simply reading the WSDL deployed by the business when the services are ready for use.

Activities

The Business Executive (not a current RUP role, but seems we all live with them) communicates a need to provide clients access to our business services programmatically as that person feels the business is losing revenue to larger providers that currently provide such capabilities.

The Software Architect proposes to develop a set of services that provide the core capabilities of the Web ordering system. The proposal includes a set of use cases describing the activities that customers perform today via the Web (developed with a Business Analyst from the online business). Also included is an Inception-phase model demonstrating the candidate services and their relationship to the current back-end system.

The Software Architect, on approval of the project, iterates on the candidate service model to identify the services in the back-end application partitions that publicly expose the business functions required to support the services. In parallel, the Software Architect has a Designer look at the current Web application and how it interacts with the back-end system, mining out any required business logic and requirements to be implemented by the services.

The Software Architect and Business Analyst agree on the set of required functions to be provided as operations by the services and any constraints or policies required. This iteration of the model now shows three concrete services as well as initial service specifications, although these only specify the structural aspects of the services at this point in the process.

The Software Architect works with Developers on the Web application team to understand the specific data requirements for the identified set of operations. This is handed to a Data Architect with XML skills to develop a message model that will generate the schemas for the messages to be consumed and produced by the operations.

The Designer can begin to connect the service model with an implementation model (J2EE) that will be used to describe the components that will provide business logic and connect with the existing back-end applications.

The Software Architect and Designer finally refine the service model with details on the service specifications, primarily providing protocol and policy details that enable a consumer to understand how to interact with the services.

We now have a complete set of models:

• A use-case model describing the customer expectations
  
  
• A service model describing both the consumer view (service specifications) and provider view (services, partitions, etc.)
  
  
• A set of implementation models describing the software components realizing the service specifications

It is now possible for the Developers to implement the pilot system ready for a select set of customers to use.

Follow-on actions

Following the successful deployment of the pilot project, it was noted that the provision of the services to clients involved a parallel implementation of certain functionality to the Web system. A new project was proposed to reconfigure the Web application to reuse these services; this effort would be included in regularly planned updates to the Web application. Such a reconfiguration moved certain business logic from the Web application into the services; thus, a single set of components are used for both Web- and service-based customers.

To address performance concerns by the Web application team, the services were also reconfigured to provide more efficient Java bindings when accessed from the Web application, in addition to the SOAP/HTTP bindings provided to partners.

3.Collaboration-centric design

In a collaboration-centric approach, the focus is on the collaboration of two or more services; this is very much a process view of the services and is related to more traditional business modeling than it is to a software development activity. In this approach, services are seen as fulfilling roles in the collaboration, and the service specification is therefore the set of responsibilities defined for the role across one or more collaborations.

Such an approach will be recognizable to those that have been involved in the development of RosettaNet Partner Interchange Processes (PIPs) or in the development of the OAGIS ¹⁴ standards (however, the collaborations are less than complete in these cases). Such an approach would be common within a business in terms of either business process design or in business integration activities in which the components of an IT system are exposed as services.

Usually in scenarios like this, the service specification can be derived directly from the collaboration, yet this approach tends to focus less on message content leading to a requirement for a hybrid approach for completeness.

Scenario

This scenario involves a mid-tier banking organization that has decided to pursue a strategy of growth through acquisition; this means it is an organization for whom IT is not just a must-have, but rather a part of the business that delivers competitive advantage in absorbing acquired operations.

The bank has developed a leading portfolio of applications carefully managed to ensure both cost and capability efficiency. However, it is clear that certain technical and cultural inhibitors exist in the vision to provide a common set of applications across the whole organization. Because of these inhibitors, the company has decided to use a services approach to provide their IT capabilities and to develop all new capabilities in such a style. The organization has, over the years, developed a very process-centric mindset. These well-understood, common processes allow them to effectively integrate acquired organizations as well as direct their IT in support of these processes. By design, the IT organization is closely aligned with the business teams who define the processes that run the banking group -- i.e., for this organization, the well-documented "business vs. IT gap" simply does not exist, because both groups have been organized to eliminate it.

In our scenario, the bank is bringing one of its legacy applications into the service portfolio, which gives us the opportunity to look at the process model for account consolidation, a business service that lets the organization assist customers in making more efficient use of their accounts. This process model has been designed with a number of "black box" activities, meaning that an activity is usually performed either by systems that are not enabled as part of the service portfolio, or in ways that have not yet been detailed. The model denotes these activities as "black boxes" and no more details can be provided. The team has noted that a certain legacy application participates in three activities in the account consolidation process, and an analysis of other process models uncovers two other processes where the same application is used.

In the method that the organization has come to rely on, the process models are the primary artifact for analysis and requirements gathering. The process itself represents the complete embodiment of the functional requirements of the business through the IT and corresponding personnel; attached and formally defined documents describe non-functional requirements. Such process models are carefully maintained under configuration management and published for each operational process so they not only guide the development of the process but also provide material for training the bank's staff in the processes.

The service portfolio mentioned earlier is a RAS ¹⁵ repository that allows for searches based on criteria defined by the RAS manifest in each asset. The assets are deployed services and the manifest consists of a core profile for describing services and extensions describing business information, such as ownership, policy, and so forth.

In developing the services to provide the capabilities of the legacy application, a team consisting of business and IT representatives focuses on the collaboration between services as the realization of a business process. This approach allows the business side to see the result as a traditional business process model, while the IT side sees the same model as a collaboration between services.

Activities

The Business Analyst either creates a new business process model or updates an existing one. This model describes the new process as envisioned by the business; this process update also includes the definition of business documents managed, consumed, or produced by the process activities. The Software Architect creates a gap analysis document that compares the requirements of the new business process against the existing service portfolio.

The Business Analyst defines Key Performance Indicators (KPIs) ¹⁶ as part of the business process itself. This implies that the services participating in the process have to support metrics that can be queried to ensure conformance with the KPIs.

The Data Architect refines the message definitions from the business process model, ensuring commonality with existing schema, then develops a message model that can be used to generate the XML schemas required for the services.

The Software Architect updates the service models with either new services or adds new specifications to existing services. The message models developed by the Data Architect are used (or reused) for these service specifications.

The Software Architect and Business Analyst update the process model defined earlier to map activities to the new or updated services. The model is now complete with respect to the service updates; it may now be versioned and published.

The Software Architect and Designer develop detailed service specifications that include the protocol and policy information. Such a detailed specification acts as a contract between the provider and consumer, which cannot be broken by either party.

The Developers create adapters and/or transformations against the legacy application for implementation of the detailed specifications.

The Developers have to develop the metric producers for monitoring. These are generally specific operations required for the monitoring infrastructure to query the service for general state and state of the metrics.

The Integration Specialist Updates process choreographies with new services -- in this case, the business process is transformed into a choreography language, Business Process Execution Language (BPEL). In some cases, the generated choreography has to be updated with some additional information before deployed.

The Business Analyst updates the monitoring middleware with the business KPI definitions and their relationship to the detailed metrics so that the new services are monitored.

Back to top

Next steps

IBM Rational teams have worked with a number of customers and on internal IBM projects demonstrating or using both the RUP and RSM/RSA plug-ins. We have received enough feedback to know that while we have much more we could do, we have laid a good and solid foundation. We are now working on a set of specific projects designed to stretch the work we have done and see where we can add more content, specifically in the area of policy specification for the modeling tools and additional guidance topics in RUP.

Back to top

Notes

¹ Alan W. Brown, Simon K. Johnston, and Kevin E. Kelly. "Using Service-Oriented Architecture and Component-Based Development to Build Web Service Applications." IBM developerWorks, 2003.

² See Ali Arsanjani. "Service-Oriented Modeling and Architecture." IBM developerWorks, 2004. http://www.ibm.com/developerworks/webservices/library/ws-soa-design1/

³ Simon K. Johnston. "UML Profile for Software Services." IBM developerWorks, 2005. http://www.ibm.com/developerworks/rational/library/05/419_soa/

⁴ Simon K. Johnston. "UML Profile for Software Services, RSA Plug-In." IBM developerWorks, 2005. http://www.ibm.com/developerworks/rational/library/05/510_svc/

⁵ Simon K. Johnston and John Smith. "RUP Plug-In for SOA V1.0." IBM developerWorks, 2005. http://www.ibm.com/developerworks/rational/library/05/510_soaplug/

⁶ Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures. Dissertation. 2000.

⁷ Ibid.

⁸ See ANSI X.12 at http://www.x12.org/

⁹ See Association for Cooperative Operations Research and Development (ACORD) at http://www.acord.org/

¹⁰ See SWIFT at http://www.swift.com/

¹¹ See RosettaNet at http://www.rosettanet.org/

¹² See IBM Insurance Application Architecture at http://www-1.ibm.com/industries/financialservices/doc/content/solution/278918103.html

¹³ See Amazon Web Services (AWS) at http://www.amazon.com/gp/aws/landing.html

¹⁴ See the Open Applications Group at http://www.openapplications.org/

¹⁵ Reusable Asset Specification. Object Management Group, 2004. http://www.omg.org/cgi-bin/doc?ptc/2004-06-06

¹⁶ For more information, see http://management.about.com/cs/generalmanagement/a/keyperfindic.htm

About the author

Simon Johnston works on the SOA tooling strategy team within IBM Rational Software, responsible for the development of business, design, and construction tooling convergence around SOA. He has undertaken a number of standards-related activities for both Rational Software and now IBM in the area of XML (W3C Schema working group), Web Services (RosettaNet architecture team), and Modeling (OMG UML and OCL teams). He has also written articles on the subjects of business modeling, software modeling, and SOA. In addition to his articles for IBM developerWorks and The Rational Edge, Simon has a weblog on developerWorks. He can be reached at skjohn@us.ibm.com.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Setting the right scope
• Key concepts and themes
• RUP update
• RSM/RSA plug-in
• Three Scenarios
• Next steps
• Notes
• About the author
• Comments

Next steps from IBM

• Try: Rational Software Architect
• Demo: Model Rational RequisitePro requirements in Rational Software Architect
• Webcast: Harnessing the power of enterprise architecture
• Briefing: Architecture, design, and construction using the IBM Rational Software Delivery Platform
• Buy: Rational Software Architect

My developerWorks community

Dig deeper into Rational on developerWorks

Rate a product. Write a review.

Write a review for Rational products today!

Special offers