SOA An Introduction to Service Oriented Architecture
•Download as PPT, PDF•
1 like•1,228 views
The document provides an introduction to service oriented architecture (SOA). It defines SOA as an architectural style for building distributed systems using loosely coupled services that interact through messages. The key aspects of SOA discussed are that services should be autonomous, coarse-grained, and message-based with run-time configuration. Common SOA patterns and anti-patterns are also mentioned.
Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to SOA An Introduction to Service Oriented Architecture
Similar to SOA An Introduction to Service Oriented Architecture (20)
More from Arnon Rotem-Gal-Oz
Recently uploaded
Recently uploaded (20)
SOA An Introduction to Service Oriented Architecture
- 1. Service Oriented Architecture An Introduction Arnon Rotem-Gal-Oz Biometrics Line Development Manager
- 2. What is Software Architecture
- 8. How Architecture Architecture Quality Attributes Technology Patterns & Anti-patterns Principles Community experience Stakeholders Architect Constraints people A “deliverable” Produce Key Is an input
- 13. Big SOA Analyze the business ASB BLT HDL AFT TGI FRY DRW SWG QYD DLY BST WIU ASB ZIS XOI CUI RMO DLY XPS KYF KFC WHR JIA GEX FQA VUH HCO WKD ECP SKD MFP WCP DKE AJT
- 14. Big SOA Identify Business Areas ASB BLT HDL AFT TGI FRY DRW SWG QYD DLY BST WIU ASB ZIS XOI CUI RMO DLY XPS KYF KFC WHR JIA GEX FQA VUH HCO WKD ECP SKD MFP WCP DKE AJT COP Navigation Protectors Alerts
- 15. Big SOA Map to software "Network" COP Nav. Alerts Prot.
- 17. Service describes End Point Exposes Messages Sends/Receives Contracts Binds to Service Consumer implements Policy governed by Sends/Receives Adheres to Component Relation Key Understands Serves
- 19. A Service edge is a natural boundary Warning: Remoting and other RPCs trick us into thinking that there is no substantial difference between a local and a remote object. In fact, they hide the presence of the network.
- 22. X
- 24. The fact that I can, doesn’t mean I will. Policies
- 26. Endpoint
- 27. It’s all about the Message, baby!
- 28. Messages travel in no man’s land!
- 29. Is he Idempotent? Messages Get Retransmitted Messages Arrive More than once
- 34. Service Contract
- 35. Keep Data and state private
Editor's Notes
- 2003 PSS Global Summit
- 2003 PSS Global Summit
- 2003 PSS Global Summit Emphasize that the rationale for the architectural decisions is very important.
- 2003 PSS Global Summit Software architecture is the collection of the fundamental decisions about a software product/solution designed to meet the project's quality attributes (i.e. requirements). The architecture includes the main components, their main attributes, and their collaboration (i.e. interactions and behavior) to meet the quality attributes. Architecture can and usually should be expressed in several levels of abstraction (depending on the project's size). If an architecture is to be intentional (rather than accidental), it should be communicated. Architecture is communicated from multiple viewpoints to cater the needs of the different stakeholders. Every system has an architecture, even if it is not formally “spec’ed out”.
- A Solution to world hunger Not a solution for everything Just another tool in the toolset A specific Technology Most notably SOA Web Services Will Not make all code reusable A New name for EAI Though well established contracts can help that too A New way to do RPC 2003 PSS Global Summit
- 2003 PSS Global Summit
- 2003 PSS Global Summit
- Business Alignment Can’t stress that enough Reduced assumptions (loose coupling) Builds on ideas from component software, distributed objects, and MOM BPM … All the stuff enterprise architects do 2003 PSS Global Summit
- A service is a program you interact with via message exchanges Services are built to last Encompass a business perspective Stability and robustness are critical A system is a set of deployed services cooperating in a given task Systems are built to change Adapt to new services after deployment 2003 PSS Global Summit
- Each Service interaction is a boundary crossing Don’t cross it with transactions / exceptions etc. Crossing service boundaries may have costs Service Orientation helps makes interaction formal, intentional, and explicit Service boundary is a trust boundary ! Respect my Boundaries (Adopted from Alex Weinert, Clemens Vasters) 2003 PSS Global Summit
- Autonomous services can mean many things. One explanation I’ve heard was the autonomous means that the teams working on different teams can be autonomous. While, this is a nice “feature” to have, a much more valuable (as in “business value”) definition is that the services are as self sufficient as possible. For example a imagine a journal subscription agency which needs to create a proposal for a client. The proposal service needs among other things, to produce a “pro forma” invoice in order to do that it must get the customer’s discount rate and the customer’s discount rate as well as the publisher’s discount rates (to check if the proposal is profitable) see the flow in figure 2.X below . If the proposal service is not autonomous it has to wait for two other services and while the customer service is local the publisher’s discount might be a remote one (on the publisher’s system) – what happens to our proposal service if the publisher’s system is not on-line? 2003 PSS Global Summit
- Service compatibility is determined based on policy Object-oriented designs often confuse structural compatibility with semantic compatibility. Service-orientation deals with these two axes separately. Structural compatibility is based on contract and schema and can be validated (if not enforced) by machine-based techniques (such as packet-sniffing, validating firewalls). Semantic compatibility is based on explicit statements of capabilities and requirements in the form of policy. Every service advertises its capabilities and requirements in the form of a machine-readable policy expression. Policy expressions indicate which conditions and guarantees (called assertions) must hold true to enable the normal operation of the service. Policy assertions are identified by a stable and globally unique name whose meaning is consistent in time and space no matter which service the assertion is applied to. Policy assertions may also have parameters that qualify the exact interpretation of the assertion. Individual policy assertions are opaque to the system at large, which enables implementations to apply simple propositional logic to determine service compatibility. A Policy is a set of assertions made about Security messages behavior level of service limited by the actual service capabilities Policy-sets are attached, embedded or otherwise associated with contracts Policy specifies a run-time dynamic, negotiable configuration information for a contract implementation. 2003 PSS Global Summit
- 2003 PSS Global Summit Took Clemens example – but Reversed contract direction – The is “owned” by the service provider not the consumer
- address, a URI, a specific place where the service can be found. A specific contract can be exposed at a specific endpoint. 2003 PSS Global Summit
- Services Revolve Around Messages Services Are “Black Boxes” Messages go in and out The Rest Is an Implementation Detail! 2003 PSS Global Summit
- Between Services is Special Messages Are Sent and Float Around Between Special Care Is Needed to Understand Them Can Be Confusion About Interpreting Them Many Kinds of Message transports Email, IP, TCP/IP, HTTP, Web-service, MSMQ, MQ-Series, and more Many Kinds of Message structures XML, Binary, whatever May be OK to Have Some Message Loss If messages are idempotent Other option “Reliable Messaging” 2003 PSS Global Summit
- 2003 PSS Global Summit
- One Way Incoming Outgoing Broadcast Publish (as in publish/subscribe) To single recipient Duplex Two one-ways Request/Reply R equest/Reaction 2003 PSS Global Summit
- Messages & Formats Message Exchange Patterns Where is a service located (Address) Protocol & content format (Binding) 2003 PSS Global Summit
- Service Data is private Keep DB private Keep transactions private Keep exceptions private Don’t share classes or other internal data structures Don’t share too much – or you’ll lose autonomy (or tempt others to lose it) 2003 PSS Global Summit
- Services interactions are message driven Services should be Loosely coupled Edges should provide location transparency Business logic and edge are separate layers Scale inside the service You can use workflows for long-running interactions again - inside the service 2003 PSS Global Summit