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: [email protected]
Top Related