SOA Architectural Patterns

Dr Matjaz B. Juric

Java Champion

SOA Competence Centre

University of Ljubljana, FRI

www.soa.si

www.cloud.si

Content

SOA Anti Patterns

SOA Patterns

SOMA

SOA Patterns

The objective of SOA patterns is to enable loosely-coupled standards-based architecture

Patterns assure flexibility, extendibility, and changeability of applications.

Anti-patterns show bad practices, tight-coupling and other non-advisable techniques.

Key Principles for Service Dev.

Service boundaries are explicit

Services are autonomous

Services share schemas and interfaces, not classes

Compatibility of services is determined upon policies

Typical SOA Architecture

Service

implementation

End-points

Message

Transfor

mation

Process

BRMS

Message/

document

Antipattern: Point-to-Point

How do services connect?

How do processes and services connect?

Point-to-point connections:

Possible in SOA

Bad approach!

Solution:

ESB

Registry and repository (UDDI)

Antipattern: Shiny Nickel

Too much focus on SOA products

Introduction of newest “buzz-words”, without clear focus of their purpose

Focus on products, instead of architecture

Solution: design of the overall “Enterprise Architecture” and the definition of the SOA roadmap

Antipattern: Hair Split

Breaking the architecture into two parts:

Processes,

Services.

How to implement new functionalities?

Services or processes?

Often the answer is not obvious at first sight.

Solution: Focus has to be on business services, not on implementation technologies

Typical SOA Architecture

Service

Impl.

Endpoints

Msg

XSLT

Process

BRMS

Message/

document

Antipattern: Architectural Stovepipe

IT architect tries to define the overall architecture in advance.

Architecture should answer all today’s and feature requirements

Too much time is invested into architecture

Projects cannot wait and bypass it

Solution: IT architect makes the high-level architectural design in a rational amount of time.

Antipattern: Nobody Home

Aka “B2IT” and “Peoples Republic IT”

Business services are developed under the assumption that IT understands business needs, required services and expected results.

Such services usually do not fulfil business requirements.

Solution: IT/business alignment using request/process modelling

Antipattern: Too many Cooks

Developing more than one service with similar functionality

Developers do not check whether similar services already exist

System entropy is increasing, reuse is endangered

Solution: well defined development process, registry/repository, well defined SOA governance

Antipattern: A Million Services

Very many services are developed

“Everything should become a service.”

All services are on the same tier, there is no well-defined architecture, no registry

Consequence: nobody is familiar with the services

Solution: Categorization of services, distinction between business and technology services, classification, well-defined procedure for service identification

Antipattern: Über Service

Development of very few services with large number of operations

Developers add new operations into services without control and without good consideration

Solution: sound design on overall architecture and services, identification of services and their operations

Antipattern: Chatty Interface

Services require several operation calls to fulfil a request

Potential danger to develop state-full services

Behaviour of an operation depends on the result of the previous operation

State-full services are problematic:

Type put coordination logic into the client

They are less scalable

Antipattern: Loosey-Goosey

Service interface receives or returns specific XML (according to XSD)

We add extensibility as:

<ext name=“name”>value</ext>

Or as XML Any element

This results in implicit service behaviour

Implicit service behaviour leads to fragile architecture

Antipattern: CRUDy Interface

We develop services with the following operations: Create, Read, Update, Delete

Using such interface we have developed an SQL gateway to the database

Such services break the loosely-coupled concept

Applications become directly related to the database schema

SOA Patterns

Process

Patterns

Integration

Patterns

Composite

Patterns

Service

Patterns ESB

Patterns

Governance

Patterns Business Rules

Patterns

SOA Patterns

Process

Patterns

Integration

Patterns

Composite

Patterns

Service

Patterns ESB

Patterns

Governance

Patterns Business Rules

Patterns

Pattern: Agnostic Context

How to develop a service, which is useful in different contexts

How to position service as a useful resource in the organisation

Combining agnostic and non-agnostic logic within a single service reduces reusability

Solution: partitioning between services

Pattern: Service Decomposition

How to change service granularity once it has been implemented and deployed

Make a coarse-grained service more fine-grained

Make a fine-grained service more coarse-grained

Pattern: Service Normalization

Prevent and remove redundant business logic in services

Functional overlapping should be addressed in the architectural design phase

Solution: collective modelling of service interfaces before their implementation

Challenge: how to remove redundancy in already deployed services?

Pattern: Logic Centralization

How to prevent misuse of redundant business logic in services

Solution: agnostic reusable services are positioned as primary contact endpoints for specific business logic

Contract Denormalization

How to add operations to a service interface with partially overlapping functionalities

Without negative impact on the service

We expose functionalities on different levels of granularity

We increase flexibility

We provide support for different types of clients.

Pattern: Concurrent Contracts

How to satisfy the requirements of different clients while keeping the appropriate level of abstraction

Pattern shows how to define multiple interfaces for the same service implementation

Each interface can evolve independently through time

Pattern: Canonical Schema

How to develop services that will not require schema transformations

Increased interoperability

Solutions:

Use of standard approaches for schema design

Use of common schemas through various services

Pattern: Type Decoupling

Types in the interface and the implementation should not be the same:

Internal implementation

Interface = outside view

Interface types should not be identical to internal implementation types

Internal type can change

If used in the interface, we will break the contract (interface)

Pattern: Security Centralization

How to abstract security-related logic

How to centralize logic

How to maintain it centrally

Solution: common centralized framework for security

Use of vendor tools

Process

Patterns

Integration

Patterns

Composite

Patterns

Service

Patterns ESB

Patterns

Governance

Patterns Business Rules

Patterns

SOA Patterns

Pattern: Enterprise Inventory

Defines approach for service registry and repository establishment and use

Assures:

Unified list of available services

Reuse

Service lifecycle management

Service governance (compliance to standards)

Service ownership

…

Pattern: Domain Inventory

Defines approach to divide the organization into domains and development of services within domains

Domain repository is usually aligned with the business domain

Domain services are based on common/shared design and governance principles

Pattern: Service Layers

Defies how to organize services within registry/repository into logical groups

Defines how to create logical groups

How to add clasifications to the gropus

How to search within the groups in an efficient manner

Process

Patterns

Integration

Patterns

Composite

Patterns

Service

Patterns ESB

Patterns

Governance

Patterns Business Rules

Patterns

SOA Patterns

Process Patterns

Electronic Commerce

Web-up, Enterprise-out, …

e-Marketplace

General e-Marketplace, Sell-Side Hub, …

Account Access

Domain specific reference models:

eTOM (NGOSS/TMF) for telcos

DAIS/OPC Unified Architecture for power dist.

…

IBM SOMA

SOMA (Service-Oriented Modelling and Architecture) Methodology

Focused on service design

Related to RUP

Rational Unified Process

Supported by Rational tools

IBM Rational Method Composer

IBM SOMA

Conclusion

SOA patterns can help to design and develop better SOA architectures and applications

SOA antipatterns demonstrate approaches which are common but not advisable

Designing sound SOA requires a lot of knowledge and skills and is not easy

More SOA patters are available and should be studied and applied carefully

HVALA ZA POZORNOST!

38

e-naslov: http://www.cloud.si

e-naslov: http://www.soa.si

e-pošta: info@cloud.si