Service-Oriented Computing
Patron= consumer
Patron= consumer Kitchen Staff =
producer Kitchen Staff =
producer Waiter = message
broker + deliverer Waiter = message broker + deliverer
Menu = list of services Menu = list of services
Restaurant = enterprise
2) Request food3) Receives request
4) Prepares food 6) Receives food 5) Sends food
1) Selects food from menu
Service Design
How the 3 core components (services, descriptions, and messages) are designed ? “service-orientation”
Service-orientation is a distinct design much like OO. Commonly accepted governance design principles:
– Loose coupling: relationship that minimizes dependencies – Service Contract: adhere to communications agreement – Autonomy: control over the logic they encapsulate
– Abstraction: only see service contract, rest is hidden – Reusability: logic divided into services to promote reuse – Composability: able to form composite services
Primitive SOA
Web services is technology that help most to the advancement of SOA
Previous charts described ingredients for primitive SOA
Baseline technology architecture supported by current major vendor platforms
Follow-on discussion are based on and extend this primitive model Some of the extensions are attainable through advanced design
techniques and some are pre-defined and supported by vendors
Contemporary SOA
Real world look of SOA shaped by:
– Industry trends and developments
– Vendor new XML and web services specifications – Technology advancements
Characteristics of Contemporary SOA
Is at the core of the service-oriented computing platform
Increases QoS
Fundamentally autonomous
Based on open standards
Supports vendor diversity
Fosters intrinsic interoperability
Promotes discovery
Promotes federation
Promotes architectural composability
Fosters reusability
Emphasizes extensibility
Supports S-O business modelling paradigm
Implements layers of abstraction
Promotes loose coupling
Promotes organization agility
Is a building block
Is an evolution
Is still maturing
At the core of the S O C platform
“SOA” has become a multi-purpose buzzword when discussing an application computing platform consisting of Web services technology and service orientation principles
When a product, design, or technology is prefixed with “SOA” it is something that was created in support of an architecture based on service-orientation principles
Increase QoS
Need SOA to be ready for enterprise-level functionality such that tasks are carried out:
In a secure manner (contents and access)
Reliably (i.e. message guaranteed delivery)
With appropriate performance
Protecting business integrity
With exception logic in case of failure
Fundamentally Autonomous
Individual services need to be as independent and self-contained as possible with respect to the control they maintain over their underlying logic
Message-level autonomy
Concept is expanded to solution environments and the enterprise i.e. applications
Figure : Standard open technologies are used within and outside of solution boundaries.
Figure : Disparate technology platforms do not prevent service-oriented
Figure : Registries enable a mechanism for the discovery of services.
Promotes discovery
Figure : Services enable standardized federation of disparate legacy systems.
Figure : Inherent reuse accommodates unforeseen reuse opportunities.
Figure : A collection (layer) of services encapsulating business process logic.
Figure : Through the implementation of service layers that abstract business and application logic, the loose coupling
Figure 3.16: A loosely coupled relationship between business and application
Common misperceptions about SOA
“An application that uses Web services is service-oriented”
“SOA is just a marketing term used to re-brand Web services
“SOA is just a marketing term used to re-brand distributed computing with Web services”
“SOA simplifies distributed computing”
“An application with Web services that uses WS-* extensions is service-oriented”
“If you understand Web services you won’t have a problem building SOA”
Common tangible benefits of SOA
Improved integration (and intrinsic interoperability)
Inherent reuse
Streamlined architectures and solutions
Leveraging the legacy investment
Establishing standardized XML data representation
Focused investment on communications infrastructure
Common pitfalls of adopting SOA
Building service-oriented architectures like traditional distributed architectures
Not standardizing SOA
Not creating a transition plan
Not starting with an XML foundation architecture
Not understanding SOA performance requirements
Not understanding Web services security
