Service-oriented modeling

From Wikipedia, the free encyclopedia

It has been suggested that this article or section be merged into Service-oriented analysis and design. (Discuss)

This article or section includes a list of references or external links, but its sources remain unclear because it lacks in-text citations.
You can improve this article by introducing more precise citations.

Service-oriented modeling is a software development practice that employs disciplines and a universal language to provide tactical and strategic solutions to enterprise problems. Service-oriented modeling takes an anthropomorphic view to the modeling process by striving to create models that can be understood by individuals with diverse levels of business and technical understanding. The service-oriented modeling paradigm advocates taking a holistic view of the analysis, design, and architecture of all 'Software Entities' in an Organization. Service-oriented modeling encourages viewing software entities as 'assets' (service-oriented assets), and refers to these assets collectively as 'services'.

The service-oriented modeling methodology 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.

The service-oriented modeling paradigm is based upon the following vision:

Introduce a state-of-the-art and holistic modeling language that can facilitate an SOA implementation
Introduce advanced service life cycle concepts and processes that can be employed to manage service-oriented projects
Enable business and IT personnel to equally partner in service-oriented modeling efforts and to represent their unique perspectives

The service-oriented modeling practice employs the following disciplines that are widely utilized during service-oriented development life cycle:

Service-oriented conceptualization
Service-oriented discovery and analysis
Service-oriented business integration
Service-oriented design
Service-oriented conceptual architecture
Service-oriented logical architecture

1 Service-oriented modeling framework (SOMF)
2 SOA life cycle modeling: an SOA governance life cycle approach
3 Service-oriented life cycle modeling activities
4 Service-oriented modeling styles
5 Service-oriented modeling assets
6 Service-oriented discovery & analysis modeling notation
7 Why Service-oriented discovery & analysis modeling?
8 Service-oriented discovery & analysis modeling examples
9 References

[edit] Service-oriented modeling framework (SOMF)

Service-oriented modeling framework (SOMF) Version 1.1

The service-oriented modeling framework (SOMF) that was devised by Michael Bell 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 fulfill 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: an SOA governance life cycle approach

Unlike any other modeling practice, the service-oriented modeling framework (SOMF) 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. For example, among the five modeling disciplines that are advocated by SOMF, the service-oriented discovery and analysis modeling process offers a language that fosters SOA best practices. Consider the following five modeling disciplines that are offered by SOMF:

Service-oriented discovery & analysis modeling
Service-oriented business integration modeling
Service-oriented logical design modeling
Service-oriented conceptual architecture modeling
Service-oriented logical architecture modeling

[edit] Service-oriented life cycle modeling activities

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] Service-oriented 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 below illustration 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 Stare 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] Service-oriented modeling assets

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

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] Service-oriented discovery & analysis 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:

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] Why Service-oriented discovery & analysis modeling?

The SOMF model recommends that business and IT people share the responsibility of SOA modeling activities. This modeling language is simple enough that can be understood by all stakeholders in an SOA initiative.

Why are we required to “record” the service analysis activities? The service-oriented discovery and analysis phase is not only about the final state of a service structure and functionality; it is also about business and technological traceability. Meaning, we are mandated to answer the following questions when delivering an analysis proposition diagram:

Financial traceability: How much it would cost (or what was the price) to transform a service from one state to another?
Historical traceability: Capture the date/time when a software transformation occurred (historical reasons)
SOA best-practices traceability: What were the architecture best practices that led to analysis decisions?
SOA analysis process tracking: What are/were the various options and reasons for future/past implementation
Componentization of Software Assets: Service decomposition and segmentation
And much more…

In other words, the analysis proposition diagram explains simple or complex transformation of software entities (services) that provide solutions, such as Substitution of services, Retirement of services, service Exchange, service Augmentation and other business patterns that can be illustrated by this process.

SOMF Examples (Softcopy). Methodologies Corporation.

SOMF Examples & Language Notation (Softcopy). Methodologies Corporation.

[edit] Service-oriented discovery & analysis modeling examples

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

1. 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.

2. Use Case 2 describes service decomposition. Once again, this is because of an SOA best practice rule.

3. Use Case 3 illustrates a service retirement (elimination) employing the “subtracted” analysis operation.

4. Use Case 4 represents a common business substitution operation. Atomic service A-3 was retired and replaced with atomic service A-2.

5. Use Case 5 describes an analysis process, in which atomic services A-1 and A-2 exchange their aggregating composite services because of an adjustment to their contextual affiliation.