3 Service Oriented Architecture What is SOA?Service Oriented ArchitectureServiceSystem capabilities that provide access to functions and data are appropriately exposed to other components (applications, devices, networks, etc.)OrientedUses “open” interoperability protocolsArchitectureIn its purest form, it’s the connection of systems (simple or complex)
4 What Has Slowed True SOA Implementations? Proprietary toolsLack of universally accepted protocolsEnterprise governance less emphasizedLegacy roadblocksResult is StovePipe IntegrationApplicationApplicationApplicationApplicationApplicationApplication
5 What is Different Now?Numerous tools and open standards: Internet, XML, SOAP, UDDI, WSDL, JMS, .NET, etc…General acceptance of standardsArchitecturally integrated Web Services, MOM, and RMI architectures are now more achievableUnprecedented urgency to share data
6 Enterprise Governance being the objective: A Practical StepEnterprise Governance being the objective:Leverage the legacy by decoupling point-to-point relationships and extending services to external requestsMonolithic legacy applications can be become “service providers”Exposing services is more important than howService Orientation is infectious
7 Integration of Services ApplicationBusiness RulesData Transformation RulesApplicationPublishInquireThe integration of services becomes the Service Bus, or what we like to call the Interoperability Hub
8 Walk Then Run Start with simple document-oriented exchanges Enhance through service aggregationPrudently evolve toward document-oriented Publish/Subscribe and Orchestrated relationshipsBusiness Function/Service AggregationTransformation/Routing ServicesOrchestrated Transactions and Event Driven Services
9 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.ApplicationBusiness RulesData Transformation RulesPublishInquire
11 How Services Make Applications Open SOA is a service based architecture that utilizes open, standards-based Web ServicesAll applications can speak XML without requiring proprietary third party productsSOA 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.
12 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 easierExisting services can be quickly combined into new applications, that provide enhanced functionalityThe applications are exposed in a standardized formatIt becomes the “a la carte” of application processes
13 How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementationBy providing loose coupling to application processes, the consumer is not aware of the internal implementation, and therefore is protected from changes by the producer.BusinessTierConsumerProducerData AccessDatabaseAPI
14 How Services Make Applications Open In the past applications were integrated in a tightly coupled fashion which led to a frail implementationBy providing loose coupling to application processes, the consumer is not aware of the internal implementation, and therefore is protected from changes by the producer.DatabaseDatabaseConsumerGeneric ServiceProducerAPIAPIData AccessTierBusinessTierData AccessTier
15 How Services Make Applications Open An agency can quickly adapt to new methods of communicationNew implementations can be added faster and more reliably in a SOA environmentNew customers send messages based on an agreed contract between the producer and consumerThe implementation is independent of the producer which enables multiple views of information without impacting legacy applicationsSecure Business ApplicationsBusiness ApplicationServiceBusiness LogicInterface FacadeProducerXMLCustomizable Presentation TierConsumer?MessageContract
16 How Agencies are Integrating Stovepipe Applications Legacy MainframesToday’s ArchitectureDataDataWorkstationApplication ServersApplication ServersDataWeb ServersData WarehouseData MartsReport ServerData Marts
17 Technologies Used for Integration Message Oriented Middleware MOM (Hub and Spoke)Data WarehousingMartsWarehouseRemote Method Invocations RMIObjectWeb ServicesServiceLegacyXML
18 Roadmap to SOAStart by creating services around existing processes within applicationsApplicationBusiness ProcessDefine current business processes within existing applicationsCreate course grain services that satisfy particular business processesServiceMake these services available to the internal agencyXMLExpose these services to external agencies via an Enterprise Interoperability Hub (Service Bus)
19 Roadmap to SOA Moving from Stovepipes . . . Service XML Business ProcessApplicationServiceXMLApplicationBusiness ProcessApplicationBusiness ProcessServiceXMLMoving from Stovepipes . . .
20 Enterprise Interoperability Hub Roadmap to SOAApplicationApplicationApplicationBusiness ProcessBusiness ProcessBusiness ProcessBusiness ProcessBusiness ProcessBusiness ProcessServiceServiceServiceServiceServiceServiceServiceServiceEnterprise Interoperability HubTransformationTransformationTransformationXMLXMLXMLXMLXMLXMLXMLXMLXMLMoving from Stovepipes To Shared Services
21 Roadmap to SOA Enterprise Interoperability Hub The next step is to provide a view of the agency to external customers via an Enterprise Interoperability HubThe Hub will become the mechanism to represent services to external agencies.SOAP ServiceExternal Agency ServicePortal ServiceEnterprise Interoperability HubRequestNew Application ServiceTransformation/Routing ServicesOrchestrated Transactions and Event Driven ServicesData ServiceMOM Service
22 Roadmap to SOA Today’s Architecture Legacy Mainframes Workstation DataDataWorkstationApplication ServersApplication ServersDataWeb ServersData WarehouseData MartsReport ServerData Marts
26 What Attendees Will Learn Best practices for the implementation of service-oriented architectures (SOA) and web servicesHow to design a roadmap to consolidate and rationalize diverse constituent portals, websites, and web services with a common architecture, security framework, and user interfacePractical suggestions for using resources from legacy systems with newer applications
27 Implementation Best-Practices What is the Use-Case?Plan for reuseTransactionsTuning and Management
28 Plan for ReuseScalabilityReliabilityDeploymentDocumentation
29 Pick the Right Interface Web Services and XML provide best interoperability but not the best performanceWeb Services are not always the right answerMaybe multiple interfaces? (WS, RMI, JMS, MQ, CORBA, etc.)
30 To UDDI or to Not UDDI ? When do you publish your WSDL? UDDI.org The defacto standard –UDDI.orgExcellent source of information and resources regarding UDDI, the specification, and the future of WebServices discovery
31 WebService Management What does it provide?Quality of Service (QoS)Service Level Agreements (SLAs)Registry ServicesWhen to involve the technology?
32 Rationalization Roadmap Service Rationalization or Portal Rationalization?Is there a difference?A portal or portlet does not equal a WebServiceComposite Application or Business Process Rationalization?
33 Service Rationalization Creating a new service contract or API that fronts multiple legacy implementationsEnables service consolidationTerrific path to drastically reducing TCORationalizedServiceService FabricrouteradaptoradaptoradaptorLegacyService ALegacyService BLegacyService C
34 Portal Rationalization Collapsing the web interfaces from multiple systems into a single portal by having each interface be its own portlet within the portal
35 Composite Applications Business Process RationalizationA 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
36 Integrating the Integration Process / Data IntegrationApp ServerHere 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 FabricWebService EnabledBrokerBroker (BEA, WebMethods or Tibco)WebService EnabledWebService EnabledWebService EnabledPeopleSoftWebService EnabledHR System 1HR System 2HR System 3
37 Adapting Legacy System for SOA Fronting with a WebServiceCan be done with one of many technologies - Apache Axis, Systinet, J2EE Servlet containers (Tomcat, JBoss, WebSphere, WebLogic), etcLook to using a WebService Management layerUtilizing a Messaging system (ESB Flavor 1)MQ Series, Tibco, one of many JMS providersUtilizing Traditional EAI connectors (ESB Flavor 2)Vitria, webMethods, SeeBeyond, etc.