Definition of SOA. Capgemini University Technology Services School Capgemini - All rights reserved November 2006 SOA for Software Architects/ 2

Transcription

1 Gastcollege BPM

2 Definition of SOA Services architecture is a specific approach of organizing the business and its IT support to reduce cost, deliver faster & better and leverage the value of IT. November 2006 SOA for Software Architects/ 2

3 Goal of SOA The goal of Service Orientation is to design for change. November 2006 SOA for Software Architects/ 3

4 The 4 Tenets of Service Orientation 1. Boundaries are explicit 2. Services are autonomous 3. Services share schema and contract, not class 4. Service compatibility is based upon policy November 2006 SOA for Software Architects/ 4

5 Boundaries are explicit A boundary represents the border between a service s public interface and its internal, private implementation Explicit message passed over well-defined boundaries Crossing boundaries can be expensive, provide few welldefined public interfaces to your service Internal (private) implementation details should not be leaked outside of a service boundary November 2006 SOA for Software Architects/ 5

6 Services are autonomous Services have control they encapsulate Services are entities that are independently deployed, versioned, and managed Plan for failure November 2006 SOA for Software Architects/ 6

7 Services share schema and contract, not class Service interaction should be based solely upon a service s policies, schema, and contract-based behaviours Once a service contract has been published it becomes extremely difficult to modify it while minimizing the impact upon existing service consumers. November 2006 SOA for Software Architects/ 7

8 Service compatibility is based upon policy It is not possible to communicate some requirements for service interaction in service interface alone so use policy Operational requirements for service providers can be manifested in the form of machine-readable policy expressions. Policy expressions provide a configurable set of interoperable semantics governing the behavior and expectations of a given service November 2006 SOA for Software Architects/ 8

9 Architectural principles for design and service definition Loose coupling - Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other Abstraction - Beyond what is described in the service contract, services hide logic from the outside world Reusability - Logic is divided into services with the intention of promoting reuse November 2006 SOA for Software Architects/ 9

10 Architectural principles for design and service definition (cnt) Composability - Collections of services can be coordinated and assembled to form composite services Statelessness Services minimize retaining information specific to an activity Discoverability Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms November 2006 SOA for Software Architects/ 10

11 Stateless / Statefull design November 2006 SOA for Software Architects/ 11

12 What is state? What is state? State is data-specific information to a current activity In the context of SOA, services are regarded as stateless if service invocations are stateless Design of service invocations should not assume any prior knowledge about what would get invoked first or last Service has state while it is running. Keep the state duration and size lean and mean. Statelessness promotes scalability and reusability November 2006 SOA for Software Architects/ 12

13 Service example (1) November 2006 SOA for Software Architects/ 13

14 What is state continued While a service is processing it is temporarily stateful or aware of state message A Stateless (Unaware of message A) Stateful Receive message A Interpret message A Process message A Forward message A message A Stateless (Unaware of message A) November 2006 SOA for Software Architects/ 14

15 (Dis)advantages of statefull/stateless The two scenarios shown before have distinct implications : Statefull Stateless Easier to design & build Better performance Simple transaction management Poor scalability Tight coupling between services Availability Promotes reuse Services are autonomous (not dependent) Very scalable Loosely coupled Harder to design & build Difficult on transactions Performance overhead Higher availability of services November 2006 SOA for Software Architects/ 15

16 Sync / Async November 2006 SOA for Software Architects/ 16

17 Definition: Sync. vs Async. Synchronous Asynchronous Request Trip Booking Booking Details Request Trip Booking Ack Request Booking Details Book Trip Book Trip Book Vehicle Book Hotel Book Airline Book Vehicle Book Hotel Book Airline Requester needs to wait for the response It also handles exceptions. November 2006 SOA for Software Architects/ 17 Requester may carry on The response & exceptions are handled by the orchestration service

18 SOA & Synchronicity Decoupling the call/reply of a service from the processing involved makes a caller independent from the service. Implementing asynchronous enhances adaptability Extra behavior can be added in the orchestration. The caller is isolated from such changes. Extra Steps November 2006 SOA for Software Architects/ 18

19 Impact on End User Expectations Currently most business users are used to synchronous behavior from the primary IT systems Systems provide answers and errors straight away Changing that habit towards asynchronous might not be easy New business process definitions necessary End users don t know when they will get an answer to their request Enquiry mechanisms are necessary November 2006 SOA for Software Architects/ 19

20 The request and the answer are separated, some scenario s: Impact on technology An answer channel is necessary to report out the results (e.g. B2B) A polling model where the client checks for new info (e.g. RSS) Asynchronous services enforce extra logic, some scenario s: The process controller has to call a service to deliver the answer A integration broker provides an asynchronous service by accepting a request straight away, calling a synchronous service, then delivering the answering asynchronously. An enquiry mechanism is required The web service itself is hardly changed technology-wise It still can report some errors straight away (schema validation, authorization, authentication) Service result is delivered through different service call November 2006 SOA for Software Architects/ 20

21 Transactions November 2006 SOA for Software Architects/ 21

22 What is a transaction? A transaction is a unit of interaction with a system that is treated in a coherent and reliable way independent of other transactions, that must be either entirely completed or aborted. Ideally, a system will guarantee all of the ACID properties for each transaction. Atomic Consistent Isolated Durable November 2006 SOA for Software Architects/ 22

23 Transactions in a SOA world Services are loosely-coupled Stateless unaware of transactional state (no roll-back ) Asynchronous may not get a response in a timely manner (difficulty with serial transactions) Distributed concerns regarding latency, reliability and security Opaque Only the interface is known Nested transactions We need a Transaction Coordinating Service Managing a, possible, complex transaction Dealing with nesting, concurrency, security and scheduling November 2006 SOA for Software Architects/ 23

24 Example: Booking a Trip service November 2006 SOA for Software Architects/ 24

25 Why does SOA make transactions difficult? The Business Transactions are not Atomic anymore They have to deal with the state of the data in between service calls the errors that may occur in each service it uses Workflow Business Service Service Data Access Services are Atomic They always finish in a consistent state November 2006 SOA for Software Architects/ 25

26 Example: Booking a trip (cntd) SOA Business Service B2C B2B User aware Business Service B2C B2B Book Trip Book Vehicle Book Hotel Book Airline Book Vehicle Book Hotel Book Airline November 2006 SOA for Software Architects/ 26

27 Options to deal with distributed transactions Try to stay away from distributed transactions Avoid 2-phase commit If the business requirements are there, the options are Compensating transactions Journal pattern Find the business Undo / Back order, and implement it November 2006 SOA for Software Architects/ 27

28 Transactions Summary We have to deal with 2 levels of transactions Service level: Autonomous, well-contained, fine grained transactions Business level: business context driven, connected to business processes The issues around managing transactions in a SOA world are: Coordinating Transactions Handling the impact of the various states of a Business Transaction on the data Handling Exceptions November 2006 SOA for Software Architects/ 28

29 Issue: Locking In a SOA environment services manipulating data can be invoked by different services potentially at the same time. Data integrity is at risk once two sessions begin to work on the same records and lost updates are quite possible. Also, with one session editing data that another is reading an inconsistent read becomes likely. Stateless behaviour is required, locking data in the database is a form of state November 2006 SOA for Software Architects/ 29

30 Locking Pessimistic locking Lock everything at the beginning. Breaking a SOA tenet Optimistic locking Don t lock and verify at the end if it safe to commit. Can this be done? November 2006 SOA for Software Architects/ 30

31 How it works: How it works Optimistic Offline Lock Associate a version number with each record in your system. When a record is loaded that number is retained by the session along with all other session state outside the service. When storing the results the validation is a matter of comparing the version stored in your session service call to the current version in the stored data. Once the verification succeeds, all changes, including an increment to the version, are committed. November 2006 SOA for Software Architects/ 31

32 When to apply it? Optimistic Offline Lock When to use it: OOL is appropriate when the chance of conflict between any two business transactions is low. Pessimistic Offline lock is more appropriate when the chance is higher or the expense of a conflict is unacceptable. OOL should be used as a standard approach when performing conflict management in any system you build. November 2006 SOA for Software Architects/ 32

33 The Cost of SOA Implementing SOA is expensive Design Broader scope Implementation Mapping of data structures between layers Transactions Sync/Async patterns Security Performance XML conversions Security Managing Version management November 2006 SOA for Software Architects/ 33

34 SOA is executed as part of a larger strategy crosses many silos and kingdoms Understand SOA drivers and impact focuses on enabling enhanced business agility considers reuse to be of paramount importance are substantially based on standards incorporates many technologies (and vendors) Choosing SOA based architecture will impact design, build, test, implementation and maintenance of the resulting system. November 2006 SOA for Software Architects/ 34