Successfully reported this slideshow.
SOA Architectural Patterns         Dr Matjaz B. Juric          Java Champion       SOA Competence Centre       University ...
Content SOA Anti Patterns SOA Patterns SOMA
SOA Patterns The objective of SOA patterns is to enable loosely-coupled standards-based architecture   Patterns assure fle...
Key Principles for Service Dev. Service boundaries are explicit Services are autonomous Services share schemas and interfa...
Typical SOA Architecture   Message/                   End-points              Process   document                        Me...
Antipattern: Point-to-Point How do services connect? How do processes and services connect? Point-to-point connections:   ...
Antipattern: Shiny Nickel Too much focus on SOA products Introduction of newest “buzz-words”, without clear focus of their...
Antipattern: Hair Split Breaking the architecture into two parts:   Processes,   Services. How to implement new functional...
Typical SOA Architecture   Message/                   Endpoints              Process   document                        Msg...
Antipattern: Architectural      Stovepipe  IT architect tries to define the overall  architecture in advance.    Architect...
Antipattern: Nobody Home Aka “B2IT” and “Peoples Republic IT” Business services are developed under the assumption that IT...
Antipattern: Too many Cooks Developing more than one service with similar functionality Developers do not check whether si...
Antipattern: A Million Services Very many services are developed   “Everything should become a service.” All services are ...
Antipattern: Über Service Development of very few services with large number of operations Developers add new operations i...
Antipattern: Chatty Interface Services require several operation calls to fulfil a request Potential danger to develop sta...
Antipattern: Loosey-Goosey Service interface receives or returns specific XML (according to XSD) We add extensibility as: ...
Antipattern: CRUDy Interface We develop services with the following operations: Create, Read, Update, Delete Using such in...
SOA Patterns                  Composite                   Patterns      Process                  Integration      Patterns...
SOA Patterns                  Composite                   Patterns      Process                  Integration      Patterns...
Pattern: Agnostic Context How to develop a service, which is useful in different contexts How to position service as a use...
Pattern: Service Decomposition How to change service granularity once it has been implemented and deployed Make a coarse-g...
Pattern: Service Normalization Prevent and remove redundant business logic in services Functional overlapping should be ad...
Pattern: Logic Centralization How to prevent misuse of redundant business logic in services Solution: agnostic reusable se...
Contract Denormalization How to add operations to a service interface with partially overlapping functionalities   Without...
Pattern: Concurrent Contracts How to satisfy the requirements of different clients while keeping the appropriate level of ...
Pattern: Canonical Schema How to develop services that will not require schema transformations   Increased interoperabilit...
Pattern: Type Decoupling Types in the interface and the implementation should not be the same:   Internal implementation  ...
Pattern: Security Centralization How to abstract security-related logic How to centralize logic How to maintain it central...
SOA Patterns                  Composite                   Patterns      Process                  Integration      Patterns...
Pattern: Enterprise Inventory Defines approach for service registry and repository establishment and use Assures:   Unifie...
Pattern: Domain Inventory Defines approach to divide the organization into domains and development of services within doma...
Pattern: Service Layers Defies how to organize services within registry/repository into logical groups Defines how to crea...
SOA Patterns                  Composite                   Patterns      Process                  Integration      Patterns...
Process Patterns Electronic Commerce   Web-up, Enterprise-out, … e-Marketplace   General e-Marketplace, Sell-Side Hub, … A...
IBM SOMA SOMA (Service-Oriented Modelling and Architecture) Methodology Focused on service design Related to RUP   Rationa...
IBM SOMA
Conclusion SOA patterns can help to design and develop better SOA architectures and applications SOA antipatterns demonstr...
HVALA ZA POZORNOST!     e-naslov: http://www.cloud.si      e-naslov: http://www.soa.si        e-pošta: info@cloud.si      ...
Upcoming SlideShare
Loading in …5
×

SOA architecture patterns, Matjaž Jurič (FRI/Univerza v Ljubljani)

2,049 views

Published on

Published in: Technology, Business
  • Be the first to comment

SOA architecture patterns, Matjaž Jurič (FRI/Univerza v Ljubljani)

  1. 1. SOA Architectural Patterns Dr Matjaz B. Juric Java Champion SOA Competence Centre University of Ljubljana, FRI www.soa.si www.cloud.si
  2. 2. Content SOA Anti Patterns SOA Patterns SOMA
  3. 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. 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. 5. Typical SOA Architecture Message/ End-points Process document Message Transfor mation Service BRMS implementation
  6. 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. 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. 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. 9. Typical SOA Architecture Message/ Endpoints Process document Msg XSLT Service BRMS Impl.
  10. 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. 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. 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. 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. 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. 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. 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. 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. 18. SOA Patterns Composite Patterns Process Integration Patterns Patterns Service ESB Patterns Patterns Governance Business Rules Patterns Patterns
  19. 19. SOA Patterns Composite Patterns Process Integration Patterns Patterns Service ESB Patterns Patterns Governance Business Rules Patterns Patterns
  20. 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. 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. 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. 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. 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. 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. 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. 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. 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. 29. SOA Patterns Composite Patterns Process Integration Patterns Patterns Service ESB Patterns Patterns Governance Business Rules Patterns Patterns
  30. 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. 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. 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. 33. SOA Patterns Composite Patterns Process Integration Patterns Patterns Service ESB Patterns Patterns Governance Business Rules Patterns Patterns
  34. 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. 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. 36. IBM SOMA
  37. 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. 38. HVALA ZA POZORNOST! e-naslov: http://www.cloud.si e-naslov: http://www.soa.si e-pošta: info@cloud.si 38

×