Service-oriented modeling

From Wikipedia, the free encyclopedia

Service-oriented modeling is the discipline of modeling business and systems, for the purpose of designing and specifying service-oriented business systems within a service-oriented architecture.

Contents 1 Overview 2 Popular approaches to service-oriented modeling 2.1 Service-oriented analysis and design (SOMA) 2.2 Service-oriented modeling framework (SOMF) 3 SOA life cycle modeling 3.1 Life cycle modeling activities 4 Methodological issues 4.1 Modeling styles 4.2 Modeling assets 4.3 Modeling notation 4.4 Service-Oriented Conceptualization 5 Examples 6 References 7 Further reading 8 External links

[edit] Overview

Any service-oriented modeling methodology typically includes a modeling language that can be employed by both the 'problem domain organization' (the Business), and 'solution domain organization' (the Information Technology Department), whose unique perspectives typically influence the 'service' development life-cycle strategy and the projects implemented using that strategy.

Service-oriented modeling typically strives to create models that provide a comprehensive view of the analysis, design, and architecture of all 'Software Entities' in an organization, which can be understood by individuals with diverse levels of business and technical understanding. Service-oriented modeling typically encourages viewing software entities as 'assets' (service-oriented assets), and refers to these assets collectively as 'services'.

[edit] Popular approaches to service-oriented modeling

There are many different approaches that have been proposed for service modeling, including SOMA and SOMF.

[edit] Service-oriented analysis and design (SOMA)

IBM announced Service-Oriented Modeling and Architecture (SOMA) as the first publicly announced SOA-related methodology in 2004.^[1] SOMA refers to the more general domain of service modeling necessary to design and create SOA. SOMA covers a broader scope and implements service-oriented analysis and design (SOAD) through the identification, specification and realization of services, components that realize those services (a.k.a. "service components"), and flows that can be used to compose services.

SOMA includes an analysis and design method that extends traditional object-oriented and component-based analysis and design methods to include concerns relevant to and supporting SOA. It consists of three major phases of identification, specification and realization of the three main elements of SOA, namely, services, components that realize those services (aka service components) and flows that can be used to compose services.

SOMA is an end-to-end SOA Method for the identification, specification, realization and implementation of services (including information services), components, flows (processes/composition). SOMA builds on current techniques in areas such as domain analysis, functional areas grouping, variability-oriented analysis (VOA) process modeling, component-based development, object-oriented analysis and design and use case modeling. SOMA introduces new techniques such as goal-service modeling, service model creation and a service litmus test to help determine the granularity of a service.

SOMA identifies services, component boundaries, flows, compositions, and information through complementary techniques which include domain decomposition, goal-service modeling and existing asset analysis.

[edit] Service-oriented modeling framework (SOMF)

The Service-Oriented Modeling Framework (SOMF) has been proposed by author Michael Bell as a service-oriented modeling language for software development that employs disciplines and a universal language to provide tactical and strategic solutions to enterprise problems.^[2]

The service-oriented modeling framework (SOMF) is a service-oriented development life cycle methodology. It offers a number of modeling practices and disciplines that contribute to a successful service-oriented life cycle management and modeling (see image on right).

It illustrates the major elements that identify the “what to do” aspects of a service development scheme. These are the modeling pillars that will enable practitioners to craft an effective project plan and to identify the milestones of a service-oriented initiative—either a small or large-scale business or a technological venture.

The provided image thumb (on the right hand side) depicts the four sections of the modeling framework that identify the general direction and the corresponding units of work that make up a service-oriented modeling strategy: practices, environments, disciplines, and artifacts. Remember, these elements uncover the context of a modeling occupation and do not necessarily describe the process or the sequence of activities needed to fulfil modeling goals. These should be ironed out during the project plan – the service-oriented development life cycle strategy – that typically sets initiative boundaries, timeframe, responsibilities and accountabilities, and achievable project milestones.

[edit] SOA life cycle modeling

Service-oriented modeling is driven by the development process of services. This approach enables business and information technology professionals to focus on deliverables that correspond to a specific service-oriented life cycle stage and event.

[edit] Life cycle modeling activities

Service-oriented Modeling and Architecture (SOMA) consists of the phases of identification, specification, realization, implementation, deployment and management in which the fundamental building blocks of SOA are identified then refined and implemented in each phase. The fundamental building blocks of SOA consists of services, components, flows and related to them, information, policy and contracts.

The service-oriented modeling framework (SOMF) introduces five major life cycle modeling activities that drive a service evolution during design-time and run-time. At the design-time phase a service originates as a conceptual entity (conceptual service), later it transforms into an SOA unit of analysis (analysis service), next it transitions into a contractual and logical entity (design service), and finally is established as a concrete service (solution service). The following identify the major contributions of the service-oriented modeling activities:

• Service-oriented discovery & analysis modeling: Discover and analyze services for granularity, reusability, interoperability, loose-coupling, and identify consolidation opportunities.
• Service-oriented business integration modeling: Identify service integration and alignment opportunities with business domains' processes (organizations, products, geographical locations)
• Service-oriented logical design modeling: Establish service relationships and message exchange paths. Address service visibility. Craft service logical compositions. Model service transactions
• Service-oriented conceptual architecture modeling: Establish an SOA architectural direction. Depict an SOA technological environment. Craft an SOA technological stack. Identify business ownership.
• Service-oriented logical architecture modeling: Integrate SOA software assets. Establish SOA logical environment dependencies. Foster service reuse, loose coupling and consolidation.

[edit] Methodological issues

[edit] Modeling styles

How can an SOA practitioner model a computing environment? In what type of forms can a group of services be arranged to enable an efficient integrated computing landscape? What would be the best message routes between a service consumer and provider? How can interoperability hurdles be mitigated?

SOMF provides four major SOA modeling styles that are useful throughout a service life cycle (conceptualization, discovery and analysis, business integration, logical design, conceptual and logical architecture). These modeling styles: Circular, Hierarchical, Network, and Star, can assist an SOA modeler with the following modeling aspects:

• Identify service relationships: contextual and technological affiliations
• Establish message routes between consumers and services
• Provide efficient service orchestration and choreography methods
• Create powerful service transaction and behavioral patterns
• Offer valuable service packaging solutions

In the illustration on the right you will find the major four service-oriented modeling styles that SOMF offers. Each pattern identifies the various approaches and strategies that one should consider employing when modeling an SOA environment.

• Circular Modeling Style: enables message exchange in a circular fashion, rather than employing a controller to carry out the distribution of messages. The Circular Style also offers a conceptual method to affiliating services.
• Hierarchical Modeling Style: offers a relationship pattern between services for the purpose of establishing transactions and message exchange routes between consumers and services. The Hierarchical pattern founds parent/child associations between services.
• Network Modeling Style: this pattern establishes “many to many” relationship between services, their peer services, and consumers. The Network pattern accentuates on distributed environments and interoperable computing networks.
• Star Modeling Style: the Star pattern advocates arranging services in a star formation, in which the central service passes messages to its extending arms. The Star modeling style is often used in “multi casting” or “publish and subscribe” instances, where “solicitation” or “fire and forget” message styles are involved.

[edit] Modeling assets

The service-oriented modeling framework (SOMF) introduces three major service formations. These structures are software entities that habitually exist in our computing environments:

Atomic Service

Composite Service

Service Cluster

• Atomic service: an indivisible software component that is too granular and executes fewer business or technical functionalities. An atomic formation is also a piece of software that typically is not subject to decomposition analysis activities and its business or technological functionality does not justify breakdown to smaller components. Examples: customer address service and checking account balance service.

• Composite service: a composite service structure aggregates smaller and fine-grained services. This hierarchical service formation is characteristically known as coarse-grained entity that encompasses more business or technical processes. A composite service may aggregate atomic or other composite services. Examples: customer checking service that aggregates smaller checking account and savings account services. An application that is composed of sub-systems, an ESB that is composed of routing, orchestration, and data transformation components.

• Service cluster: this is a collection of distributed and related services that are gathered because of their mutual business or technological commonalities. A service cluster both affiliates services and combines their offerings to solve a business problem. A cluster structure can aggregate atomic as well as composite formations. Examples: A Mutual Funds service cluster that is composed of related and distributed mutual funds services. A Customer Support service cluster that offers automated bill payments, online account statements, and money transfer capabilities

The SOMF also introduces a simple notation to describe the three major service formations, as illustrated in the below image: Atomic Service, Composite Service, and Service Cluster.

[edit] Modeling notation

The service-oriented discovery and analysis notation represents eight simple icons, each of which enables us to operate on a service (atomic or composite service) or on a group of services (service clusters) in different ways.

These operations promote core SOA best practices. Let us take a look at the below illustration to find out what these analysis operations mean and how they can be employed to draft an SOA analysis proposition diagram.

Here is a short description for these symbols^[3]:

• Aggregated: signifies service containment
• Subtracted: identifies service retirement or elimination
• Unified: indicates service consolidation
• Decomposed: depicts service decoupling
• Intersected: illustrates a junction point between two or more service groups (known as service clusters)
• Overlapped: describes common functionality and processes that services provide (typically between service clusters)
• Transformed: represents transformation of a service type to another (atomic to composite, etc)
• Comment: a place to put notes

[edit] Service-Oriented Conceptualization

The service-oriented modeling framework (SOMF) advocates that practitioners devise conceptual services to bridge the communication gaps in an organization. These conceptual entities foster the creation of a common language, a vocabulary that can be used during projects to encourage asset reuse and consolidation. One of the most important aspects of the conceptual service paradigm is that it provides direction and defines the scope of a project or a business initiative.

The conceptualization process then identifies six major “tools” that can facilitate the development of conceptual services.^[4]

• Concept Attribution: this activity pertains to the collection of software products attributes that both describe service’s features and lead to the discovery of organizational taxonomy
• Concept Classification: the categorization effort contributes to separation of concerns and the establishment of service identities. This is the process of identifying service dissimilarities
• Concept Association: Unlike the classification activity, the association effort enables the discovery of service relationship. These can be business or technological affiliations
• Concept Clustering: this discipline is about grouping related conceptual services that collaboratively provide a solution. Clustering is a conceptual operation that can encompass local, remote, and virtual services
• Concept Generalization: to raise the abstraction level of a conceptual service, the generalization method increases the conceptual scope of a solution. This approach is typically used when a service is coarse-grained (too granular)
• Concept Specification: the specification activity enables architects, modelers, and developers to reduce the abstraction level of a service and thus reduce its granularity scope to finer-grained.

[edit] Examples

Let us now view a number of SOA analysis modeling examples.

Click on small images for full-size version

1. Service Aggregation Example

2. Service Decomposition Example

3. Service Subtraction Example

4. Service Substitution Example

• Use Case 1 depicts a simple aggregation case, in which atomic service A-1 is aggregated in composite service C-1 because of SOA best practice reasons.
• Use Case 2 describes service decomposition. Once again, this is because of an SOA best practice rule.
• Use Case 3 illustrates a service retirement (elimination) employing the “subtracted” analysis operation.
• Use Case 4 represents a common business substitution operation. Atomic service A-3 was retired and replaced with atomic service A-2.

[edit] References

This article needs additional citations for verification. Please help improve this article by adding reliable references. Unsourced material may be challenged and removed. (February 2009)

[edit] Further reading

• Ali Arsanjani (2004). "Service-Oriented Modeling & Architecture". IBM Online article, 09 Nov 2004.
• Ali Arsanjani et al. (2008). "SOMA: A method for developing service-oriented solutions ". IBM systems Journal Oct 2008
• Jim Amsden (2006). "UML Profile and Metamodel for Services RFP". OMG Paper
• Michael Bell (2008). Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley.
• Birol Berkem (2008). "From The Business Motivation Model (BMM) To Service Oriented Architecture (SOA)" In: Journal of Object Technology Vol 7, no. 8
• Brian Blake (2007). "Decomposing Composition: Service-Oriented Software Engineers". In: IEEE Software. Nov/Dec 2007. pp.68–77.
• Dick A. Quartel , Maarten W. Steen , Stanislav Pokraev , Marten J. Sinderen, COSMO: A conceptual framework for service modelling and refinement, Information Systems Frontiers, v.9 n.2-3, p.225-244, July 2007

[edit] External links

Wikimedia Commons has media related to: Service-oriented modeling

• "SOMF Examples" (Softcopy). Methodologies Corporation. http://www.modelingconcepts.com/pdf/SOMF_ANALYSIS_MODELING.pdf. 
• "SOMF Examples & Language Notation" (Softcopy). Methodologies Corporation. http://www.modelingconcepts.com/pages/download.htm.