A Reference Architecture for Service Oriented Architecture (SOA)

Transcription

1 A Reference Architecture for Oriented Architecture (SOA) 1

2 Motivation Why do we need SOA Redundancy Implementation inconsistency Lack of inter-operability Wrapper -Happy Lack of Modularity Misconception: SOA is about design and not technology (i.e., Webs) 2

3 What is SOA? ---- Randy Heffner, Forrester Research "A pattern of design, development, deployment, and management of (a) applications and (b) software infrastructure and frameworks in which: Applications are organized into business units of work (services) that are (typically) network accessible interface definitions are first-class development artifacts Quality of service (QoS) characteristics (security, transactions, performance, etc.) are explicitly identified at design time Software infrastructure takes active responsibility for managing QoS and enforcing policy for service access and execution s and their metadata are cataloged in a repository Protocols and structures within the architecture are, optionally, based on industry standards (e.g., the emerging SOAP stack of standards) 3

4 What is SOA? ---- More definitions The orchestration patterns website outlines 12 additional definitions of SOA from industry experts The diversity in definitions is interesting Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol-independent distributed applications SOA is a form of technology architecture that adheres to the principles of service orientation "-oriented architecture is an architectural discipline SOA is a style of design that strives to enable easy integration and flexible applications "A service oriented architecture is an approach to design and integrate software in a modular method where each module is precisely a 'loosely coupled service',,, Oriented Architecture is nothing but business oriented architecture SOA is a framework enabling application functionality to be provided, discovered and consumed as re-usable Web s sets And so on Source: 4

5 What is SOA? ---- More definitions The orchestration patterns website It s outlines a bit confusing 12 additional is definitions SOA of SOA from industry experts The diversity about: in definitions is interesting Oriented Architecture (SOA) is an approach to the development of loosely coupled, protocol-independent distributed applications SOA is a form of technology architecture that adheres to the principles of service orientation 2. Business "-oriented architecture is an architectural discipline SOA is a style of design that strives to enable easy integration and flexible applications "A service oriented architecture is an approach to design and integrate software in a modular method where each module is precisely a 4. 'loosely Loose coupled Coupling service',,, Oriented Architecture is nothing but business oriented architecture SOA is a framework enabling application functionality to be provided, discovered and consumed as re-usable Web s sets 6. All of the above? And so on 1. Web s Architecture 3. s 5. Integration 7. Or something else Source: 5

6 Microsoft and SOA A Microsoft View on SOA: The goal for Oriented Architecture (SOA) is a world-wide mesh of collaborating services that are published and available for invocation on a Bus. Adopting SOA is essential to delivering the business agility and IT flexibility promised by Web s Microsoft uses a Metropolis analogy to explain SOA The idea being that cities, like an SOA, require services (police, manufacturing, shopping, etc.) and a transportation (bus, railroad, etc.) system to thrive Source: 6

7 IBM & SOA. IBM s Website on SOA (linked here from developerworks.com) is clearly targeted at selling IBM tools and professional services Source: 7

8 SOA You may either feel educated or sleepy by now, but you probably know little more than when you arrived at this class about SOA 8

9 SOA Buzz you however will be well equipped to play buzzword bingo at the meeting where somebody tries to explain SOA 9

10 Oriented Architecture is an Example of an Architectural Style An Architectural Style defines a family of systems in terms of a pattern of structural organization. What are the architectural components? What are the architectural connectors? What patterns guide the design of the components and connectors? How are faults and unexpected events handled? Clear definition of the set of constraints on the architectural components and the relationships that are allowed between them Because SOA is an Architectural Style a Reference Architecture can be constructed to govern common aspects of all applications built in accordance with this style 10

11 Oriented Architecture is an Example of an Architectural Style SOA as an Architectural Style: What are the architectural components? s What are the architectural connectors? Messages What patterns govern the design of the components and connectors? Data s, Business s, Composite s How are faults and unexpected events handled? Language specific exception handling mapped to service faults Clear definition of the set of constraints on the architectural components and the relationships that are allowed between them s are network addressable s are language and platform independent s have flexible instantiation capabilities s are stateless Messages are formally defined by a service contract 11

12 The Actors in an SOA Consumers, Providers & Messages Provider Consumer Application Message Intermediary Concrete Consumed Interface Provided Interface 12

13 The Architectural Components - s s are a conceptual design component, and can be implemented using a variety of different technologies Java Beans, (Enterprise Java Beans).Net Class Files (ASMX) COBOL Programs Third party tools: Siebel s are designed to have flexible interfaces and are evolved easily s separate the concerns of the service consumer from the service provider s can be instantiated in a variety of different ways Local components, Web s, Sync-/Asynchronous Messages s are lifecycle managed by an application server container of some sort CICS,.Net Framework, J2EE (WebSphere, Axis) 13

14 The Architectural Connectors - Messages s interoperate with each other using messages capable of verifying and certifying their own syntax and semantics Architecture Requirements for Messages Messages do not assume any sort of delivery technology Messages support intermediaries and can be transformed between the service consumer and the service provider without either party being aware of the transformation process Messages can be secured end-to-end Messages can be deserialized into language-specific components Language specific components can serialize themselves into a valid message that adheres to both the syntactic and semantic requirements of the message 14

15 Messages and XML In a SOA, messages are generally encoded as XML documents Character-based encoding is the lowest-common denominator for almost every computing and message-transport platform Research into XML parsing has produced parsers that can produce and digest XML documents very fast The valid structure of messages encoded as XML can be specified using a standard description language XML Schema XML Namespaces support the flexible extension of service interfaces XML is governed by a wide verity of standards Security Transformation Industry-specific business transactions Vendor-specific schemas 15

16 Benefits of the SOA Architectural Style Its all about the interface Loosen the coupling between a service component and the requesting application Support easy and rapid evolution of the service interface with a maximum degree of backward-compatibility Interface specifies the semantics used by the service provider Loosen the coupling between an application and the database Allows current data sources to be aggregated behind a service interface Allows the underlying data sources to evolve as authoritative data sources are created Messages define the types used by the interfaces of the service consumer and the service provider 16

17 Best Practices for Design in an SOA s for an SOA should be built using the Design by Contract approach contract developed first using a standard description language, typically XML Schema The service contract defines the service interface, encodes the message structure, and defines the message semantics s interfaces define the interface types, as such service programmers should not be working at the XML level Objects should be generated for the service interface from the service contract (i.e., XSDObjectGen for.net, JAXB for Java) contracts should be designed for extension, and organized around business events that the service supports contracts define subject areas that support the various business events supported by the service contract can be used by a service invocation framework Examples: WSDL for Web s 17

18 Best Practices for Interface and Message Design in SOA interfaces should be build around the specification and execution of useful application/business events The service interface should define a collection of subject areas that are relevant to the application/business events supported by the service <RequestMessage> <MessageHeader> <!-- Miscellaneous Header stuff goes here --> <BusinessEvent> <! Enumeration of supported business events goes here --> </BusinessEvent> </MessageHeader> <MessageBody> <SubjectArea1>...</SubjectArea1> <SubjectArea2>...</SubjectArea2> <SubjectAreaN>...</SubjectAreaN> </MessageBody> </RequestMessage> The application/business event coupled with the provided subject areas dictates what a service will do on behalf of the consumer, this model fits in naturally to business processes where the current view of the truth might be dependant on the state of the business process. 18

19 Some Misconceptions about s s are not Database API s Use stored procedures for black box operations on data A service can be implemented as a Web, but a Web is not necessarily a service in an SOA Reuse of a service is nice if you can find a requirement for it A service is best thought of as an authoritative access point to execute application/business events around a particular business subject area A service is a great place to get a business context aware view of the truth 19

20 We will see later that services come in different styles Styles Basic s Integration s Composite s 20

21 Anti-Best Practice for Creating s: The Right-Click method 21

22 .Net is no better for directly promoting a component to a service Decorate a component interface with [WebMethod] Create a file with an.axmx extension with a single line: <%@ Web Class="ClassName_Goes_Here" %> Any method in the components class that is public and decorated with [WebMethod] becomes part of the service interface 22

23 Design Like Mini-Applications Request- Tier Interface Tier Domain Object Tier Data-Access Tier Database Tier Web Server Message Queue Local Objects Message Validation Implementation Message Serialization Objects s should use type-safe objects that serialize/deserialize to XML in accordance with the service contract Domain Object Builder Domain Objects The domain tier represents the business domain and is unaware of how the business objects are persisted. Business logic goes here. Business Event Change Publisher Business Event Action Factory Actions (Events) Data Access Objects The domain layer is bound to the data access layer by action objects that manage business event transactions Data access objects are aware of how to persist domain objects in a database. Persisted Structures Stored Procedures Databases Mainframe Transactions Other (Messaging) 23

24 Outline Objects and Components Oriented Reference Architecture SOA Functional View SOA Architectural View SOA Messaging SOA Interfaces (provided & required) ESB 24

25 Objects and Components (again) s are the main entities in applications constructed using SOA principles s are constructed using components, which in turn, are created using objects Reviewing principles of objects and components is helpful in understanding how to design services s can then be placed in context of a reference architecture for SOA 25

26 Principles of OO Abstraction An object is known by its data type and behavior, providing a stable interface for communicating with and using the object. Encapsulation Implementation decisions are hidden inside of classes and were protected by variables (properties) and methods that were explicitly made public to the outside Allows for the separation of interface from implementation Polymorphism The ability for an class to take on different behavior-based on the runtime binding to object types 26

27 Principles of OO Inheritance The ability of one object to inherit the representation and behavior from another object. This inherited behavior and representation can be selectively used as is, extended, or replaced. Identity A class is a template for objects and objects are instances of classes All objects can be uniquely defined, have their own unique identity, and manage their unique state 27

28 Design Principles for OO Program to interface not implementation To extend behavior, favor object composition over inheritance extended behavior and original behavior are preserved This prevents a change to the original behavior from impacting inherited behavior Minimize coupling between objects to ensure that changes are localized and do not propagate Maximize cohesion within an object 28

29 Design Principles for OO Good interface design is essential It does not expose the underlying attributes (class level) or the underlying classes (subsystem/component level) Does not expose the underlying implementation Does a logical unit of work A change to the system should not require a change to the interface (property of good abstraction) 29

30 Problems with OO The design principles of OO scale to design principles for services in an SOA OO has scalability and complexity limitations Classes have to have compile or link time visibility to all other classes this implies repackaging/deploying an entire application unit when a class changes Distribution was handled manually using low level network protocols Interface design had to be perfect, but this was difficult to do in practice All types must be binary compatible Type conversion and object serialization/deserialization was a manual process 30

31 Components Components aggregate classes and focus on packaging and distribution OO design principles directly map to component design principles Yet component approaches to software design have their problems: Components must still provide a stable interface Components are only able to provide a single interface to their clients Designs using components are chatty, often requiring many components to perform a useful operation this makes scalability difficult Component frameworks are proprietary COM, DCOM, CORBA, J2EE/EJB 31

32 Step 1: Containers to the rescue Containers (a.k.a application servers) are like application-aware operating systems that sit on top of the native operating system (e.g., Microsoft.Net, J2EE) Standardizes resource allocation and sharing that is tightly integrated into component model Able to introduce component-aware semantics E.g., Secuirty attributes based on RBAC - beyond read, write, read-write, allow, deny Containers abstract many of the hard things: Finding things (directories), managing network resources, reliability, availability, database connections, security, on demand -stuff Code running in a container is often called managed code 32

33 Step 2: Messaging infrastructure to the rescue Traditional distributed inter-operability is generally achieved by sending a binary-encoded message over a synchronous network connection (e.g., socket) This approach makes it hard to: Provide multiple interfaces for a component Support asynchronous programming models Support common architecture styles (e.g., Pub-Sub) Support severs implemented in a different technology from the requestor Support applications with high-reliability requirements Support external routing information 33

34 Step 2: Messaging infrastructure to the rescue Messaging infrastructures are traditionally implemented as queues where messages, metadata and routing information are placed into a queue and the messaging infrastructure routes the message to from a source queue to a destination queue Queues may have properties such as triggers so that when a message of a certain type arrives it automatically invokes a component to process the message 34

35 Step 2: Messaging infrastructure to the rescue Messaging infrastructures also have their problems: The format for the encoded message is left to the user meaning the requestor and server must agree on the format The asynchronous programming model is more difficult for programmers to deal with than a synchronous programming model Deployment of applications using messaging infrastructure is fragmented 35

36 Step 3: Standards to the rescue finally enablement of SOA is possible SOA takes the best from OO, Components, Containers, and messaging infrastructures OO and Components provide the design principles Containers and messaging infrastructures provide the runtime environment Now standards such as the WS-* set enable containers to support distributed components that: Can interoperate using messaging or synchronous messages seamlessly Standardize the format and define semantics for the messaging payloads Supports external definition of routing and QoS of related to the delivery of messages 36

37 SOA Revisited SOA Represents every application or resources as a service with a standardized interface Is based on having services exchange structured information (as opposed to an RPC call) Provides facilities via a container to coordinate and mediate between the services so that they can be invoked, used and changed effectively 37

38 revisited A service is : A component that does something useful on behalf of an application Exposes its functionality and hides the implementation details Not dependant on the context or state of other services A service either provides information or facilitates the processing of an application feature ensuring that the application state is changed from one valid and consistent state to another Dependencies between services should be defined in terms of an application process 38

39 An SOA Reference Architecture 39

40 SOA Reference Model 101 Requestor Application Message Type Delivery Method Delivery Channel Transport Protocol Payload Format Encoding Semantics Extensions Message Intermediary Provider Functional Interface 40

41 Components of the SOA Reference Architecture Application Specific Components Functional Type Messaging Models Style Interface Quality of (QoS) Characteristics Integration Adapters Application Integration 41

42 Establishing the Functional Aspect of the in an SOA Requestor Message Provider (or Intermediary) Consumers Partners Application Code Legacy Other s Web App Portal Transport TCP/IP RPC WS-Reliable Messaging Message Broker HTTP/ HTTPS Types Component Simple services potentially acting on single enterprise resource (e.g., database, code, etc) and are created by aggregating and/or encapsulating one or more application-specific component interface(s) Business Component services composed of combinations of component services and rules. Data s providing data querying, combination and transformation for multiple data sources. Event-Driven s that react, publish or implement enterprise business events. Business Process Long lived business processes coordinating other services with external interactions. Resources Application Code Legacy Partners Database Other s 3 rd Party Applications Files Core s Security Drexel University Software Engineering Research PoliciesGroup (SERG) Manager 42

43 The Enterprise Architecture Reference Model for SOA Containers WebSphere J2EE Microsoft.Net CICS Database Process/PM SDLC Management Methodology Core Infrastructure Security Infrastructure Components QoS - Clustering/ Load Balancing Inter-, Intra-, and Extranet Gateways Messaging / Transactions / EAI Application Presentation Application Components SOA Design Design & Architectural Patterns Application Framework Components Messaging Utility SOA Patterns Reporting / Information Management Messaging / Transactions / EAI s Integration ESB Infrastructure Business Process Metadata Composition Data Transformation Quality of Transformation Coordination Routing Caching Messaging / Transactions / EAI Storage Functional s Basic Proxy Wrapper Controller (Simple Business Process Composition) Coordination (ACID Transaction) Workflow (Business Process, Business Transaction) Policy Enforcement Via Data Architectural Styles XML Processing Repository Workflow Rules Messaging / Transactions / EAI 3 rd Party Integration Purchased Applications Internal Applications Partner Applications Components Legacy Legacy Legacy Application Legacy Application Application Operational Reporting Reporting Applications Analytical Reporting ODS BOR Warehouse Data Mart ETL Legend: Drexel University Application Software Enterprise Engineering Research Corporate Group (SERG) Data Domain Architecture Domain Infrastructure Domain Messaging Interface 43

44 Messaging Taxonomy SOA Transport Models for Messages Supported by the Reference Architecture Protocol Payload Format Encoding Semantics Extensions Delivery Method Delivery Pattern TCP/IP HTTP/HTTPS RMI IIOP.Net Remote MQ WS-Reliable Messaging XML Binary SOAP XML-RPC CORBA Custom/ Proprietary Serialized Object RPC The payload contains attributes that directly bind to service parameters Document- Centric The payload is encoded as a structured document Endpoint Addressing Attachments Message Metadata (Security, Session, Context, etc.) Message Schema Marshalling and Datatype Specifications Synchronous Asynchronous Delivery QoS At Least Once At Most Once Exactly Once One-Way Command Event Request/ Reply Point-to-Point One-to-Many Publish/ Subscribe 44

45 Specification Step 1: Select Type Step 2: Select Style Step 3: Specify Interface Step 4: Define Supported Messaging Models Step 5: Define Quality of (QoS) Characteristics Each designed service should be classified by its service type Once a service type is defined, a service style should be selected based on the desired architectural characteristics of the service, its required resources, and potential consumers Each service should provide a welldesigned interface encapsulating the desired service behavior A service may be integrated into multiple applications under different contexts, therefore, the service design should also consider the messaging models that will be supported by the service A service should also specify its required and provided QoS attributes such as security, transactions, performance, etc. 45

46 The Styles are Related Basic s Integration s Composite s Basic [is a special type of] Utility Proxy [is a specialization of] Wrapper Controller [adds externalized workflow capabilities to] Workflow [adds ACID transaction support to] Coordination 46

47 ESB Where a container layered over the OS to facilitate the managed code model, an ESB lives within a container to provide function to services in an SOA An ESB Facilitates effective service communication Facilitates effective service integration Facilitates effective service interaction 47

48 ESB Interfaces ESB Interface Connection Change Control Description The ESB connection interface should fully support the synchronous and asynchronous web service stacks as well as message-oriented middleware (MQ Series), HTTP/HTTPS, Microsoft.NET d Components, Java Remote Method Invocation (RMI),.NET Remoting, CICS host transactions. Rather than changing code in a service interface, the ESB is configured with metadata to handle managing the service catalog, interface versioning, routing, quality of service (QoS), orchestration, security, business rules, and other volatile duties. The control interface provides enterprise management capabilities that are outside the scope of the individual services managed by the ESB. The control interface integrates with standard infrastructure management facilities, handles service provisioning to maintain QoS commitments, and provides reports/logs on the health and operation of the ESB infrastructure. 48

49 ESB Features ESB Features Description Security The ESB supports security policies regarding service usage ESB Features Communication Request Routing and Versioning Transformation and Mapping Aggregation Transaction Management Description Supports the ESB messaging requirements (protocol, style, sync, async, etc.) Support for subject-, content-, and itinerary-based routing. The ESB transparently routes requests to the correct version of the service interface, as well as managing the version instances. Support for mapping of data formats of message payloads in cases where the service requestor and provider have different interface formats The ESB may implement microprocesses that aggregate smaller services into larger services, which may also require transaction management. The ESB provides support for compensated transactions, working with other TP monitors to handle ACID transactions Quality of Registry and Metadata Management Extensibility for Message Enrichment Monitoring and Management The ESB can persist requests to message queues and retry service operations when failures occur, implement failover to alternate servers, and other steps to ensure that otherwise unreliable networks and services can be made to provide the quality of service required by the requester. When maintaining a name space (service discovery), the ESB may extend the service metadata this requires (such as WSDL), to enable services to be classified to ease searching for reuse. A special case of semantic mapping, enrichment enables database or table lookups to be merged into a message stream so that messages emerge from the bus richer with data than when they arrived. The ESB automate management as much as possible, it will also be necessary to enable humans to investigate problems, find root causes, and take action to correct the issues that are discovered. 49

50 Utility <<Utility >> <<component>> <<component>> UML Interface <<component>> <<component>> <<reusable business logic>> Description A utility service encapsulates generic functionality intended to be reused within and across different SOA applications. In SOA, most services are conceptual single-instance components that provide capabilities to one or more applications based on a published service contract (i.e., the service interface). A utility service is a special case of a service in an SOA as it is intended to be reused across (and not integrated into) multiple applications. Utility services are physically created by aggregating the desired public interfaces of one or more application components into the utility service interface. Design Guidance Utility services are conceptually similar to library or framework components in traditional application architectures. 50

51 Basic <<Basic >> <<component>> <<component>> UML Interface <<component>> <<component>> <<business logic>> Description A basic service encapsulates the functionality implemented in one or more business components by specifying a well-defined service interface that exposes a desired business capability. Each interface point in a basic service should be defined with a granularity in terms of performing a useful business unit-of-work (BUOW). A basic service must perform a discrete BUOW. Basic services can be orchestrated with other service styles to perform business processes. Basic services are usually defined top-down by performing analysis on a business domain, specification of business use cases, or business process walkthroughs. Design Guidance Basic services are best designed by properly establishing the service interface. Some best practices for creating the service interface include: (1) Interfaces that are easy to consume are as simple as possible, but no simpler (2) Be able to accomplish a business unit of work in a single call (3) Be used across many different contexts (not just the first app that it was built for) (4) Models business processes rather than lower level functionality (5) The service interface should be easy to version such that they can be easily extended with the addition of new parameters and doesn t break service consumers when a new interface is defined (6) The service interface should promote the concept of loose coupling by insulating the service consumer from changes in the service implementation, not requiring anything other than the schema and contract to know how to invoke them, and no leaking internal abstractions outside the service boundary. 51

52 Proxy <<Proxy >> UML Interface Proxy <<generated>> Existing Application Component Description A proxy service service-enables an existing application component by creating a service proxy component that facades the existing component. Proxy services can generally be automatically generated by an IDE, exposing the public interface (or a subset of the public interface) of the existing application component as a service. A proxy service is often used to integrate with an application that provides some desired functionality to an SOA application, but this functionality is implemented as a collection of API s and not as a service. Design Guidance One must be careful when creating proxy services, as they are easy to create, but yet are often inefficient from a design perspective when compared to other service types. Problems generally occur with proxy service designs because the underlying component s public interface is not optimized for an SOA. Designers should generally consider using a wrapper service when the goal is to integrate with an existing application that offers an API or an integration component. 52

53 Wrapper <<Wrapper >> Adapter <<proxy>> UML Interface {middleware} New Adapter Component Legacy Application Description A wrapper service exposes specific parts of legacy applications through a service interface. This service style essentially creates a new interface component, called an adapter, that adheres to good design principles of a business service. The adaptor component uses EAI to interact with a legacy application. The legacy application itself might require modification to support this style as the desired business logic that is exposed by the adapter component may not be accessible via direct EAI mechanisms. This service style is a good choice for application integration. Design Guidance Design the adapter component in a wrapper service style using the same principles that were described in the design guidance for a Business. Map the service interface in the adapter to functionality and business rules that exist in the legacy application. When possible interact with the legacy capability via EAI. In some cases the legacy system itself might require modification to support the adapter service interface (e.g., the business logic is embedded and not externally accessible) 53

54 Controller <<Controller >> Business Process UML Interface [service] [service] [service] <<service assembly>> Description A controller service represents the execution of a high-level business task (or simple business workflow). s designed using the controller style create control logic to implement the business task. This control logic is called a service assembly. From an SOA perspective its important to manage the granularity of the service designs. s that are too abstract are prone to high maintenance problems as their interfaces and behaviors are subject to a high degree of change. Aggregate services, such as a controller service provide additional flexibility to SOA-designs by creating a service that supports a business task, while at the same time, allowing the underlying services to be used and evolve independently. Design Guidance Whenever possible deploy the service assembly in the same container as the subordinate services. This enables the service assembly to interact with the other (subordinate) services via a local interface rather than a network interface such as SOAP. Also, since web service support is still very limited with respect to supporting context and transactions this guidance also allows the controller to work with the underlying services in a stateful way (i.e., supports ACID transactions). 54

55 Coordination <<Coordination >> Business Transaction Workflow / Business Process {begin} UML Interface [service] [service] {commit} [service] [service] <<business process with ACID transaction support>> Description A coordination service supports executing a workflow to implement a business unit-of-work (BUOW). The BUOW in a coordination service should be short-running as this service style supports ACID transactions. Unlike a controller service, the workflow in a coordination service is externalized, defined using a standard markup (i.e., BEPL), and executed by an infrastructure component that manages the actual workflow process. Design Guidance The transaction-oriented workflow outlined above is the topic of the WS-Transaction specification. With this specification workflows are defined using the BEPL markup. Given lack of BEPL support in the tools that we are using in class, applications requiring the characteristics of a coordination service should use a controller service instead an code the business process into the service assembly. 55

56 Workflow <<Coordination/Workflow >> Business Process Workflow / Business Process Description UML Interface {begin} {commit} [service] [service] A workflow service implements a business process. The workflow service does not support ACID transactions because the business process might be long-running (i.e., several days, require human intervention, etc.). Unlike a controller service, the workflow in a coordination service is externalized, defined using a standard markup (i.e., BEPL), and executed by an infrastructure component that manages the actual workflow process. Due to the nature of the workflow service style ACID types of transactions are not supported, instead, a compensation service is provided in this model to gracefully recover from unexpected problems. [service] [service] Context Coordination Compensation <<business process with compensated transaction support>> Design Guidance The workflow outlined above is the topic of the WS-Transaction and WS-Coordination specifications. With these specifications, workflows are defined using the BEPL markup. Given lack of BEPL support in the tools that we are using in class, applications requiring the characteristics of a workflow service should use a controller service instead an code the business process into the service assembly. 56

57 Blueprints for SOA Designs Application/ integration views Shows the application functionally decomposed (MVC Pattern for thin client) Shows the application in context of services that are consumed Defines all application/service integration points Views Defines services in terms of the reference architecture 57

58 References From Objects to s: A Journey in Search of Component Reuse Nirvana by M. Dodani, Journal of Object Technology vol3, no. 8, -Oriented Architecture : A Field Guide to Integrating XML and Web s by T. Erl, Prentice Hall, ISBN: What Is An Enterprise Bus?, by M. Gilpin, Forrester Research, 58