LiquidHub Lunch & Learn Demystifying SOA: Concepts & Best Practices

1. LiquidHub Lunch & Learn Demystifying SOA: Concepts & Best Practices Prepared by: Ray Bordogna Partner & Chief Strategy Officer LiquidHub, Inc. Presented: Tuesday, February 26, 2008

2. Executive Briefing Outline • About LiquidHub, Inc. • Section I: • The Business Process • Section II: • The IT Environment • Section III: • SOA Introductory Concepts • Section IV: • SOA Implementation Considerations • Section V: • SOA Proof of Concept (POC)

3. About LiquidHub, Inc. #339 in 2005 List • LiquidHub is a systems integrator & technology consultancy focused on enabling the Agile Enterprise through our Strategy, Applications, Data, and Infrastructure solutions and an engagement lifecycle of planning, execution, and management. • Specific solutions include Enterprise & SOA, Enterprise Integration, Enterprise Portals, Content Management, and scalable Applications and Security Infrastructures. • With offices in Philadelphia, Boston, and Hyderabad, India, our more than 475 associates serve clients in Life Sciences, Financial Services & other key industries globally, at our sites or theirs. • LiquidHub’s Enterprise Services Transformation Roadmap (ESTR) helps organizations plan for technology simplicity and reusability, providing a roadmap to the Agile Enterprise. ESTR provides our clients with a clear process for evaluating business needs, identifying existing technology & process assets, and planning the implementation and integration of new technologies in a way that ensures technology reuse and lower total cost of ownership.

4. The LiquidHub Enterprise Services Architecture (ESA) Framework Enterprise Architecture Enterprise Services Architecture Service Orientation Frameworks (e.g., Zachman) ESTR: (Integrated View) • Services Definition: • Loosely Coupled • - Abstracted • - Platform Independent • Designed & Built for Agility • Articulating • Meaningful to the Service Consumer • Contract-based • Standards-based • Discoverable • Service-Oriented Principles: • Federated • Traceable • Aligned with Business & IT • Evolutionary • Managed • Application Neutral integrates Planning Approaches (e.g., EAP) Enterprise Planning Methodology Reference Models (e.g., TOGAF) Solution Methodology (Project) Governance Models (e.g., TOGAF) ESA Reference Model

5. The LiquidHub Enterprise Architecture Framework Business Strategy What markets do we compete in and how are we different? CAPABILITY 1 Business Architecture What processes support our capabilities? Process 1 Process 6 Process 12 Application (Services) Architecture What applications (services) enable our processes? Service 1 Service 3 Service 6 Service 7 Data Architecture DB 1 What data support our business? DB 12 Infrastructure Architecture What is the foundation of our business? Device 2 Device 13 Business IT Resource Architecture What is our optimal resource allocation? Business IT Financial Architecture What is our optimal investment portfolio? Expense: $XX Capital $YY Development: $XX Maintenance: $YY

6. YourCurrentEnterprise TheAgileEnterprise The LiquidHub Enterprise Services Transformation Roadmap (ESTR) Program Management Plan SDLCMethodologyRefinement Composite ApplicationsOrchestration & Choreography GovernanceModel Business Service Domain Model BusinessSolutionDeliveryRoadmap Business ArchitectureModel BusinessServicesDesign BusinessServicesImplementation ProjectPortfolioManagement BusinessProcessOptimization InformationArchitecture & Taxonomy BusinessProcessModel EnterpriseData Model/Semantic Model MetadataRepositoryDesign Application (SOA) Platforms Federated Data Source and Data Services TechnologyServicesReference Model ApplicationIntegrationPlatforms Blueprint SecurityArchitecture Network ServicesArchitecture NetworkInfrastructureServices ApplicationManagement Services Envision (Strategy and Plan) Engineer (Architect/Design) Execute (Develop/Implement) Phases Program Management Enterprise Business Services Information Management Technology Shared Services WorkStreams

7. Finance Orders Customer The LiquidHub ESA Reference Model (Portfolio of Services) Business Architecture & Business Process Models Enterprise Business Services Business Applications Enterprise Packaged Applications Business Process Services Information Assets Business Services Domain 1 Business Services Domain 2 Technology Shared Services Enterprise Presentation Services Information Services Enterprise Application Services Data Infrastructure Client Services Core Application Services Business Intelligence Personalization Services Business Process Integration Data Access Services Digital Asset Management Enterprise Platforms Integration Platforms Application Platforms Infrastructure Services Development & Deployment Security & Access Management Messaging & Calendaring Mobile, Wireless & Telephony MonitoringServices DirectoryServices Network Backbone & Topology File and Print AccessServices Network Resource Management Routing & Security Architecture Storage Architecture

8. Section I The Business Process

9. An Enterprise can be Viewed as a Collection of Processes An Enterprise Inputs Outputs Resources

10. In fact, the essence of strategy revolves around processes • The business process movement has many parents, but none has been more influential than Michael E. Porter, who has given us the ideas that dominate today's thinking about strategy and the role of processes in achieving competitive advantage. • Competitors, Porter argued, would always try to copy your innovations and "best practices." What they couldn't easily copy was a well integrated Value Chain in which every activity fit together to achieve a well thought out strategy. As Porter explained; "The essence of strategy is choosing to perform activities differently than rivals do.“ • Porter suggests that smart senior executives think in terms of processes. In effect, one strategic goal of the organization should be to create value chains and processes that are unique and that fit together to give the organization a clear competitive advantage that is difficult for rivals to duplicate. Limited Passenger Service Frequent & Reliable Departures Short, Point to Point Routes to 2nd Airports Lean, Productive Ground & Gate Crews Very Low Ticket Prices High Aircraft Utilization Adapted from “What is Strategy,” HBR, Porter 1996

11. Enterprise A Enterprise A* But, what about the capability to Introduce and/or Change processes? How fast? How much $? The ability to implement new processes and change existing processes in a fast, cost-effective manner facilitates competitive advantage and is the essence of ‘agility.’

12. Section II The IT Environment

13. Issue #1: The n(n-1) Integration Complexity • Consider the n(n-1) integration problem. Many organizations face integration problems of some sort; perhaps because of a corporate merger, a new business alliance or just the need to interconnect existing systems. If n application systems must be directly interconnected, the process will produce n(n-1) interfaces. Note that each arrowhead represents an interface. • This set of 5 applications requires 20 interfaces; adding a 6th application would require 10 new interfaces. • And to further increase complexity, one must modify code in each of the existing applications to include the new interfaces, generating substantial testing costs. • To reduce this cost and complexity, a solution that produces the minimum interfaces is required. Application 1 Application 4 (.NET) Application 2 Application 5 (J2EE) Application 3

14. 1 2 Issue #2: Redundant & Non-Reusable Programming Application Portfolio • Over time, many enterprise application portfolios have increased in redundancy due to business combinations and business unit independence. As a result, many organizations deal with redundant applications – or applications with functions that can’t easily be reused. • Commonly, in decentralized organizations, business unit independence hinders any coordinated effort to create reusable functional assets or services. Collectively, this redundancy increases both cost and time to market to deploy new products or services, because changes have to be made in each application or system that is affected. This lack of reuse ultimately requires more resources – and often more time – to deliver new applications. Application 1 Application 2 1 1 2 Application 3 Application 4 1 1

15. Section III SOA Introductory Concepts

16. Service-Oriented Architecture (SOA) is a multi-purpose buzzword A service-oriented architecture is a collection of services that communicate with each other. The services are self-contained and do not depend on the context or state of the other service. They work within a distributed systems architecture. Source: DMReview.com Is it an Enterprise Architecture? In computing, the term Service-Oriented Architecture (SOA) expresses a perspective of software architecture that defines the use of services to support the requirements of software users. In a SOA environment, nodes on a network[1] make resources available to other participants in the network as independent services that the participants access in a standardized way. Most definitions of SOA identify the use of Web services (i.e. using SOAP or REST) in its implementation. However, one can implement SOA using any service-based technology. Source: http://en.wikipedia.org/wiki/Service-oriented_architecture Is it an Application Architecture? SOA is an architectural style whose goal is to achieve loose coupling among interacting software agents. A service is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. Source: XML.com Is it Software Architecture? A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity. Some means of connecting services to each other is needed. Source: service-architecture.com Service-oriented architecture (SOA) is an evolution of distributed computing based on the request/reply design paradigm for synchronous and asynchronous applications. Source: Javaworld.com Is it an Approach? Service-oriented architecture (SOA) is a design methodology aimed at maximizing the reuse of application-neutral services to increase IT adaptability and efficiency. Source: http://dev2dev.bea.com/soa/ SOA refers to the re-engineering of IT systems and development that makes use of reusable chunks of software, aligned to business processes. Source: Diagonal Integrators Is it a Framework? SOA is one of the most popular architectural paradigms today, but without any standardized reference model. It is an architecture that provides seamless Enterprise Information Integration between loosely coupled distributed applications or services over the network. Source: ASP Alliance SOA is an architectural style for building software applications that use services available in a network such as the web. It promotes loose coupling between software components so that they can be reused. Applications in SOA are built based on services. Source: Sun.com Is it a Reference Model?

17. Basic Concept: The Service Definition of a Service: A service is a unit of logic expressed in software that is designed for re-use by other software elements in different execution contexts. Provides service identification, definition of parameters, and conventions concerning passing the service results back to the consumer Service Interface Service Content Service content provides or encapsulates logic such as a business process, a technical feature, a stateless computation, etc…

18. 1 2 3 Fundamental SOA consists of services, descriptions & messages 3 • Services Communicate Through Messaging • Messages are “independent units of communication” which need to be outfitted with enough intelligence to self-govern their parts of processing logic. • Similar to services, messages must be autonomous since after a service sends a message on its way, it loses control of what happens to the message thereafter. Process Step Service Encapsulation service service Service A Service B sub-process Self-governing message PROCESS service Service Composition service description for Service B 1 • Services Encapsulate Logic • In SOA, units of logic are known as services. • To retain their independence, services encapsulate logic within a distinct context. This context can be specific to a business task or some other logical grouping. • The concern addressed by a service can be large or small. Therefore, the size and scope of the logic represented by the service can vary. • A collective is composed of several services. 2 • Services Relate Through Service Descriptions • In SOA, services are aware of each other through the use of service descriptions. • A service description establishes the name of the service and the data expected and returned by the service. • The manner is which services use service descriptions results in a relationship classified as loosely coupled.

19. A service can be a simple business capability: getStockQuote getCustomerAddress checkCreditRating A service can be a complex business transaction: openAccount: verifyCustomerIdentity createCustomerAccount commitInventory sellCoveredOption scheduleDelivery A service can be a system service: logMessageIn authenticateUser This may seem like an artificial distinction of services. The distinction is made to help quantify the level of granularity. Services may be low-level (i.e., fine-grained) or complex high-level (coarse-grained) functions and there are tradeoffs in: Performance Flexibility Maintainability Reuse The level of granularity is a statement of a service’s functional richness. The Nature of a Service Adapted from “Migrating to a Service-Oriented Architecture,” IBM, 2005

20. “Granularity” The term “granularity” is most commonly used to communicate the level of (or absence of) detail associated with some aspect of software program design. Within a service, different forms of granularity exist, all of which can be impacted by how service-orientation design principles are applied. Consolidate Invoices Functional Granularity refers to the potential breadth of the service’s functional scope. For example, “Consolidate Invoices” is a coarse grained service. • Get Invoice • Get Header • Retrieve PO Records • Perform Calculations • View Client History Data Granularity refers to the quantity of data a service needs to exchange in order to carry out its function. There has been a tendency for services implemented as Web Services to exchange document-centric messages – messages containing entire information sets or business documents. A fine-grained service will have less work to do than a coarse grained service. Constraint Granularity refers to the amount of detail with which a particular constraint is expressed. The schema or data model representing the structure of the information being exchanged by a service can define a series of specific validation constraints (data type, data length, data format, allowed values, etc…) for a give value and would represent a fine-grained constraint as opposed to a coarse-grained level of constraint granularity that would permit a range of values with no predefined length or formal restrictions. Adapted from “ SOA: Principles of Service Design,” Erl, 2007

21. These Design Issues Require (Service-Oriented) Principles How should the relationship between services be defined? How should services be designed? Service A Service B Self-governing message service description for Service B How should service descriptions be designed? How should messages be designed?

22. The Service-Orientation Design Paradigm & Principles • a design paradigm is an approach to designing solution logic. • when building distributed solution logic, design approaches revolve around a software engineering theory known as the "separation of concerns” which states that a larger problem is more effectively solved when decomposed into a set of smaller problems or concerns. This gives us the option of partitioning solution logic into capabilities, each designed to solve an individual concern. Related capabilities can be grouped into units of solution logic. • The fundamental benefit to solving problems this way is that a number of the solution logic units can be designed to solve immediate concerns while still remaining agnostic to the greater problem. This provides the constant opportunity for us to reutilize the capabilities within those units to solve other problems as well. • What distinguishes service-orientation is the manner in which it carries out the separation of concerns and how it shapes the individual units of solution logic. Applying service-orientation to a meaningful extent results in solution logic that can be safely classified as "service-oriented" and units that qualify as "services." To understand exactly what that means requires an appreciation of the strategic goals of service-oriented computing combined with knowledge of the following service-orientation design principles: Service Oriented Design Principles: • Standardized Service Contract • Service Loose Coupling • Service Abstraction • Service Reusability • Service Autonomy • Service Statelessness • Service Composability • Service Discoverability Adapted from “ SOA: Principles of Service Design,” Erl, 2007

23. Principle #1: Standardized Service Contract "Services within the same service inventory are in compliance with the same contract design standards."Services express their purpose and capabilities via a service contract. The Standardized Service Contract design principle is perhaps the most fundamental part of service-orientation in that it essentially requires that specific considerations be taken into account when designing a service’s public technical interface and assessing the nature and quantity of content that will be published as part of a service’s official contract. A great deal of emphasis is placed on specific aspects of contract design, including the manner in which services express functionality, how data types and data models are defined, and how policies are asserted and attached. There is a constant focus on ensuring that service contracts are both optimized, appropriately granular, and standardized to ensure that the endpoints established by services are consistent, reliable, and governable. XML Schema WSDL WS Policy <definitions> <types> <message> <parts> <portType> <Policy> <ExactlyOne> <All> assertions… <schema> <element> <complex type> Figure: Using Web service contract documents (WSDL, XML schema, and WS-Policy definitions) as an example, this illustration highlights the areas that are typically affected by the application of this design principle. Adapted from “ SOA: Principles of Service Design,” Erl, 2007

24. Key Concept: The Service Contract Definition: A Service Contract establishes the terms of engagement, providing technical constraints and requirements as well as any semantic information the service owner wishes to make public Service Contract Technical Web Service Contract Historical Context: In the past, technical contracts have commonly been represented by a form of technical interface known as the API. The Interface Definition Language (IDL) and Abstract Syntax Notation (ASN.1) were frequently used to express technical contracts for remote invocation frameworks such as those based on Remote Procedure Calls (RPC). SLA WSDL XML Schema WS Policy Figure: A Web Service can be comprised of the following service description documents: WSDL Definition, XML Schema Definition and WS Policy Description. The term “technical service contract” is used simply to refer to service description documents that are programmatically consumed at runtime. Note that SLAs and other human consumable service description documents can also be part of the service. Web Services: established a non-proprietary distributed communications framework that introduced the Web Services Description Language (WSDL) as the core part of the service contract. The XML schema language is used to define the data model for messages exchanged via Web services and the WS-Policy language facilitates policy assertion definition and attachment to various parts of the WSDL

25. Principle #2: Service Loose Coupling "Service contracts impose low consumer coupling requirements and are themselves decoupled from their surrounding environment." Coupling refers to a connection or relationship between two things. A measure of coupling is comparable to a level of dependency. This principle advocates the creation of a specific type of relationship within and outside of service boundaries, with a constant emphasis on reducing (“loosening”) dependencies between the service contract, its implementation, and its service consumers. The principle of Service Loose Coupling promotes the independent design and evolution of a service’s logic and implementation while still guaranteeing baseline interoperability with consumers that have come to rely on the service’s capabilities. There are numerous types of coupling involved in the design of a service, each of which can impact the content and granularity of its contract. Achieving the appropriate level of coupling requires that practical considerations be balanced against various service design preferences.

26. Principle #3: Service Abstraction Service contracts only contain essential information and information about services is limited to what is published in service contracts.Abstraction ties into many aspects of service-orientation. On a fundamental level, this principle emphasizes the need to hide as much of the underlying details of a service as possible. Doing so directly enables and preserves the previously described loosely coupled relationship. Service Abstraction also plays a significant role in the positioning and design of service compositions. Various forms of meta data come into the picture when assessing appropriate abstraction levels. The extent of abstraction applied can affect service contract granularity and can further influence the ultimate cost and effort of governing the service.

27. Principle #4: Service Reusability Services contain and express agnostic logic and can be positioned as reusable enterprise resources.Reuse is strongly emphasized within service-orientation; so much so, that it becomes a core part of typical service analysis and design processes, and also forms the basis for key service models. The advent of mature, non-proprietary service technology has provided the opportunity to maximize the reuse potential of multi-purpose logic on an unprecedented level. The principle of Service Reusability emphasizes the positioning of services as enterprise resources with agnostic functional contexts. Numerous design considerations are raised to ensure that individual service capabilities are appropriately defined in relation to an agnostic service context, and to guarantee that they can facilitate the necessary reuse requirements.

28. Principle #5: Service Autonomy "Services exercise a high level of control over their underlying runtime execution environment." For services to carry out their capabilities consistently and reliably, their underlying solution logic needs to have a significant degree of control over its environment and resources. The principle of Service Autonomy supports the extent to which other design principles can be effectively realized in real world production environments by fostering design characteristics that increase a service’s reliability and behavioral predictability. This principle raises various issues that pertain to the design of service logic as well as the service’s actual implementation environment. Isolation levels and service normalization considerations are taken into account to achieve a suitable measure of autonomy, especially for reusable services that are frequently shared.

29. Principle #6: Service Statelessness "Services minimize resource consumption by deferring the management of state information when necessary."The management of excessive state information can compromise the availability of a service and undermine its scalability potential. Services are therefore ideally designed to remain stateful only when required. Applying the principle of Service Statelessness requires that measures of realistically attainable statelessness be assessed, based on the adequacy of the surrounding technology architecture to provide state management delegation and deferral options.

30. Principle #7: Service Discoverability "Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted."For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities for reuse present themselves. The service design therefore needs to take the “communications quality” of the service and its individual capabilities into account, regardless of whether a discovery mechanism (such as a service registry) is an immediate part of the environment.

31. Principle #8: Service Composability "Services are effective composition participants, regardless of the size and complexity of the composition." As the sophistication of service-oriented solutions continues to grow, so does the complexity of underlying service composition configurations. The ability to effectively compose services is a critical requirement for achieving some of the most fundamental goals of service-oriented computing. Complex service compositions place demands on service design that need to be anticipated to avoid massive retro-fitting efforts. Services are expected to be capable of participating as effective composition members, regardless of whether they need to be immediately enlisted in a composition. The principle of Service Composability addresses this requirement by ensuring that a variety of considerations are taken into account.

32. Summary of Service-Orientation Principles • Loose Coupling: • Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other • vs. Tight-Coupling: the functionality of each component heavily depends on the functionality implemented by other components. Often such components cannot be used independently of the overall system. That is the design is component-based, but the components are not stand alone. • Service Contract: • Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents • Autonomy: • Services have control over the logic they encapsulate • Abstraction: • Beyond what is described in the service contract, services hide logic from the outside world • Reusability: • Logic is divided into services with the intention of promoting reuse • Statelessness: • Services minimize retaining information specific to an activity • Discoverability: • Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms • Composability: • Collections of services can be coordinated and assembled to form composite services

33. Business Process Layer Services Layer Application Layer Service-Orientation & the Enterprise Business Logic • The collective logic (or processes) that defines and drives the enterprise is an ever-evolving entity constantly changing in response to external & internal influences • From an IT perspective, this enterprise logic can be divided into 2 important halves: business logic and application logic • Business Logic: is structured into processes that express business requirements • Application Logic: is an automated implementation of business logic organized into technology solutions • Services establish an abstraction layer wedged between traditional business & application layers. • Services are developed & deployed in proprietary environments, wherein they are individually responsible for the encapsulation of specific application logic. Application Logic Application A (.NET) Application B (J2EE) Application C (Legacy)

34. Business Processes & Services Business Process “Open account for customer” Presentation – user interface Business Process Orchestration Locate account type Add account to customer Get customer details Business Services Coarse Grained Service Orchestration (Process Orchestration) Locate customer record Check customer status Lookup account type table Retrieve account details Create Customer- Account record Technical Services Fine Grained Adapted from ANZ Banking Group Australia

35. SOA can be implemented without Web services, and Web services can be used for non-SOA (e.g. RPC) interactions. However, Web services delivers key standards for implementing SOA. The WS-* family scales to meet integration challenges intra-enterprise (enterprise application integration [EAI]) and inter-enterprise (business to business [B2B]). XML is an ideal candidate for loosely coupled inter-application data sharing. XML is not self-describing, but XML Schema can be be used to constrain message layout and content. Web services SOA “The architecture” “An Implementation” SOA & Web Services • Services architecture • Service contract • Message based • Service directory • Protocol independent • Coarse grained & document centric • RPC interactions • Binary XML • Web services specs • WSDL • SOAP & XML • UDDI • HTTP • Doc literal binding • Process orchestration (BPEL) Web Services is the stack of standard web technologies required at both consumer and provider ends to implement the pipe for shipping XML messages between them. You don't have SOA until you build/buy services and compose them to implement business functionality.

36. In theory, SOA does not equal Web Services but is there another model? is used to invoke operations defined by SOAP Web Services WSDL is accessed using describes SOA is often discussed in conjunction with Web services, but the 2 are not synonymous. In theory, SOA does not require Web services, and simply implementing Web services does not result in an SOA. However, Web services are the 1st standard for service-oriented computing to gain the near-universal vendor support. By standardizing essential elements of SOA, Web services remove the risk of having to be on a particular technology (e.g., CORBA). serves as a registry for UDDI is accessed using enables discovery of Figure 1. Web Services Model is used to invoke operations defined by ? Enterprise Services ? is accessed using describes serves as a registry for ? is accessed using enables discovery of Figure 2. ? Model

37. 1st and 2nd Generation SOA • 1st generation SOA, mostly inspired by the initial set of web services, defined SOA as an architecture modeled around 3 basic components: • service requester • service provider • service registry 1st generation web services standards: • WSDL described the service • SOAP provided the messaging format • UDDI provided the standardized service registry format 2nd generation SOA added: • WS-* specifications (extension) • WS-BPEL supported the interest in applying service-orientation concepts to the world of business analysis. Service Registry PUBLISH FIND: Discover & retrieve WSDL Service Requestor Service Provider BIND & EXECUTE

38. ContemporaryService Oriented Architecture Reference Model Corporate Network Enterprise Service Bus Business Process Modeling Adapter • Presentation Services • Portal Services • Device Services • Messaging Services • Security Services • Translation Services Workflow Engine In House Apps SOA Repository Adapter SOA App Testing SOA Registry Package Apps • Data Services • Data Federation • ETL • Metadata Management • Data Archiving • Backup & Recovery SOA Governance Adapter Service Broker Collab’n Apps • Infrastructure Services • Identity & Authentication • Message Management • System Management • Security Management • Resilience & Recovery • Provisioning • Federation Services Software Development Modeling Tools Programming Tools App Servers DBMS CM & Lifecycle Tools Testing Tools Adapter SOA Supervisor BI Apps & Services Source: Hurwitz Group, 2006

39. 2 Key Advantages of SOA: easier logic evolution & state management • SOA establishes a loosely-coupled relationship between units of processing encapsulated as services. This allows the logic within each service boundary to be updated and evolved independently of existing service requestors, as long as the original service contract is preserved. • SOA promotes the standardization of XML data representation throughout solution environments. Further, service statelessness is emphasized by deferring state management to the message level. This maximizes reuse, availability and scalability of service logic but also provides a standardized state management approach. Service B Service A logic logic logic Self-governing message service description for Service B

40. Comparing Previous Architectures to Web Services • Compared to Web Services, CORBA solutions: • Are nearly as capable for cross-platform and cross-language development • Are harder to understand because CORBA relies on IDL to translate data • Can handle higher transaction loads because they keep a persistent connection • Compared to Web Services, RMI solutions: • Lock you into a purely Java solution on both the client and server • Can be somewhat more difficult to deploy because of network port considerations • Can handle higher transaction loads because RMI keeps a persistent connection between clients and servers at the expense of servicing fewer clients per server • In a Java-only trusted environment, RMI will perform faster than XML-based Web Services because of the reduced work in getting the data into a wire-friendly format • Compared to Web Services, DCOM solutions: • Are nearly as capable for Microsoft cross-language development but lock you into Microsoft. • Compared to Web Services, CGI solutions: • Are more difficult to find because of no directory service • Are more difficult to write clients for without a well-documented service-specific API to rely on • Are more difficult to interact with because there’s no accepted data interchange format. • Compared to Web Services, Servlet solutions: • Can only be written in Java • Lack a service directory • Lack an interface specification explaining how to communicate with them; no accepted data interchange format

41. Distributed Internet Architecture vs. Service Oriented Architecture

42. Section IV SOA Implementation Considerations

43. Federated Business Collaborative services creating dynamic, collaborative business relationships Business Services Services directly implement business service capability Business Process Improvement Service as a process creates modular units of business process Application Integration Service increases loose coupling and separation of concerns Technical Applications Data integration, client neutrality, shared internal services Where are We? An SOA Maturity Model Adapted from CBDi

44. What’s Our Approach? Top-Down, Bottom-Up, Middle-out, Hybrid? “Top down” and “bottom up” considerations need to be balanced. Business Architecture Governance Executive Business Ownership • Principles • Patterns • Architecture • Skills • Measurement • Management • Rewards Top down Funding Technical Ownership Repository SOA Design and Development Skills Technology Enablers Bottom up Proof of Concepts Select SOA tools Simple Web Services

45. work_stream: Business Services ESTR Guidelines: Tips for Smarter Service Design The coarse- and fine-grained trade-off is a matter of latency and usability. At the end of the day, you should move to a good SOA, exposing the right services that do the right things, and not be as concerned about granularity. Services that implement fine-grained interfaces and that are meant for local invocation will work well. Moreover, services that implement fine-grained interfaces, that are meant for distributed invocation, and that are on a low-latency network will also work well.

46. Common Tangible Benefits of SOA Many of the benefits promised by SOA do not manifest themselves until the use of service-oriented principles becomes established within an enterprise. As a result, there are few short-term benefits • Improved Integration (and intrinsic interoperability) • Because of the vendor-neutral communications framework established by Web Services driven SOA, the potential exists for enterprises to implement highly standardized service descriptions and message structures • State of Federation, where previously isolated environment now can interoperate without requiring expensive and fragile point-to-point solutions • Inherent Reuse • Building services to be inherently reusable results in a moderately increased development effort and requires design standards. • Subsequently leveraging reuse within services lowers the cost and building service-oriented solutions • Streamlined Architectures & Solutions • The concept of composition can lead to highly optimized automation environments: • Assembly of service collections into aggregate services • The WS* platform is based on the principle of composability • Leveraging the Legacy Investment • Industry-wide acceptance of the Web Services technology set has spawned a large adapter market • Best of Breed Alternatives • Because SOA establishes a vendor-neutral communications framework, IT is not longer restricted to a single proprietary development and/or middleware platform • Organizational Agility • How building blocks can be realized and maintained within existing financial and cultural constraints ultimately determines the agility of the organization as a whole

47. Common Pitfalls of Adopting SOA • Building service-oriented architectures like traditional distributed architectures • Problems: • proliferation of RPC-style service descriptions (leading to increased volumes of fine-grained message exchanges) • inhibiting the adoption of features provided by WS-* specifications • Further entrenchment of synchronous communication patterns • Creation of hybrid or non-standardized services • Not creating a transition plan • Migration needs to happen at the technical, process and organization levels to avoid ad-hoc adoption • Not standardizing SOA • Like any other architecture, SOA requires the creation and enforcement of design standards • Failing to create an XML foundation architecture • SOA requires standardizing how core XML technologies are used to represent, validate and process corporate data • Failing to account for SOA performance requirements • As message-based communication increases, processing latency can be an issue • Lack of proper SOA security model • Secure Sockets Layer (SSL) is not the technology of choice for SOA; the need for message-level security implies that the WS-Security Framework is optimal • Failure to understand standards organizations • Web Services Interoperability (WS-I): Basic Profile and Basic Security Profile

48. Performance Issues • Message-based communication in SOAs can, in fact, increase performance requirements when compared to RPC-style communication within traditional distributed architecture • XML processing-related performance challenges • Web services security measures, such as encryption and digital signing, add new layers of processing to both the senders and recipients of messages • Need to test the message processing capabilities of your environments • Stress testing the vendor supplied processors (for XML, XSLT, SOAP, etc..) • Considering alternative processors, accelerators or other types of technology: • XML-binary Optimized Packaging (XOP) • SOA Message Transmission Optimization Mechanism (MTOM) • Performance is one of the reasons why: • Coarse-grained service interfaces and asynchronous messaging are emphasized when building Web Services

49. Management & Operations • Account • Reconciliation • Reconcile Checks • Reconcile Client Accounts • Reconcile Transfer Agency Accounts • Reconcile Custody Bank Accounts • Reconcile Omnibus Accounts • Compliance • Monitor Investment Compliance • Monitor Client Compliance • Audit Dividend & Capital Gain Disbursements • Client Control Reporting • Process As-of Transactions • Provide Tax Services • Money Movement • Move Money • Inventory Management • Manage Literature Inventory • Fulfill Literature Requests • Financial Management • Perform Corporate Budgeting • Provide Executive Information • Execute Monthly/Yearly Financials • Perform AP/AR • Issue Payroll • Track Assets • Prepare Compliance Reporting • Human • Resources • Hire/Retain/Release Employees • Provide Career Management • Provide Work/Life Initiatives • Prepare Compliance Reporting Best Practice: Create a Services Blueprint for Transformation Partner & Supplier Interaction Fund Accounting RecordKeeping Advisory Services Customer Relationship Management Channels Customer Segments • Financial Planning • Create Financial Plan • Manage Financial Plan • Cash Management • Manage Cash • Process Information Requests • Generate Reports • Generate Statements • Generate Confirm/ Notifications • Marketing • Analyze/Understand Client • Perform Market Research/Analysis • Create/Modify Products/Services • Educate Client • Prepare Communications Brokers Account Management Retirement Client Kiosk/POS • Pricing • Price/Value Investments • Correct Pricing Error • Manage Accounts • Setup/Maintain Person • Setup/Maintain Account • Setup/Maintain DC/DB Plan • Setup/Maintain Trust • Prepare Client Transactions • Prepare Purchase • Prepare Redemption • Prepare Exchange • Prepare Buy • Prepare Sell • Exercise Options • Prepare Contribution • Prepare Withdrawal • Prepare Rollover • Perform Adjustments • Administer Installment Setup • Administer Annuitization Setup • Administer Loan • Prepare Asset/ Account Transfer • PreparePlanLevelTransfer • Prepare 1035 Exchange • Terminate Person • Prepare Death Claim • Process Client Transactions • Manage Assets • Manage Account Balance • Administer Installment Payment • Rebalance Assets • Calculate Benefits • Convert New Plan • Bill Fees • Process Credit/Margin • Calculate Annuity Payments • Administer Annuitization Payment • Manage Loans • Manage Trust Assets • Manage Trust Income & Disbursements • Process Corporate Actions • Withhold Taxes • Purge/Archive Records • Manage Client Payments • Prepare Excess Refund • Prepare Pass-Through Dividend • Manage Brokerage Orders • Securities Accounting • Conduct Securities Lending • Perform Clearing & Settlement Call Center/IVR Brokerage Client • Manage Information Requests • Provide Information • Provide Personalized Performance Data • Customer Service • Call Center Services • Customer Lifecycle • Customer Segment Management Trust Accounting Analysis & Product Development Web Endowment Client • Performance Analysis • Product/Service Success Analytics Investment Management • Sales Force Automation • Campaign Management • Contact Management • Sales Goal Performance Management/Dashboard • Investment Strategies Management • Manage Portfolios • Replicate Indexes • Manage Order Routing and Execution • Monitor Performance Client • Service Development • R&D • Product Lifecycle Trust Client External Advisors Mobile Defined Contribution Client Fax Transaction Clearing-houses Defined Benefit Client Paper

50. Finance Orders Customer Best Practice: Create an ESA Reference Model Business Architecture & Business Process Models Enterprise Business Services Business Applications Enterprise Packaged Applications Business Process Services Information Assets Business Services Domain 1 Business Services Domain 2 Technology Shared Services Enterprise Presentation Services Information Services Enterprise Application Services Data Infrastructure Client Services Core Application Services Business Intelligence Personalization Services Business Process Integration Data Access Services Digital Asset Management Enterprise Platforms Integration Platforms Application Platforms Infrastructure Services Development & Deployment Security & Access Management Messaging & Calendaring Mobile, Wireless & Telephony MonitoringServices DirectoryServices Network Backbone & Topology File and Print AccessServices Network Resource Management Routing & Security Architecture Storage Architecture