Work Product: Service Model

IBM Rational Unified Process

Service Model
Work Product Template
Template Copyright International Business Machines Corporation 2006

1 Description
The Service Model augments other Work Products by capturing information related to services that is not captured in other work products. Information documented in the Service Model is the result of work that spans the identification and specification of services as well the decision-making that is needed to support service realization. The Service Model is composed of several sections (Figure 1 Service Model), each of which is summarized below in Table 1: Service Model Detail. The Service Portfolio and Service Hierarchy are produced during RUP/SOMA Identification. Realization decisions are captured during RUP/SOMA Realization activities. The remaining sections are produced during RUP/SOMA Specification.

Figure 1 Service Model work product organization

Work Product Template

Page 1 of 13

Work Product: Service Model

Section Service Portfolio

Description List of candidate services discovered during RUP/SOMA service identification activities.

RUP/SOMA step where created RUP/SOMA Identification: Domain Decomposition Goal-Service Modeling Existing Asset Analysis

Service Hierarchy

Candidate services organized using a business significant categorization scheme, making evaluation of candidate service more manageable. Domain Decomposition Functional Area Analysis typically provides the classification scheme. Documents the rationale behind why we chose to expose a given candidate service or group of services in the service hierarchy or composition. The Service Litmus Test is applied to candidate services to make exposure decisions. Documents dependencies between services in the model.

RUP/SOMA Identification: Domain Decomposition: Functional Area Analysis Service Specification: Exposure Decisions using the Service Litmus Test Service Specification: Service Dependencies

Service Exposure

Service Dependencies

Service Composition and flow

Identifies which services are choreographed together to form a composite service.

Service Specification: Service Composition Flow Service Specification: Service Non-functional Requirements Service Specification: Service Message Specifications Service Specification: State Management Decisions Realization: Service Allocation to Components

Service Non-functional Requirements

Documents the non-functional requirements that dictate those characteristics.

Service Messages

Documents messages that are exchanged between service consumer and service provider.

State Management Decisions

State can be an important consideration for composite services and the related decisions are documented here. Documents architectural decisions that deal with how the services will be realized, such as buy, build, subscribe, etc. Nonfunctional requirements are prominent criteria in many of these decisions. Realization Decisions are documented in the Architectural Decisions work product. Table 1: Service Model Detail

Realization Decisions

Work Product Template

Page 2 of 13

Work Product: Service Model

2 Purpose
Service Modeling is the heart of Service Oriented Architecture (SOA). It is needed to: Identify candidate services and capture decisions about which services will actually be exposed Specify the contract between the service provider and the consumer of the services Associate Services with the components needed to realize these services

The Service Model work product provides a single artifact where services can be identified and specified, regardless of the technique

2.1

Impact of Not Having This Work Product

Without this product it would be difficult to properly define services and specify the components needed to realize them. This could lead to gaps in the service portfolio, proliferation of unnecessary services, inconsistencies in how services were exposed, and inconsistencies in the design of components needed to realize the services.

2.2

Reasons for Not Needing This Work Product

This product is not needed if we do not need to externalize service descriptions at the edge of a significant organizational boundary (i.e. at the edge of a major line of business within an enterprise, or at the edge of the enterprise).

3 Notation
The Service Model captures multiple elaborations of services. The first elaboration begins as a list of candidate services in the Service Portfolio created during service Identification activities. As soon as possible services in the list are organized into a hierarchy using a functional classification scheme (typically based on functional areas identified during domain decomposition). As additional information becomes known, the Services Portfolio is extended with additional attributes that show the mapping of services to business functions, goals and assets. Service Specification activities capture additional information. Service exposure decisions, dependencies, composition and state management decisions associated with compositions, and messages. For convenience, certain types of requirements and constraints are also summarized in the Service Model: specific types of non-functional requirements and architectural decisions.

3.1

Service Portfolio

For simplicity the Service Portfolio can initially be represented as a list of candidate services as shown in Figure 2.

Work Product Template

Page 3 of 13

Work Product: Service Model

Figure 2: Service Portfolio - initial service list As the number of candidate services increases, an unstructured list can quickly become unmanageable. Therefore, as soon as possible a service classification scheme should be identified so that candidate services can be organized into groups within the classification hierarchy. The Service Hierarchy organizes services in the service portfolio using a uniform classification scheme. The classification scheme is often based on the functional areas identified by RUP/SOMA Domain Decomposition Functional Area Analysis, and Documented in the Functional Area Descriptions work product. Notation for the Service Hierarchy is an outline format as shown in the example in Figure 3.

Figure 3: Service Portfolio organized using a classification hierarchy

While a simple list of service names can be a quick starting point, it will eventually be important to capture additional information about each service. This information can be subdivided into two types: information that supports service identification, and information that supports service specification. Service identification is focused on building a portfolio of services that can be associated with business functions, business goals, assets such as existing systems, and an indication of whether the service is considered a candidate service, or has been chosen for exposure. The table shown in Table 2: Service Portfolio template is a template that can be used to document services at the level of detail needed in the service portfolio. Service specification information is discussed in the next Notation section.

Work Product Template

Page 4 of 13

Work Product: Service Model

Associations Service Description Status Function/ process Goal Asset

Table 2: Service Portfolio template Service: name of service Description: short description of service Status: C for candidate service, E for a service chosen for exposure. Associations: Function/process: name of business function and/or process that the service is associated with (this typically aligns with Functional Areas and/or Process Definition). Depending on the level of detail reached in analysis activities, this could be a business domain, a functional area, a specific function, a business process, or a process step from some level of process decomposition. More specificity in the reference is generally better. Goal: name of a goal or subgoal that the service is associated with (this typically matches a goal or sub-goal listed in the Goal-Service Model). Asset: an asset that is associated with the realization of the service (this typically matches a system listed in the Business Function / System Matrix) Exception Service Operation Input Msg Output Msg (Fault)

3.2

Service Specifications

3.2.1 Service Exposure Decisions

Not all candidate services meet the criteria needed to be chosen for exposure. Service Exposure decisions can be made by applying the Service Litmus Test described in the Service-Oriented Modeling and Architecture (RUP/SOMA) technique paper. The template shown in Table 3: Service Exposure Decision template can be used to capture service exposure decisions and the rationale for making the decision.
Work Product Template Page 5 of 13

Work Product: Service Model

Service

Expose Business Alignment

Service Litmus Test Results Composeability Externalized Description Redundancy Elimination Comments

Table 3: Service Exposure Decision template Service: name of service Expose: Y for expose, N for dont expose Business Alignment: does the service meet business alignment SLT criteria Composability: does the service meet composeability SLT criteria Externalized Description: does the service meet externalized service description SLT criteria Redundancy Elimination: does the service meet redundancy elimination SLT criteria Comments: cases may arise were a decision is made by the business to expose a service even if it does not pass all SLT tests. Document the reason for overriding the SLT test results.

3.2.2 Service Dependencies, Composition and Flow

The Service Model documents three related aspects of the relationships among services that arise from the larger context that individual services are used in. Since services are used in the context of business processes, the Process Definition work products is an important input to the specification of dependencies, composition and flow. Analysis of how services are used in the context of business processes leads to the identification of how specific combinations of services are used. Service dependencies describe the relationships between services that arise in the larger context of how they will be used. When a service is formed from a composition of other services the composing service depends on the composed services. When services are used in the context of a business process, there is a process related dependency that arises from the inherent sequence of steps in the business process that dictates the order in which services will be used. These two types of dependency scenarios are shown in Figure 4: Functional dependencies (Type 1) that arise from composition of multiple services Temporal dependency (Type 2) where there is some pre- or post- condition or processing requirement that will need to be accounted for in compositions or choreographies.

Work Product Template

Page 6 of 13

Work Product: Service Model

Service Dependency Type 1

Service Dependency Type 2

Functional Dependency/Composite Dependency: Reserve Vehicle will depend on Check rates and Make Reservation for its functionality

Pre-condition dependency i.e. another service invocation must have executed successfully before the current invocation can begin execution. Processing dependency i.e. another service invocation is required to complete the successful execution of the current service. Post-condition dependency (not shown) this appears in cases where a service requires another service invocation after its execution.

Figure 4: Types of Service Dependencies Dependencies should be represented visually with accompanying text that describes the nature of the dependencies. One style for diagramming dependencies is shown in Figure 4. For functional dependencies A UML component relationship diagram can also be used. For processing dependencies a UML sequence diagram can be used.

3.2.3 Service Composition and Flow

Service composition can be used to support short running, non-interruptible, as well as long running interruptible processes. The flow of Service composition can be represented visually using the approach shown in Figure 5: Service Composition, with accompanying text that describes the composition. Each composition should be named so that it can be referred to in the State Management Decisions section. A. Short running, non-interruptible process (micro-flow) B. Long running , interruptible process (macro-flow)

Work Product Template

Page 7 of 13

Work Product: Service Model

A. Short running, non-interruptible process (micro-flow) Reserve Vehicle is composed of: Check Rates Make Reservation

B. Long running , interruptible process (macro-flow) Rent Vehicle is composed of: Reserve Vehicle Check-out Vehicle Check-in Vehicle

Figure 5: Service Composition

3.2.4 Service Non-functional requirements

It is convenient to summarize certain types of nonfunctional requirements in the Service Model to simplify the validation of proposed decisions for how a service will be realized. For example, if an existing business system function is proposed as a way to realize a service, then the availability level of the business system needs to be equal to or better than the availability requirement of the service. This does not eliminate the need to fully document nonfunctional requirements in the ARC 119 Non-functional Requirement work product. The template shown in Error: Reference source not found can be used to summarize these non-functional requirements. Nonfunctional requirements that can be summarized in the Service Model: Service <name of service> Availability (i.e. MTBF, MTTR) Operational window (is there ever a time when the service is not expected to be used?) Response time (how quickly does the service need to respond to a request) Peak throughput (how many requests for the service can arrive per unit of time e.g. per second, per minute, per hour) <other> NFR type <ref. nfr list above> Non-functional Requirement <statement of requirement>

Table 4: Non-functional Requirements template

3.2.5 Service Messages

The Service Model needs to capture only a high level description of the messages associated with a service. Later activities will create a detailed message specification. The following template can be used to provide a high level description of service input and output messages. Message Segment Service Value

Work Product Template

Page 8 of 13

Work Product: Service Model

Topic Input Message Output Message Table 5: Rent-a-car Service Messages template Enterprise message formats must be reconciled with the input/output messages of individual services, so they are related and assigned to allow appropriate services to use and update them as needed. Services may need to extract information from or expect output from the Common Enterprise Message format. These expectations are documented in the template below. Service Common Enterprise Message Format Attribute Description of Interaction with Services Input or Output Messages

Table 6: Service Common Message Format template

3.2.6 Realization Decisions

Two areas of realization decisions are of interest to the Service Model. Decisions need to be made about which services will be allocated to which service components. Certain architectural decisions also need to be made that are directly related to the realization of services. They will be noted and summarized here, but are fully documented in the Architectural Decisions work product. Summarizing these architectural decisions here should be viewed as a convenience for easy reference during service modeling activities, not a replacement for the Architectural Decisions work product.

3.2.6.1 Service Allocation to Components

The Service Model work product captures the mapping between Services and Service Components. The detailed modeling of the realization of a service is documented in the Service Component Model, where the relationships between Service, Functional and Technical components are defined. As decisions are made to allocation services to service components they can be documented in the Service Model work product using the template shown in Figure 6. Service <service name> Service Component <service component name> Comment <comments or special considerations>

Figure 6: Service Allocation template

3.2.6.2 Service Realization related architectural decisions

Certain architectural decisions points pertain to services and the services layer. These decisions are summarized here for ease of reference, and are documented in detail in the Architectural Decisions work product along with other architectural decisions. Decision point Decision Services

Work Product Template

Page 9 of 13

Work Product: Service Model

How service descriptions will be externalized How services are exposed (e.g. Web Services) How messages are formed (i.e., XML, AS2, structured field, proprietary, ) How/where message transformation will be done How security will be enforced at the level of the service interface Service name space issues Division of responsibility between ESB and enterprise components <other service related decision point>

(All or specific list)

Table 7: Realization Decision Summary table wth example decision points Note that more than one alternative might be adopted for certain decision points. In those cases the decision point should be listed once for each adopted alternative, along with a list of services that the alternative will be applied to.

3.2.7 State Management Decisions

Although an individual service is considered stateless, compositions often require that certain information (state) be managed during the time that the elements of the composition are being invoked. State management decisions describe the state related requirements and how the requirement will be met. Composition Name of composition Table 8: State Management Decisions template Composition: name of composition (the composition is described in the Service Composition section) State requirements: state requirements for this composition Decision: where and how state management will be accomplished State requirements Decision

Example

<To be based on the TP example>

5 Development Approach
Work Product Template Page 10 of 13

Work Product: Service Model The Service-Oriented Modeling and Architecture (RUP/SOMA) technique paper describes the approach to creating a Service Model in detail. The approach consists of the following steps. Create a Service Portofolio: the RUP/SOMA method describes identification techniques that can be used to add services to the service portfolio. Organize the Service Portfolio using a classification hierarchy: the service candidates in the Service Portfolio can be categorized by applying a classification scheme that is meaningful to the SOA initiative. Functional areas that were identified during Functional Area Analysis provide a useful business context for developing a classification scheme. Make Service Exposure Decisions: The Service Portfolio initially identifies candidate services that have not been fully evaluated for service exposure. Service exposure decisions will eventually be made, at which time some or all of the services in the Service Portfolio will be chosen for exposure. In order identify those services that need to be exposed a set of criteria in the form of the Service Litmus Test (SLT) can be used. This metaphor is used to denote a set of tests, that when applied, will determine if a given set of services should be eligible for exposure. Identify Service Dependency: detailed review of the service will often expose a set of dependencies between services and between services and the applications they rely on for realization of their functionality. Although, most dependencies might be on other (exposed) services, some may be on components that have not been chosen to be exposed as a service. Identify Service Compositions: choreography or orchestration can be used to create a composition of services. That composition may or may not itself be a service. For example Business Process Execution Language for Web Services (BPEL4WS) can be used to implement the choreography or flow of services. Summarize key non-functional requirements: a service consumer typically has expectations such as how fast a service will perform and its level of availability. A service provider may impose certain requirements on a service consumer such as a security related requirement. It is convenient to summarize requirements of this type in the service model to support validation of various aspects of the model as well as decisions related to how services will be realized. Create Message Specification: services require input and output messages. Messages are identified and specified at a high level in the service model (i.e. this is not a detailed level of specification) Identify state management requirements for compositions: although individual services are considered stateless, compositions often have requirements to maintain state information across the invocation of the composed services. The choreographer of the services is often responsible for the management of state. Alternatively, a component that implements and realizes multiple related services or operations on services may need to maintain state between invocations for performance reasons. State Management in SOA environment can be considered to fall into three main categories: Transaction State, Security State and Functional State.

6 Validation and Verification

7 Advice and Guidance

RUP/SOMA activities are subdivided into three major steps: Identification, Specification and Realization Decisions (Figure 7). These steps which are carried out in an iterative fashion, building up the services portfolio, specifying services chosen for exposure, and making key realization decisions that are required in order to carry out activities that take place later in the solution development life cycle.
Work Product Template Page 11 of 13

Work Product: Service Model

Figure 7: RUP/SOMA Activites overview It is important to understand that while service specification depends on identification to create a service portfolio, realization decisions take place at a number of points concurrent with both identification and specification.

8 References
1. Service-Modeling and Architecture Technique paer 2. Service Litmus Test, Arsanjani, Holley 3. Service Prolfiferation Syndrome, Arsanjani, Holley 4. Business Extensions for UML, OMG . www.omg.org/uml. 5. Krutchen, P., The Rational Unified Process: An Introduction, Addison-Wesley, 1999. 6. Rumbaugh, J., Booch, G., Jacobson, I., The Unified Modeling Language Reference, Addison-Wesley, 1999. 7. IBM Object Technology Center, Developing Object-oriented Software: An Experience-based Approach, Prentice-Hall, 1997, pp. 192-232. 8. Erikson, Hans-Erik; Penker, Magnus; Business Modeling with UML, John Wiley and Sons, 2000, pp. 66-75, pp. 370-371. 9. Marshall, C., Enterprise Modeling, Addison-Wesley, 2000, pp. 7-26. 10. Bory, Deimel, Henn, Koskimies, Pasil, Pomberger, Pree, Stal and Syperski, What characterizes a software component?, Software - Concept and Tools (1998), Vol 19, No.1, pp. 48-56. 11. Workshop on Component-Oriented Programming (WCOP96), ECOOP96 Workshop Reader, Springer-Verlag, 1997, ISBN 3-920993-67-5. 12. Arsanjani, A., Enterprise Component: A Compound Pattern for Building Technology-Neutral Components, proceedings of OOPSLA 2000 Workshop on Business Components, Minneapolis, MN, 2000, to be published by Springer-Verlag, 2001. 13. Arsanjani, A., Rule Object: A Pattern Language for Flexible Modeling and Construction of Business Rules, Washington University Technical Report number: wucs-00-29, Proceedings of the Pattern Languages of Program Design, 2000. 14. Daniels, J., Cheesman, J., UML Components, Addison-Wesley, 2000, pp. 68-73. 15. Jacobson, I., Booch, G., Rumbaugh, J., The Unified Software Development Process, AddisonWesley, 1999, pp.98-106, pp.122-130. 16. Arsanjani, A., Analysis and Design of Distributed Java Business Frameworks using Domain Patterns, Proceedings of TOOLS 99, IEEE Computer Society Press 1999, pp. 490-500.
Work Product Template Page 12 of 13

Work Product: Service Model 17. Meyer, B., Object-oriented Software Construction, Prentice Hall, 1997, pp. 57-61. 18. Arsanjani, A., GOOD: Grammar-oriented Object design, Position Paper for OOPSLA Workshop on Metadata and Active Object Models, 1998, Vancouver, British Columbia. 19. Arsanjani, A., Dynamic Configuration and Collaboration of Components with Self-description, position paper submitted to ECOOP 2001 Workshop on Active Object Models and Meta-modeling, 2001.. 20. Allen, P., Realizing e-business with Components, Addison-Wesley, 2000, pp. 64-71. 21. Arango, G., Domain analysis: from art form to engineering discipline; Proceedings of the fifth international workshop on Software specification and design, 1989, Pages 152 159. 22. McDavid, D., A Standard for Business Architecture Description, IBM Systems Journal. Vol 38, No. 1, 1999. 23. Thibault, S. A. , Marlet, R., and Consel, C., Domain-Specific Languages: From Design to Implementation Application to Video Device Drivers Generation, IEEE Transactions on Software Engineering, vol. 25, pp. 363-377, May 1999. 24. Gamma, E., Helm, R., Johnson, R., Vlissides, J., Design Patterns: Elements of reusable Objectoriented Software, Addison-Wesley, 1994. 25. Fowler, M., Analysis Patterns: Reusable Object Models, Addison-Wesley, 1997. 26. Allen, B., and Holtzman, P., Simplifying the Construction of Domain-Specific Automatic Programming Systems: The NASA Automated Software Development Workstation Project, Proceedings of the Space Operations Automation and Robotics Workshop, (Houston, TX), pp. 407-410, NASA Johnson Space Center, Aug. 1987. 27. Ardis, M., Dudak, P., Dor, L., Leu, W., Nakatani, L., Olsen, and Pontrelli, P.,Domain Engineered Configuration Control, in Proceedings of the First Software Product Line Conference (P. Donohoe, ed.), pp. 479-493, Aug. 2000 28. Batory, D., Coglianese, L., Goodwin, M., and Smith, R. , A Domain Model for Avionics Software, Tech. Rep. ADAGE-UT-92-01, Department of Computer Science, University of Texas, Austin, Texas, Feb 1992. 29. Enterprise Component technique paper, part of the LT Componentization and web services execution model.

9 Estimating Considerations
The duration and the amount of effort required to develop the Domain Decomposition Model will vary depending on: Size of enterprise Complexity of enterprise Scope of engagement Quality and completeness of the input work products Experience of team (in technique and industry)

Where all the necessary input is available, (particularly the activity and information models and the usage matrix), then the development of the function model will require approximately 2 - 7 days effort from the consultant responsible for the work product. In addition, effort will be required from the customers staff and will vary with the factors given above.

Work Product Template

Page 13 of 13