Best Practices for Adopting SOA

SOA Overview

Service Oriented Architecture What is SOA? Service Oriented Architecture Service System capabilities that provide access to functions and data are appropriately exposed to other components (applications, devices, networks, etc.) Oriented Uses “open” interoperability protocols Architecture In its purest form, it’s the connection of systems (simple or complex)

What Has Slowed True SOA Implementations? Proprietary tools Lack of universally accepted protocols Enterprise governance less emphasized Legacy roadblocks Result is StovePipe Integration Application Application Application Application Application Application

What is Different Now? Numerous tools and open standards: Internet, XML, SOAP, UDDI, WSDL, JMS, .NET, etc… General acceptance of standards Architecturally integrated Web Services, MOM, and RMI architectures are now more achievable Unprecedented urgency to share data

Enterprise Governance being the objective: A Practical Step Enterprise Governance being the objective: Leverage the legacy by decoupling point-to-point relationships and extending services to external requests Monolithic legacy applications can be become “service providers” Exposing services is more important than how Service Orientation is infectious

Integration of Services Application Business Rules Data Transformation Rules Application Publish Inquire The integration of services becomes the Service Bus, or what we like to call the Interoperability Hub

Walk Then Run Start with simple document-oriented exchanges Enhance through service aggregation Prudently evolve toward document-oriented Publish/Subscribe and Orchestrated relationships Business Function/Service Aggregation Transformation/Routing Services Orchestrated Transactions and Event Driven Services

SOA Opens the Architecture As external services development spreads and matures within an environment, the legacy application components become “open.” - and therefore - New application development will begin to be based more on the integration of services, rather than linking of components and databases. Application Business Rules Data Transformation Rules Publish Inquire

Troy Holmes Implementing SOA

How Services Make Applications Open SOA is a service based architecture that utilizes open, standards-based Web Services All applications can speak XML without requiring proprietary third party products SOA breaks down the walls of conventional software design, by enabling reuse of existing applications. SOA can be used to encapsulate legacy business logic and provide functionality to a larger user base.

How Services Make Applications Open By wrapping services with SOA, agencies will be building the groundwork for information sharing throughout the government. Building new solutions for agencies becomes faster and easier Existing services can be quickly combined into new applications, that provide enhanced functionality The applications are exposed in a standardized format It becomes the “a la carte” of application processes

How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementation By providing loose coupling to application processes, the consumer is not aware of the internal implementation, and therefore is protected from changes by the producer. Business Tier Consumer Producer Data Access Database API

How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementation By providing loose coupling to application processes, the consumer is not aware of the internal implementation, and therefore is protected from changes by the producer. Database Database Consumer Generic Service Producer API API Data Access Tier Business Tier Data Access Tier

How Services Make Applications Open An agency can quickly adapt to new methods of communication New implementations can be added faster and more reliably in a SOA environment New customers send messages based on an agreed contract between the producer and consumer The implementation is independent of the producer which enables multiple views of information without impacting legacy applications Secure Business Applications Business Application Service Business Logic Interface Facade Producer XML Customizable Presentation Tier Consumer ? Message Contract

How Agencies are Integrating Stovepipe Applications Legacy Mainframes Today’s Architecture Data Data Workstation Application Servers Application Servers Data Web Servers Data Warehouse Data Marts Report Server Data Marts

Technologies Used for Integration Message Oriented Middleware MOM (Hub and Spoke) Data Warehousing Marts Warehouse Remote Method Invocations RMI Object Web Services Service Legacy XML

Roadmap to SOA Start by creating services around existing processes within applications Application Business Process Define current business processes within existing applications Create course grain services that satisfy particular business processes Service Make these services available to the internal agency XML Expose these services to external agencies via an Enterprise Interoperability Hub (Service Bus)

Roadmap to SOA Moving from Stovepipes . . . Service XML Business Process Application Service XML Application Business Process Application Business Process Service XML Moving from Stovepipes . . .

Enterprise Interoperability Hub Roadmap to SOA Application Application Application Business Process Business Process Business Process Business Process Business Process Business Process Service Service Service Service Service Service Service Service Enterprise Interoperability Hub Transformation Transformation Transformation XML XML XML XML XML XML XML XML XML Moving from Stovepipes . . . To Shared Services

Roadmap to SOA Enterprise Interoperability Hub The next step is to provide a view of the agency to external customers via an Enterprise Interoperability Hub The Hub will become the mechanism to represent services to external agencies. SOAP Service External Agency Service Portal Service Enterprise Interoperability Hub Request New Application Service Transformation/Routing Services Orchestrated Transactions and Event Driven Services Data Service MOM Service

Roadmap to SOA Today’s Architecture Legacy Mainframes Workstation Data Data Workstation Application Servers Application Servers Data Web Servers Data Warehouse Data Marts Report Server Data Marts

Enterprise Interoperability Hub (Service Bus) Roadmap to SOA Data Data Marts Data Warehouse Exposed Service Future Architecture Legacy Mainframes Enterprise Interoperability Hub (Service Bus) Workstation Application Servers Application Servers Web Servers Report Server

Enterprise Interoperability Hub (Service Bus) Roadmap to SOA Data Data Marts Data Warehouse Exposed Service Future Architecture Legacy Mainframes Enterprise Interoperability Hub (Service Bus) Workstation Application Servers Application Servers Web Servers Report Server

Jeff Simpson SOA Best Practices

What Attendees Will Learn Best practices for the implementation of service-oriented architectures (SOA) and web services How to design a roadmap to consolidate and rationalize diverse constituent portals, websites, and web services with a common architecture, security framework, and user interface Practical suggestions for using resources from legacy systems with newer applications

Implementation Best-Practices What is the Use-Case? Plan for reuse Transactions Tuning and Management

Plan for Reuse Scalability Reliability Deployment Documentation

Pick the Right Interface Web Services and XML provide best interoperability but not the best performance Web Services are not always the right answer Maybe multiple interfaces? (WS, RMI, JMS, MQ, CORBA, etc.)

To UDDI or to Not UDDI ? When do you publish your WSDL? UDDI.org The defacto standard – email UDDI.org Excellent source of information and resources regarding UDDI, the specification, and the future of WebServices discovery

WebService Management What does it provide? Quality of Service (QoS) Service Level Agreements (SLAs) Registry Services When to involve the technology?

Rationalization Roadmap Service Rationalization or Portal Rationalization? Is there a difference? A portal or portlet does not equal a WebService Composite Application or Business Process Rationalization?

Service Rationalization Creating a new service contract or API that fronts multiple legacy implementations Enables service consolidation Terrific path to drastically reducing TCO Rationalized Service Service Fabric router adaptor adaptor adaptor Legacy Service A Legacy Service B Legacy Service C

Portal Rationalization Collapsing the web interfaces from multiple systems into a single portal by having each interface be its own portlet within the portal

Composite Applications Business Process Rationalization A combination of Service and Portal Rationalization where, through a workflow engine, we create a new composite application and new interface that leverages existing IT assets in a new unified business process

Integrating the Integration Process / Data Integration App Server Here is the initial state: Three HR Systems that are web service enabled and then included in the SOA Fabric. But … these HR systems are aging and the system requirements are ageing … their days are numbered. In order to get the required functionality, management has selected PeopleSoft as the target platform. As a Pilot only HR System 3 will be integrated into the PeopleSoft system. This integration will be done as a function of migrating to the PeopleSoft system. SOA Fabric WebService Enabled Broker Broker (BEA, WebMethods or Tibco) WebService Enabled WebService Enabled WebService Enabled PeopleSoft WebService Enabled HR System 1 HR System 2 HR System 3

Adapting Legacy System for SOA Fronting with a WebService Can be done with one of many technologies - Apache Axis, Systinet, J2EE Servlet containers (Tomcat, JBoss, WebSphere, WebLogic), etc Look to using a WebService Management layer Utilizing a Messaging system (ESB Flavor 1) MQ Series, Tibco, one of many JMS providers Utilizing Traditional EAI connectors (ESB Flavor 2) Vitria, webMethods, SeeBeyond, etc.