1 D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 212
2 D.1 Principles of service-orientation 213 HISTORICAL PERSPECTIVE Initial thrusts of software component / distributed object approaches to standardize invocation mechanisms to make transparent the location of these components on the network With the success of XML languages, the concept of service detached from a common middleware emerged standardized and interoperable protocols and technologies over the web A service is neither software nor a process but an abstraction that implements a capability
3 D.1 Principles of service-orientation 214 SERVICE-ORIENTED ARCHITECTURE A model for the execution of loosely coupled and dynamic service-based software applications A model in which business logic is decomposed into smaller, distinct units of logic (eventually distributed). Each unit : exists individually (autonomy) yet not isolated from each other is required to conform to a set of principles (standards) is called atomic service A service is seen as a standardized and interoperable interface of a specific function
4 D.1 Principles of service-orientation 215 WHAT S A(WEB) SERVICE? Standardized and interoperable distributed software components that perform some function over Web protocols and technologies Implies both a service provider and a service user May be included in business process of services in order to address specific collaboration problem Implemented by means of Web services technologies e.g., SOAP, REST using a technical architecture using Web services is not enough to be service-oriented
5 SERVICES CAN ENCAPSULATE VARYING AMOUNT OF LOGIC D.1 Principles of service-orientation 216
6 D.1 Principles of service-orientation 217 SERVICES RELATE THROUGH DESCRIPTIONS Because it has access to service B s description, service A has all of the information (e.g., name, location, data exchange, etc.) it needs to communicate with service B
7 D.1 Principles of service-orientation 218 SERVICES COMMUNICATE BY MEANS OF MESSAGES A message exists as an independent unit of communication After a service sends a message, it loses control of what happens to the message thereafter
8 D.1 Principles of service-orientation 219 SERVICE-ORIENTATION ISSUES When a solution is comprised of units of serviceoriented processing logic, it becomes a service-oriented solution
9 D.2 Principles of service-orientation 220 ELEMENTS OF SOA (1/2) Loose coupling. No tight transactional properties would generally apply among the components. no technological constraints the failure of a part of the system does not imply a total failure of the service communication is done by asynchronous messages Implementation neutrality. The interface is what matters. We cannot depend on the details of the implementations of the interacting components. Flexible configurability. The system is configured late and flexibly. The configuration can change dynamically. a SOA is said to be dynamic when it is not completely preconfigured during the development and deployment steps; some parts of the service are specified and (re)configured at run time.
10 D.1 Principles of service-orientation 221 ELEMENTS OF SOA (2/2) Persistence. The components must exist long enough to be able to detect any relevant exceptions, to take corrective action, and to respond to the corrective actions taken by others. Components must exist long enough to be discovered, to be relied upon, and to engender trust in their behavior. Granularity. The participants in an SOA should be understood at a coarse granularity. Interactions and dependencies should occur at as high a level as possible. Teams. Instead of framing computations centrally, it would be better to think in terms of how computations are realized by autonomous parties.
11 D.1 Principles of service-orientation 222 PRINCIPLES OF SERVICE-ORIENTATION Contract. Services adhere to a communications agreement, as defined collectively by one or more service-description documents. Loose coupling. Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other. Abstraction. Beyond descriptions in the service contract, services hide logic from the outside world. Reusability. Logic is divided into services with the intention of promoting reuse. Autonomy. Services have control over the logic they encapsulate. Statelessness. Services minimize resource consumption by deferring the management of state information when necessary Discoverability. Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. Composability. Services are effective composition participants, regardless of the size and complexity of the composition.
12 D.1 Principles of service-orientation 223 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (1/8)
13 D.1 Principles of service-orientation 224 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (2/8)
14 D.1 Principles of service-orientation 225 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (3/8)
15 D.1 Principles of service-orientation 226 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (4/8)
16 D.1 Principles of service-orientation 227 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (5/8)
17 D.1 Principles of service-orientation 228 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (6/8)
18 D.1 Principles of service-orientation 229 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (7/8)
19 D.1 Principles of service-orientation 230 HOW SERVICE-ORIENTATION PRINCIPLES INTER-RELATE (8/8)
20 D.1 Principles of service-orientation 231 RPC VS. DOCUMENT ORIENTATION OF SERVICES (1/2) Both use XML documents to communicate but there is a conceptual difference in what is represented by the document RPC-centric view treats services as offering a set of methods to be invoked remotely documents are serialization of the business objects
21 D.1 Principles of service-orientation 232 RPC VS. DOCUMENT ORIENTATION OF SERVICES (2/2) Document-centric view treats services as exchanging documents one another documents are the main representations and purpose of the distributed computation
22 D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 233
23 D.2 Service exchange lifecycle 234 SERVICE EXCHANGE LIFE CYCLE
24 D.2 Service exchange lifecycle 235 LIFE CYCLE: SERVICE CREATION Virtualization (i.e., servicization ) : taking an already existing application and transforming it into a service e.g., interfacing a private application with web service technologies Dissemination: creating a new service that directly realizes the wanted functionality from scratch e.g., writing a new atomic web service Aggregation: creating a new service by aggregating, composing already existent services e.g., implementing a new business process
25 D.2 Service exchange lifecycle 236 LIFE CYCLE: SERVICE SELECTION Service matchmaking: a service needs to be discovered by a user and a correspondence between the user s goals and the service functionalities has to be established Service selection Local: depends on reputation mechanisms, recommender techniques, referrals, trust or other social aspects directly connecting the service user and provider; Global: occurs in a marketplace Service user and providers might already know each others or might both use service registries
26 D.2 Service exchange lifecycle 237 LIFE CYCLE: SERVICE REGISTRIES Enable service providers and users to locate each other Asymmetric registry: provider publishes a service offer in a registry and user finds it Yellow pages: find service providers by their characteristics and capabilities according to a standard taxonomy of domains White pages: find service providers by their identity Green pages: find all the services provided for a given service provider Symmetric registry: gather both service offers and demands. The role of the registry is to facilitate the matchmaking.
27 LIFE CYCLE: SERVICE CONTRACT (1/2) D.2 Service exchange lifecycle Negotiation is a process by which a joint decision is reached by two or more agents, each trying to reach an individual goal or objective (possibly contradictory with the other s) 238 Service provider and user, after negotiation, come to a mutually acceptable agreement about the terms and conditions under which the desired service will be performed: contracts or Service Level Agreements (SLAs). formalizes the service exchange
28 LIFE CYCLE: SERVICE CONTRACT (2/2) D.2 Service exchange lifecycle Agents identification: user, provider and eventually third party involved Functional description: what the service does, (business logic view) 239 Interface specification: how the service works (interaction view): formats, protocols, syntax Operational description (i.e., quality of service): next slide Contract life cycle: service performance lifetime and frequency, the conditions of renewal, the conditions of service end over Exchange description: some properties about the service e.g., is free or not, what are the payment conditions
29 D.2 Service exchange lifecycle 240 QUALITY OF SERVICE (QOS) Domain of application, with the limits of the performance, rights and obligations of agents involved in the service exchange, but also the conformity to standards, etc. Quality of performance such as dimensionality, effectiveness, accessibility, accuracy and precision of the service. Security conditions and level with authentication policies, authorization listings, privacy rules, integrity, etc. Robustness description with reliability, availability, continuity of the service, but also some technical properties such as transaction management, etc. Management description which specifies who drives, and monitors, the service performance. What will be the follow-up, the warranty, etc. Rules and adaptation to changes such as dysfunction, evolution, versioning, etc.
30 LIFE CYCLE: SERVICE COMMUNI CATION D.2 Service exchange lifecycle Message passing based communication conceptually differ from invocation 241 Methods of the services are not directly invoked by users, instead the provider decides how to proceed by interpreting the user s message and invoking itself the good method(s). Synchronous: requires the sender and receiver to wait for each other to transfer the message Asynchronous: sender send without waiting for the receiver to be ready and without being block waiting for response
31 LIFE CYCLE: SERVICE PERFORMA NCE Internal stateful performance: some reversible state transitions on service provider data Stateless performance: No state changes during the performance. D.2 Service exchange lifecycle can be restarted following a failure without concern for its history of prior interactions same occurrences of the service should be executed several times without effects read only on underlying application evolving state e.g., clock persist over multiple interactions. state can evolve independently of service call same occurrences of the service produce successive state transitions 242 Resource stateful performance: some state transitions on an external resource (environment) or agent (including the service user) side effects by nature irreversible
32 D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 243
33 D.3 Service composition 244 BUSINESS PROCESS MANAGEMENT (BPM) A business process is a structure that defines logical and temporal relations between services (i.e., service composition) the composite service performance is the result of the combination of the composed service performances engaged in the process hard: maintain global coherence without explicit global control Requires communication between composed services: static (i.e., done before the business process execution) orchestration/workflow dynamic (i.e., done while the business process is executed) choreography/conversation
34 D.3 Service composition 245 SERVICE ORCHESTRATION/WORKFLOW Execution of specific business processes (centralized) Static definition of the interaction Orchestration engine e.g., WS-BPEL The heart of SOA
35 SERVICE D.3 Service composition CHOREOGRAPHY/CONVERSATION 246 Conversation language e.g., WSCI, WS-CDL Uses defined protocols Harder than orchestration Multi-party collaboration (distributed) Describing externally observable interactions between services
36 D.3 Service composition 247 BPMN Business Process Modeling Notation Graphical representation for specifying business processes
37 BPMN EXAMPLE D.3 Service composition Example: collaborative decision taking workflow 248
38 D. SERVICE ORIENTED ARCHITECTURE PRINCIPLES 1. Principles of serviceorientation 2. Service exchange lifecycle 3. Service composition 4. Evolution of SOA 249
39 D.4 Evolution of SOA 250 SOA & THE ENTERPRISE Introduction of services (abstraction) Business logic is a documented implementation of the business requirements that originate from an enterprise's business areas Application logic is an automated impl of business logic (variant technology)
40 D.4 Evolution of SOA 251 SOA DELIVERY LIFECYCLE
41 STANDARDS ORGANIZATIONS THAT CONTRIBUTE TO SOAS D.4 Evolution of SOA 252
42 HISTORICAL VIEW OF SERVICES OVER THE WEB D.4 Evolution of SOA 253 Generation Scope Technology Example First All Browser Any HTML page Second Programmatic Screen scraper Systematically generated HTML content Third Standardized Web services Formally described service Fourth Semantic Semantic Web services Fifth Collaborative Business protocols Semantically described service Service engagements
43 D.4 Evolution of SOA 254 WEB SERVICE LIFE CYCLE EVOLUTION?
44 D.4 Evolution of SOA 255 MORE ON SOA AND SOC Web%20Services.pdf 2011:si5:soa:start books/soc/