1. SOA Architectural Patterns
Dr Matjaz B. Juric
Java Champion
SOA Competence Centre
University of Ljubljana, FRI
www.soa.si
www.cloud.si

2. Content
SOA Anti Patterns
SOA Patterns
SOMA

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

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

5. Typical SOA Architecture
Message/ End-points
Process
document
Message
Transfor
mation Service
BRMS
implementation

6. 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)

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

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

9. Typical SOA Architecture
Message/ Endpoints
Process
document
Msg
XSLT
Service
BRMS
Impl.

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

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

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

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

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

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

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

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

18. SOA Patterns
Composite
Patterns
Process Integration
Patterns Patterns
Service ESB
Patterns Patterns
Governance Business Rules
Patterns Patterns

19. SOA Patterns
Composite
Patterns
Process Integration
Patterns Patterns
Service ESB
Patterns Patterns
Governance Business Rules
Patterns Patterns

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

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

22. 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?

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

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

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

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

27. 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)

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

29. SOA Patterns
Composite
Patterns
Process Integration
Patterns Patterns
Service ESB
Patterns Patterns
Governance Business Rules
Patterns Patterns

30. 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
…

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

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

33. SOA Patterns
Composite
Patterns
Process Integration
Patterns Patterns
Service ESB
Patterns Patterns
Governance Business Rules
Patterns Patterns

34. 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.
…

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

36. IBM SOMA

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

38. HVALA ZA POZORNOST!
e-naslov: http://www.cloud.si
e-naslov: http://www.soa.si
e-pošta: info@cloud.si
38