A Reference Architecture for Service Oriented Architecture (SOA)

1. A Reference Architecture forService Oriented Architecture (SOA)

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., WebServices)

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 Service 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 Services 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)” http://orchestrationpatterns.com/?q=node/13

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… • “Service 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…“ • "Service-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' ,,,” • “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 Services sets…” • And so on… Source: http://orchestrationpatterns.com/?q=node/13

5. What is SOA? ---- More definitions • The orchestration patterns website outlines 12 additional definitions of SOA from industry experts… The diversity in definitions is interesting… • “Service 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…“ • "Service-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' ,,,” • “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 Services sets…” • And so on… It’s a bit confusing… is SOAabout: • Web Services • Business Architecture • Services • “Loose Coupling” • Integration • All of the above? • Or something else… Source: http://orchestrationpatterns.com/?q=node/13

6. Microsoft and SOA… A Microsoft View on SOA: “The goal for Service Oriented Architecture (SOA) is a world-wide mesh of collaborating services that are published and available for invocation on a Service Bus. Adopting SOA is essential to delivering the business agility and IT flexibility promised by Web Services…” Microsoft uses a Metropolisanalogy 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: http://msdn.microsoft.com/architecture/soa/default.aspx

7. IBM & SOA…. IBM’s Website on SOA (linked here fromdeveloperworks.com)is clearly targeted atselling IBM tools andprofessional services… Source: http://www-306.ibm.com/software/solutions/webservices/

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…

9. SOA Buzz… … you however will be well equipped to play“buzzword bingo” at the meeting where somebodytries to explain SOA…

10. Service 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 beconstructed to govern common aspects of all applications built in accordancewith this style…

11. Service Oriented Architecture is an Example of an Architectural Style • SOA as an Architectural Style: • What are the architectural components? • Services • What are the architectural connectors? • Messages • What patterns govern the design of the components and connectors? • Data Services, Business Services, Composite Services • 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 • Services are network addressable • Services are language and platform independent • Services have flexible instantiation capabilities • Services are stateless • Messages are formally defined by a service contract • …

12. The “Actors” in an SOA – Service Consumers, Service Providers & Messages Message Service Provider ConcreteService Service Consumer Application IntermediaryService Service ConsumedServiceInterface ProvidedServiceInterface

13. The Architectural Components - Services • Services 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 • Services are designed to have flexible interfaces and are evolved easily • Services separate the concerns of the service consumer from the service provider • Services can be instantiated in a variety of different ways • Local components, Web Services, Sync-/Asynchronous Messages • Services are lifecycle managed by an application server container of some sort • CICS, .Net Framework, J2EE (WebSphere, Axis)

14. The Architectural Connectors - Messages • Services 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

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

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

17. Best Practices for Service Design in an SOA • Services for an SOA should be built using the “Design by Contract” approach • Service 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 • Services 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) • Service contracts should be designed for extension, and organized around business events that the service supports • Service contracts define “subject areas” that support the various business events supported by the service • Service contract can be used by a service invocation framework • Examples: WSDL for Web Services

18. Best Practices for Interface and Message Design in SOA • Service 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 <ServiceRequestMessage> <MessageHeader> <!-- Miscellaneous Header stuff goes here --> <BusinessEvent> <!– Enumeration of supported business events goes here --> </BusinessEvent> </MessageHeader> <MessageBody> <SubjectArea1>...</SubjectArea1> <SubjectArea2>...</SubjectArea2> <SubjectAreaN>...</SubjectAreaN> </MessageBody> </ServiceRequestMessage> 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.

19. Some Misconceptions about Services • Services are not Database API’s • Use stored procedures for “black box” operations on data • A service can be implemented as a Web Service, but a Web Service 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”

20. We will see later that services come in different styles • Service Styles • Basic Services • Integration Services • Composite Services

21. Anti-Best Practice for Creating Services: The “Right-Click” method…

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: • Any method in the components class that is public and decorated with “[WebMethod]” becomes part of the service interface <%@ WebService Class="ClassName_Goes_Here" %>

23. Design Service Like Mini-Applications

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

25. Objects and Components (again) • Services are the main entities in applications constructed using SOA principles • Services 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 • Services can then be placed in context of a reference architecture for SOA

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

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

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

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)

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

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

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”

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

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

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

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

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

38. Service 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

39. An SOA Reference Architecture

40. SOA Reference Model 101 Message Type Delivery Method Delivery Channel Transport Protocol Payload Format Encoding Semantics Extensions Message Provider FunctionalService Requestor Application IntermediaryService Service ServiceInterface

41. Components of the SOA Reference Architecture Service FunctionalType ServiceStyle Service Interface Application Specific Components Service Integration Adapters ServiceMessaging Models Quality of Service (QoS) Characteristics Application Service Integration

42. Establishing the Functional Aspect of the Service in an SOA Service Requestor Message Service Provider(or Service Intermediary) Service Types Partners ApplicationCode RPC Component Service 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) Legacy ApplicationCode TCP/IP 3rd PartyApplications Business Service Service Resources Component services composed of combinations of component services and rules. Legacy Service Consumers Transport Database WS-ReliableMessaging Data Service Services providing data querying, combination and transformation for multiple data sources. OtherServices Partners Event-Driven Service MessageBroker Services that react, publish or implement enterprise business events. Files Web App Business Process Service OtherServices Long lived business processes coordinating other services with external interactions. HTTP/HTTPS Portal Core Services ServicePolicies ServiceManager Security

43. Integration • Quality of Service • Transformation • Coordination • Business Process Metadata • Composition • Routing • Caching ESB Infrastructure The Enterprise Architecture Reference Model for SOA Containers Process/PM WebSphereJ2EE Microsoft.Net CICS Database SDLC Management Methodology Messaging / Transactions / EAI 3rd Party Integration Security Services Application Functional Services Presentation PurchasedApplications Basic Service UtilityService Proxy Service InfrastructureComponents ApplicationComponents InternalApplications Wrapper Service Service Repository SOA Design Controller Service (Simple Business Process Composition) PartnerApplications Messaging Service Architectural Styles Messaging / Transactions / EAI Messaging / Transactions / EAI Design & Architectural Patterns QoS - Clustering/Load Balancing Components Workflow Coordination Service(ACID Transaction) SOAPatterns Workflow Service(Business Process, Business Transaction) Application FrameworkComponents Legacy Rules LegacyApplication Core Infrastructure Inter-, Intra-, and Extranet Gateways LegacyApplication LegacyApplication Data Transformation XML Processing Policy Enforcement Via Data Service Messaging / Transactions / EAI Storage Reporting / Information Management ODS BOR Warehouse Data Mart OperationalReporting ReportingApplications Analytical Reporting ETL MessagingInterface Legend: Data Application Domain Enterprise Architecture Domain Corporate Domain Infrastructure

44. Messaging Taxonomy SOA Transport Models for Messages Supported by the Reference Architecture DeliveryPattern DeliveryMethod Extensions EncodingSemantics Payload Format Protocol • TCP/IP • HTTP/HTTPS • RMI • IIOP • .Net Remote • MQ • WS-Reliable Messaging • RPC • The payload contains attributes that directly bind to service parameters • Document-Centric • The payload is encoded as a structured document • Endpoint Addressing • XML • Binary • SOAP • XML-RPC • CORBA • Custom/ Proprietary • Serialized Object • 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

45. Service Specification Step 3:Specify Service Interface Step 4:Define SupportedMessaging Models Step 5:Define Quality of Service (QoS) Characteristics Step 2:Select ServiceStyle Step 1:Select ServiceType Each designed service should be classified by its service type A service should also specify its required and provided QoS attributes such as security, transactions, performance, etc. 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 Each service should provide a well-designed interface encapsulating the desired service behavior 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

46. The Service Styles are Related Basic Services Integration Services Composite Services Controller Service Basic Service Proxy Service [adds externalizedworkflow capabilities to] [is a special type of] [is a specialization of] Workflow Service Utility Service Wrapper Service [adds ACID transactionsupport to] Coordination Service

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

48. ESB Interfaces

49. ESB Features

50. Utility Service UML 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. Description Utility services are conceptually similar to library or framework components in traditional application architectures. Design Guidance