Service Oriented Architecture (SOA)

Service Oriented Architecture (SOA) Presented By SureShot Strategies Inc.

Agenda • What is a Service Oriented Architecture? • Web Services Introduction • Basic Web Services • Web Services versus other Distributed Technologies • Advanced Web Services • Anatomy of Service Oriented Architecture • Fundamental SOA • SOA Entities • Common Principles of SOA • Web Services & SOA Principles • Service Layering • Service Delivery Strategies • SOA support in J2EE • SOA support in .NET • SOA support in Super Platforms • SOA Adoption Roadmap & Compliance Levels

What is a Service Oriented Architecture?The Elevator Pitch • SOA is the next phase in the evolution of designing software systems • In the same manner in which mainframe architecture paradigm was succeeded by client-server architecture, and client-server architecture paradigm then evolved into n-tier distributed architecture based on Web Technologies, the contemporary, Web services driven SOA is succeeding the traditional distributed architecture on a global scale • Due to its abstract nature and distributed architecture with no reference to underlying implementation (implementation agnostic), SOA introduces new concepts supported by select technologies that significantly augment characteristics of traditional distributed computing platform • Coupled with Web services platform and a set of commonly accepted service-oriented principals, SOA has emerged an architectural paradigm explicitly distinct from its predecessors

Web Services, a Brief Introduction

Service Registry UDDI Service Description WSDL Message Envelope SOAP XML Schema for all Definitions XML HTTP/FTP/SMTP Transport What are Web Services? • Web services are a form of web applications that are self-contained, self-describing and modular, and that can be published, located, and invoked across the web using standard Internet protocols. • leverage existing HTTP infrastructure • leverage wide adoptability and flexibility of XML to define and package messages • Standards

Basics of Web Services • Web Services combine the best aspects of component-based development and the Web. Like components, Web Services represent black-box functionality that can be reused without worrying about how the service is implemented. • Unlike current component technologies, Web Services are not accessed via object-model-specific protocols, such as DCOM, RMI, or IIOP. Instead, Web Services are accessed via ubiquitous Web protocols (ex: HTTP) and data formats (ex: XML). • Web services are Extensible Markup Language (XML) applications mapped to programs, objects, or databases or to comprehensive business functions. • Using an XML document created in the form of a message, a program sends a request to a Web service across the network, and, optionally, receives a reply, also in the form of an XML document.

Basics of Web Services Framework • A Web service can be developed on any computer platform and in any development environment, as long as it can communicate with other web services using these common protocols. • Web services standards define the format of the message, specify the interface to which a message is sent, describe conventions for mapping the contents of the message into and out of the programs implementing the service, and define mechanisms to publish and to discover Web services interfaces. • Web services are not a specific technology, but rather a group of established and emerging communication protocols. Following are the basic characteristics of the Web Services framework: • An abstract (vendor-neutral) existence defined by standards organizations and implemented by (proprietary) technology platforms • Core building blocks that include Web services, service descriptions, and messages • A communications agreement centered around service descriptions based on WSDL • A messaging framework comprised of SOAP technology and concepts • A service description registration and discovery architecture realized through UDDI • A well-defined architecture that supports messaging patterns (Request-Response, Fire-and-Forget, Publish-Subscribe .. ) • A messaging framework comprised of SOAP technology and concepts

Basics of Web ServicesWeb Services versus other Distributed Technologies Client Message Protocol Server e.g ATMI Cobol, C … CICS, Tuxedo 1980’sTP Monitor e.g. OCI VB, C++, … DatabaseStored Procedure Early 1990’s Client/Server e.g. IIOP/DCOM Java, C++, VB, … CORBA ORBWindows MTS Mid-1990’s CORBA/COM RMI Java J2EE Container (EJB) Late-1990’s J2EE XML/SOAP Java, VB, C++, Python J2EE ContainerWindows … Early 2000’s Web Services

Basics of Web ServicesWeb Services versus other Distributed Technologies (Cont ..) • CORBA • Basic wire protocol is GIOP, or General Inter-ORB protocol • TCP/IP specialization of GIOP is called IIOP for Internet Inter-ORB protocol. IIOP maps the basic GIOP protocol to TCP/IP • DCOM • Wire protocol is ORPC (Object Remote Procedure Call). ORPC is very DCE RPC-like wire protocol with certain extensions • Java RMI (Remote Method Invocation) • Wire protocol is JRMP (Java Remote Method Protocol) • Web Services • Wire protocol is SOAP (Simple Object Access Protocol). • Unlike other wire protocols, SOAP is built upon open technologies, rather than vendor-specific technologies. • SOAP works out-of-the-box in a wide range of user locations that enable HTTP standard port 80. • Only negative in the case of SOAP is overhead due to XML processing. However, SOAP interoperability mitigates XML processing if you consider the other protocol conversions one must undertake to connect to disparate computer architectures.

Basics of Web ServicesWeb Services versus other Distributed Technologies (Cont ..) • Object Oriented Programming (OOP) based distributed technologies such as DCOM and RMI aren’t intended to link disparate systems and can’t communicate with one another. • CORBA & Web Services are both interface technologies. CORBA is also capable of linking heterogeneous systems just like Web Services. But CORBA mandates that the underlying applications be object oriented. This is because only OO environments can be CORBA compliant. • Web Services, on the other hand, do not enforce this requirement. Underlying implementations in the case of Web Services could be OOP or with procedural or simple scripting languages (such as Perl or PHP), and can communicate with other web services endpoints whether the are object oriented or not.

Basics of Web ServicesWeb Services versus other Distributed Technologies (Cont ..) • Web services, unlike other technologies, is not tightly coupled. With technologies such as CORBA, DCOM, and RMI, the programs at each endpoint must have substantial knowledge of one another. For example, if there is a change in the name of remote program or it’s methods, the invoking program must be modified accordingly. Loosely coupled web services, on the other hand, do not depend on intimate knowledge of the endpoint implementations.

Advanced Web Services • Basic Web services framework is established by the first-generation standards such as WSDL, SOAP, and UDDI. However, the basic web service framework falls short at building enterprise level software systems. Following are few of the umpteenth challenges lie in building enterprise level software systems: • Transactional Integrity: Basic first-generation web services framework does not address agreement on a standardized way to manage complex transactions using web services when they involve multiple disparate systems with different transaction semantics. • Security & Single Signon: Security is one of the missing piece in the basic first-generation web services framework. Building enterprise level software systems require that we develop trust mechanisms that span organizational boundaries and operate with disparate technologies. Standards for authentications, authorization, encryption, and non-repudiation are not addressed in the basic first-generation web services framework. Single Signon is another example of missing piece in order for distributed autonomous services to seamlessly communicate with one another.

Advanced Web Services (Cont ..) • Orchestration and Choreography: One of the premise of web services is that we’ll be able to create adhoc and agile multi-party business processes by stringing together relevant services. In order for this to happen, there is a need for standards that can coordinate or orchestrate complex transactions and choreograph multi-party business processes. Basic first-generation web services framework does not address these capabilities. • Reliable Asynchronous Message Handling: Systems that are both reliable and capable of handling high traffic loads require a robust asynchronous messaging system. The problem with unreliable systems is that messages are sometimes lost due to errors, bottlenecks, or outages etc. The solution to this problem is a system that queues and saves messages until delivery to have occurred. Again, basic first-generation web services standards do not address this capability. • Contracts and Negotiations: A successful web-services strategy must include plans for more than just technology. Before business partners can be linked via web services, there has to be agreement as to the terms and conditions of their relation. Basic first-generation web services standards do not address these capabilities. • and so on ...

WS-* Standards • WS-BPEL (also known as BPEL4WS) • WS-Discovery • WS-Addressing • WS-Trust • WS-Security • WS-SecureConversation • WS-Policy • WS-PolicyAttachment • SAML • XACML/XrML • WS-CDL • WS-Coordination • WS-Topics • WS-Eventing • WS-ReliableMessaging • WS-Federation • WS-Policy • and so on … Advanced Web Services (Cont ..) • Basic Web services standards have been evolved to address all of these shortcomings in order to build enterprise level software systems. Advanced Web services standards are called WS-* extensions. The term “WS-*” has been coined for advanced Web Services standards as majority of the second-generation Web services specifications have been prefixed with “WS-”. Following are few of the second-generation standards:

Anatomy of Service Oriented Architecture

Fundamental SOA • Term “service oriented” is an established and generic theory. It has existed for some time and has been used to address variety of problems. It basically represents a distinct approach for separating concerns whereby logic required to solve a large problem is better constructed, carried out, and managed if it is decomposed into a collection of smaller, related pieces. Each of these pieces addresses a concern or a specific part of the problem. • When coupled with “architecture”, service-orientation takes on a technical connotation. SOA represents software discipline in which automation logic is decomposed into smaller, distinct units of logic. Collectively these units comprise a larger piece of business automation logic. These autonomous units of logic are known as services. • In addition to services, the basic SOA model comprises of two other elements namely: processes, and organizations. Monolithic stovepipe applications are dissolved in favor of self-contained business services, which perform specific business functions.

Fundamental SOA (Cont..) • The main characteristics of business services is that they provide value for the business. Additionally, these services must be coarse-grained as requests for invocation of fine-grained services can lead to network chatter and as a result clogging of the network. • Business processes orchestrate the execution of these business services to fulfill required business functionality such as order processing or claims processing. Business processes are usually associated with operational objectives and business goals such as insurance claims processing etc. Processes have defined triggering (initiation) mechanism for each of new process instance (for example, on arrival of an insurance claim). • Organization owns all of the SOA artifacts such as services and processes. It governs their creation, usage, access, and maintenance. • Although not part of the basic SOA, an extended SOA model incorporates the enterprise semantic data model to the SOA definition.

Fundamental SOA (Cont..) • The enterprise level semantic data model defines the standard business objects for a given enterprise (such as insurance policies and claims). This effectively creates ontology of the enterprise data by defining common concepts describing functioning of the enterprise. This, in turn, leads to the creating of interoperable semantic interface definitions called semantic SOA. • SOA prescribes an approach for modeling business automation logic called services. This approach has resulted in a set of commonly accepted principles applied to each unit of logic that constitutes a service within SOA. • Generally there is a misconception that “an application that uses Web service is service-oriented”. This is not true and is a myth. One needs to go through the whole rigor of applying a set of commonly accepted SOA principles to the Web services components (Web services, descriptions, operations, and messages). Once these SOA principles are applied, the basic Web service components are shaped in support of service-orientation.

Fundamental SOA (Cont..) • Even though there are some SOA principles which require special attention (at the time of analysis & design phases) while building service-oriented solutions using Web services as the underlying technology platform, Web services in general do provide a framework for automatically enforcing majority of the SOA principles. • The underlying synergy of the marriage between SOA and the Web services technology platform makes Web services technology platform as the ideal choice for building SOA based enterprise solutions.

SOA Entities • The “find, bind, and execute” paradigm as depicted in the next slide allows consumer of a service to ask a third-party registry for the service that matches its criteria. If registry has such a service, it gives the consumer a contract and endpoint address for the service. SOA primarily consists of the following entities configured together to support the find, bind, and execute paradigm. • Service Consumer: This entity is an applications, service, or some other type of software module that requires a service. This entity initiates the locating of the service registry, binding to the service over a transport, and executing the service function. The service consumer executes the service by sending it a request formatted according to the contract. • Service Provider: This entity is the service, the network-addressable entity that accepts and executes requests from consumers. • Service Registry: This entity is a network-based directory that contains available services. It accepts and stores contracts from service providers and provides those contracts to interested service consumers. • Service Contract: A contract is a specification of the way a consumer of a service will interact with the provider of the service. The contract may also specify quality of service (QoS) levels. QoS levels are specifications for the non-functional aspects of the service. For instance, a quality of service attribute is the amount of time it takes to execute a service operation.

SOA Entities (Cont..) Service Registry • Service providers deploy and publish services by registering them with the Service broker • Service consumers find services by searching the Service broker's registry of published services • Service consumers bind to the Service provider and consume the available services 3. Find 2. Publish 4. List of Service Providers & Descriptions 6. Request Service Service Consumer 5. Develop application and bind to service Service Provider 1. Develop service, document interface 7. Deliver Service

SOA Entities (Cont..) Web Services Technologies WSDL Points to description UDDI Registry Points to service Finds Service Describes Service Web Service Client (J2EE, .NET …) Web Service (J2EE, .NET,C/C++,Legacy …) SOAP Invokes with XML Messages

SOA Entities (Cont ..) • The service description can be implemented by a number of service providers, each offering various choices of qualities of service (QoS) based on technical requirements in the areas of availability, performance, scalability, and security etc. • The collections of services with various levels of granularity can be combined and choreographed to produce “new” composite services that not only introduce new levels of reuse but also allow the dynamic reconfiguration of business systems.

Common Principles of SOA • Services are reusable: Regardless of whether immediate reuse opportunities exist, services are designed with broad applicability in mind. The published interface must be universal. • Services are loosely coupled: Services must be designed to interact without the need for tight, cross-service dependencies • Services abstract underlying implementation: The only part of a service that is visible to the outside world is what is exposed via the service contract. Underlying logic is invisible and irrelevant to the service requestors • Services are composable: Services may compose other services. This promotes reusability • Services are autonomous: The logic governed by a service resides within an explicit boundary. The service has total control within this boundary and is not dependent on other services for it to execute its governance. • Services are stateless: Services should not be required to manage state information, as that can impede their ability to be loosely coupled. Services should be designed to maximize statelessness even if that means deferring statemanagement elsewhere.

Common Principles of SOA (Cont ..) • Services are discoverable: Services should allow their descriptions to be discovered and understood by humans and service requestors that may be able to make use of their logic. All of these SOA principles relate to, support, or are affected by others. • Service reusability: When a service encapsulates logic that is useful to more than one service requestor, it can be considered reusable. This concept is supported by a number of complementary principles: • Service autonomy establishes an execution environment that facilitates reuse because the service has independence and self-governance. The less dependencies a service has, the broader the applicability of its reusable functionality. • Service statelessness supports reuse because it maximizes the availability of a service and typically promotes a generic service design that defers activity specific processing outside of the service logic boundaries. • Service discoverability promotes reuse, as it allows requestors to search for an discover reusable services. • Service loose coupling establishes an inherent independence that frees a service from immediate ties to others. This makes it a great deal easier to realize reusability.

Common Principles of SOA (Cont ..) • Service loose coupling: Loose coupling is a state that supports a level of independence between services. This concept is supported by a number of complementary principles: • Service reusability is supported through loose coupling because services are freed from tight dependencies on others. This increases their availability for reuse. • Service composition is enabled by the loose coupling of services, especially when services are dynamically composed. • Service statelessness is directly supported through the loosely coupled communications framework. • Service autonomy is made possible through this principle, as it is the nature of loose coupling that minimizes cross-service dependencies. • Service abstraction is what enables loose coupling between services, as the contract is the only piece of information required for services to interact with each other. • Service abstraction: This allows services to encapsulate potentially complex processing logic and exposing that logic through a generic and descriptive interface: • Service loose coupling is directly implemented through the application of service abstraction principle as mentioned before.

Common Principles of SOA (Cont ..) • Service composability: Designing services that they support composition by others is fundamental to building service-oriented solutions. This concept is supported by a number of complementary principles: • Service loose coupling establishes a communications framework that supports the concept of dynamic service composition. This mainly because services are freed from many dependencies, they are more available to be reused via composition. • Service statelessness supports service composability. It enables harmonious composition execution. • Service autonomy held by composition members strengthens the overall composition. • Service autonomy: This principle applies to a service’s underlying logic: • Service reusability is more easily achieved when service offering reusable logic has self-governance over its own logic. • Service composability is also supported through service autonomy. A service composition consisting of autonomous services is much more robust and collectively independent.

Common Principles of SOA (Cont ..) • Service statelessness is best implemented by a service that can execute independently. • Service loose coupling is a primary enabler of service autonomy. • Service statelessness: This principle is indirectly supported by: • Service loose coupling establishes a communication paradigm that is fully realized through messaging. Messaging, in turn, supports service statelessness, as the state information is carried and persisted by the messages that pass through the services. • Service composability benefits from stateless composition members, as they reduce dependencies. • Service reuse becomes more of a reality for stateless services, as availability of the service to multiple requestors is increased and the absence of activity-specific process logic promotes a generic service design. • Service discoverability: This principle is tied closely to the following principles: • Service abstraction extent of a services’ discoverability is typically be associated with the quality or descriptiveness of its service contract. • Service reusability is what requestors are looking for when searching for services and it is what makes a service potentially useful once it has been discovered.

Web Services & SOA Principles • Services are reusable: Web services are not automatically reusable • Services are loosely coupled: Web services are naturally loosely coupled through the use of service descriptions • Services abstract underlying implementation: Web services are automatically emulate the black box model within the Web services communications framework, hiding all the details of their underlying logic • Services are composable: Web services are naturally composable. The extent to which a service can be composed, though, generally is determined by the service design and the reusability of represented logic • Services are autonomous: Autonomy is not automatically provided by Web services framework • Services are stateless: Statelessness is a preferred condition for Web services and is strongly supported by many WS-* specifications and the document-style SOAP messaging model • Services are discoverability: Web services framework does provide basic discoverability mechanism using UDDI directory.

Web Services & SOA Principles (Cont ..) • It turns out that mostly all of the SOA principles except for Reusability & Autonomy are not supported by Web Services framework. This underlines the synergy of the marriage between SOA and the Web services technology platform and gives a good indication as to why Web services have been so successful in realizing SOA. Principles such as reusability & autonomy which are not automatically provided by Web services, they need special attention while building service oriented solutions. Concepts such as service layering in conjunction with service modeling and design provide detail guidelines to this regard.

Service Layering • There are three layers of abstraction defined at the services layer level: • Application service layer: This layer establishes the ground level foundation that exists to express technology-specific functionality. Their purpose is to provide reusable functions related to processing data within new or legacy application environments. • Wrapper services • Utility services • Business service layer: While application services are responsible for representing technology and application logic, the business service layer introduces a service concerned solely with representing business logic. • Entity centric business service • Orchestration service layer: This layer assumes the role of the process part. This layer introduces a parent level of abstraction that alleviates the need for other services to manage interaction details required to ensure that service operations are executed in a specific sequence.

Service Delivery Strategies • There are primarily three strategies as far as transitioning toward a standardized SOA while helping an IT organization to fulfill immediate project-specific requirements. These strategies are based on an organization’s priorities to establish the correct balance between the delivery of long-tem migration goals with versus fulfillment of short-term requirements: • Top-down: This approach requires that SOA be adopted by the enterprise as a whole and requires a lot of preliminary work such as definitions of the enterprise-wide business processes, semantics, and so on. Top-down SOA approach usually starts with building a business model of the enterprise, defining both processes and semantics, and then mapping this model onto business services. This approach to SOA design allows for better alignment of business and application perspectives. Subsequently, it becomes easier to trace the application perspective back to the business perspective, thus simplifying implementation of required changes in the business functionality. This design approach also facilitates separation of the business services—fairly stable processing units—from business processes—fast changing elements of a business model. The changed elements are usually expressed in changes of business rules, governing execution of the business processes, and sequence of service invocations.

Service Delivery Strategies • Bottom-up: The bottom-up approach can originate on the departmental and group level, starting by exposing existing applications as services and building on those services. The bottom-up SOA design approach usually starts from defining integration services, based on the functionality of existing applications and their integration requirements, which lets us service-enable existing applications and create an integration layer. Although the resulting system looks like an SOA implementation, it usually suffers from multiple drawbacks. Services created using this approach are usually tied not to enterprise-wide functionality, but to the existing applications, which can create a tight coupling between the application portfolio and business services that might complicate changes in the application portfolio. Because of significant duplication of functionality in applications, this approach can create a significant amount of services with the same or similar functionality. • Middle Rendezvous: Considering the significant investment that is required for the top-down design approach, the other option is to combine it with the bottom-up SOA design. In this case some of the integration services can be designed and implemented simultaneously with the defining of the enterprise business model and business services. In theory this approach can speed up SOA implementation—by the time business services are designed, some of the integration services will already be in place for the business services to use—but implementation of the integration services has to follow a well-defined process. The meet-in-the-middle approach can see faster results than using the top-down approach, and it is better aligned with long-term goals and values than the bottom-up design. Now let's look at implementation.

SOA support in J2EE Service-Oriented Solutions Servlets Stateless EJBs Web Container EJB Container Belongs to J2EE Platform JAX-RPC Runtime J2EE Class Libraries Java Runtime Different Operating Systems

SOA support in .NET Service-Oriented Solutions ASP.NET WSE Assemblies Belongs to .NET Framework .NET Class Libraries Common language Runtime (CLR) Windows Operating System

SOA Support in Super Platforms • SAP NetWeaver & Oracle Fusion SAP NetWeaver SAP Mobile Interfaces UI Information Integration Business and System Services, App Server Data Plumbing SAP Collaboration SAP Portal SAP KM (Part of Portal) SAP BI SAP Master Data Management SAP Integration Server SAP BPM System SAP J2EE App Server SAP ABAP App Server SAP Data Connectors

SOA Adoption Roadmap & Compliance Levels • Level 1: Initial Services (Developer Sponsorship) • Scope: R&D experimentation, Pilot projects, Portal, Custom integrations, Small number of services • Success Factors: Developers learn service development skills such as Web services standards, & Legacy Integration. • Selected Standards & Technology: XML, XSLT, WSDL, SOAP, Java, .NET • Level 2: Architected Services (CIO Sponsorship) • Scope: Multiple integrated applications • Business Benefits: IT cost reduction and control • Success Factors: Architecture group provides leadership SOA Competency Center by providing support for heterogeneity and distributed systems, Reliable Messaging, Mediation, Ease of deployment, Database integration, Versioning, Internal Security, Performance management. • Selected Standards & Technology: UDDI, WS-ReliableMessaging, WS-Policy, WS-Addressing, XQuery, WS-Security, SAML

SOA Adoption Roadmap & Compliance Levels (Cont ..) • Level 3: Business & Collaborative Services (Business Unit Sponsorship) • Scope: Business processes across business unit, enterprise or cross enterprise • Business Benefits: Business responsiveness • Success Factors: IT Partnership with Business Partnership across Organizations through Reuse, Ease of modification, Availability, Business process rules, Event-driven processes, Composite applications. • Selected Standards & Technology: WS-BPEL, WS-CDL … • Level 4: Measured Services (CFO Sponsorship) • Scope: Business unit or enterprise, Cross-enterprise • Business Benefits: Business transformation from reactive to real-time, Meet business performance metrics • Success Factors: On-going business process evaluation and response through Business Activity Monitoring, Event Stream Processing, Complex Event Processing, Event-driven dashboards and alerts. • Selected Standards & Technology: WS-Eventing, BAM …

SOA Adoption Roadmap & Compliance Levels (Cont ..) • Level 5: Optimized Services (CEO Sponsorship) • Scope: Business unit or enterprise, Cross-enterprise • Business Benefits: Business optimization — react and respond automatically • Success Factors: Continuous improvement culture through event-driven automation for optimization • Selected Standards & Technology: Amalgamation of Event Driven Architecture (EDA) with SOA.

Q & A

Service Oriented Architecture (SOA)