1 / 39

Web Service Integration

Web Service Integration. with Legacy System and Enterprise System. CS409 Application Services. Even Semester 2007. What is Legacy System?. Definition of “legacy” for SOA: Systems that preceded the distributed computing platform.

liliha
Download Presentation

Web Service Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Web Service Integration with Legacy System and Enterprise System CS409 Application Services Even Semester 2007

  2. What is Legacy System? • Definition of “legacy” for SOA: • Systems that preceded the distributed computing platform. • Integration solutions that are using proprietary remoting technologies.

  3. Important Aspects for Integration • Service models. • Integration components. • Integration models. • a, b, and c are important for integration with both, legacy and enterprise system.

  4. Service Models for Legacy Integration • Proxy services. • Add an extra layer of processing on the side of legacy component. • Wrapper (adapter) services. • Expose specific parts of legacy by creating service interface. • Coordination services. • Manage context within service activity.

  5. Proxy Services • Simplest integration service. • Can be auto-generated by most IDEs, mirroring the interfaces of existing legacy components (low scalability). • Low to medium usage volume, performance not optimized for web service due to the addition of an extra layer. • RPC-centric message type. • Resides with its corresponding legacy’s component in its native environment.

  6. Wrapper Services • Expose specific legacy’s functionalities through the creation of adapters within context of choice. • Custom-developed, provide generic interfaces for a subset of legacy’s functionalities (medium scalability). • Low to medium usage volume, for high usage needs additional business logic. • RPC-centric or document-centric message type. • Can be resided in the legacy’s or service’s environment (depends on the connector technology required by the legacy).

  7. Coordination Services • Implementation of service model in WS-Coordination specification. Consists of: context creation, registration for context coordination, and protocol selection. • Developed following WS-Coordination specification, but also extendable (very scalable). • Medium to high usage volume, support atomic transactions and business activities. • Document-centric message type. • Normally deployed with the service it is represented, but also possible for central deployment if involved large participants.

  8. Integration Components for Legacy Integration • Adapter. • Piece of software to facilitate connections between applications or their components, to bridge technology gaps or incompatible platforms. • Intermediary. • Forwarder of messages between provider and requestor (client). • Interceptor. • Agent that able to pre-process messages prior forwarding it to the next destination (you can call it advanced intermediary).

  9. Adapter • Mostly are proprietary technologies provided by vendors (some adapters are serving similar operations, thus functionality overlapping). • Achieve inter-operability by: • Exposing programmatic interface of the legacies (in form of APIs). • Translating data formats. • Translating communication protocols. • Example: connectors, gateways, etc.

  10. Intermediary • Existed because WS standard supports multi-service message path. • Types of intermediary: • Forwarding (passive) intermediaryonly relay the message to next intermediary or the ultimate receiver. • Active intermediaryprocess the message before forwarding it, but only allowed to modify the SOAP header part. • Should comply with WS-Routing and WS-Referral specifications.

  11. Interceptor • Intercept and process messages somewhere along message path. • Example of process: security check, data validation, message compression, etc. • The main objective is to improve system-wide overall processing performance (reduce the load for the actual service provider). • It is not a web service, because the logic is not exposed by the service interface and it is not encapsulating any business operation related to the web service.

  12. Integration Modelsfor Legacy Integration • One-way integration architecture. • Point-to-point architecture. • Centralized database architecture.

  13. One-Way Architecture • Simple in design, inexpensive to implement, with minimal impacts. • Common variations: • Batch export and import. • Direct data access.

  14. Batch Export and Import Wrapperservice Business Service Adapter Adapter Middle ware Middle ware SOAPwithattachment DB DB Queue IntegrationLayer IntegrationLayer Application B Application A Fig 1. Batch Export-Import by Web Services

  15. Direct Data Access Business Service Adapter Middle ware Middle ware Wrapperservice SOAP DB DB IntegrationLayer IntegrationLayer Application B Application A Fig 2. Direct data access by Web Services

  16. Point-to-Point Architecture • Establishes integration level with control for delivery and processing of data. • Common variations of integrations: • Between homogenous systems. • Between heterogeneous systems. • Between homogenous component-based systems. • Between heterogeneous component-based systems.

  17. Homogenous Systems Integration Wrapperservice Wrapper Service Adapter Adapter Middle ware Middle ware SOAP DB DB IntegrationLayer IntegrationLayer Application B Application A Fig 3. Homogenous Integration by Web Services

  18. Heterogeneous Systems Integration Application B Wrapperservice Business Service Adapter Adapter Middle ware Middle ware SOAP DB DB Adapter Middle ware IntegrationLayer IntegrationLayer DB Application A Application C Fig 4. Heterogeneous Integration by Web Services

  19. Component-Based Integration Proxyservice Proxy Service Component Component Component Component SOAP Proxyservice Proxy Service SOAP Component Component Component Component SOAP IntegrationLayer IntegrationLayer DB DB Platform 1orPlatform 2 Platform 1 Application B Application A Fig 5. Component-Based Integration by Web Services

  20. Centralized Database Architecture • A single database with generic data model to support multiple applications. • The database acts as common repository for two or more applications. • Positive side: establishes a generic data access layer to remove the dependency on database platforms and core-system, reducing data redundancy. • Negative side: performance bottleneck, database design complexity.

  21. SOAP SOAP Centralized-Database Integration Application A Wrapperservice Wrapper Service Shared DB Adapter Middleware DB IntegrationLayer Component Businessservice IntegrationLayer Component Component IntegrationLayer DB Database Application Application B Fig 6. Centralized-Database Integration by Web Services

  22. Strategy for Legacy System Integration • Step by step feasibility analysis in XWIF process: • Define business requirements and expectations. • What you’re actually trying to accomplish. • Assess adapter quality • Do you need adapter to enable connectivity? How’s the design of it? Who’s the vendor supporting it? • Analyze adapter functionality • Features, performance, and security.

  23. Strategy for Legacy System Integration (2) • … step by step … • Evaluate development tool • Estimate usage requirements • What is the potential concurrency? Beware about the processing performance. • Identify extend-ability possibilities • Any other types of system that may need it in the future? • Define testing strategy • Unit test, integration test, regression test, performance test.

  24. Strategy for Legacy System Integration (3) • … step by step … • Gather required skill sets • Programmers, web service designer, interface designer, adapter specialist, etc. • Estimate the overall impact. • How long does it take for deployment, configuration and setting, testing? • How will it affect the service level, user training, maintenance processes. • Costing • Adapter license, IDE, human resources, hosting, hardware upgrade.

  25. Strategy for Legacy System Integration (4) • … step by step … • Consider the alternatives. • Do you really have to upgrade to SOA? How about just expanding the legacy’s functionalities? • Choose the right integration path. • Justify the project!

  26. Service Models for Enterprise Integration • Process services. • BPEL4WS specification. • Coordination services. • WS-Coordination and WS-Transaction specifications.

  27. Process Services • High to very high usage volume. • The WSDL for BPEL4WS is little different than regular Web Service. The service definition provides no binding information so it can remain implementation-independent. • Document-centric message type. • Deployed within the orchestration engine.

  28. Coordination Services • Low to high usage volume (low if business activities, high if atomic transaction). • The design is conformed with WS-Coordination specification, but also extensible. • Document-centric message type. • Normally deployed within the EAI server environment.

  29. Integration Components for Enterprise Integration • Broker. • Unit that accept non-business-process function delegation. • The main objective is to ensure that data received in the destination is always in the expected format by the receiver. • Orchestration engine. • Used to encapsulate and execute business process logic

  30. Broker • Able to perform activities such as: • Data transformations, data merging and formatting, etc. • Processes of data exchange using broker: • Retrieve requested data from source database. • Validate source data using source schema. • Broker the data format. • Validate target data using target schema. • Insert data into target database.

  31. Orchestration Engine • Able to perform activities such as: • Integrate with other system to retrieve additional data, invoke the broker component to validate data, reject the data if the validation fails. • Processes of data exchange using orchestration engine: • Request data from orchestration (not from any specific application). • Request data from application. • Return response to orchestration (not to any specific application). • Process orchestration logic. • Forward data to requesting application.

  32. Integration Modelsfor Enterprise Integration • Hub and Spoke. • Messaging Bus. • Enterprise Service Bus.

  33. Hub and Spoke • Centralized processing through a hub. • Centrally located server hosts the integration logic to control the orchestration of inter-application communications. • The integrated applications will create point-to-point connections with the hub itself. • Availability of integration layer in client application is undesirable as this integration channel can’t be maintained and administered from the same central “hub” location.

  34. Hub and Spoke (2) Fig 7. Hub and Spoke Architecture by Web Services

  35. Messaging Bus • Introduces an information pipeline for incoming and outgoing messages. • Applications are assigned the role of publisher or subscriber. • Web service integration layer establishes standard communication layer. • The integration layer can also reduce the load of messaging bus server if it is designed to incorporate intelligent adapter.

  36. Messaging Bus (2) Fig 8. Messaging Bus Architecture by Web Services

  37. Enterprise Service Bus • Is a pure implementation of service oriented principles in the enterprise environment. • Every components of it exist as Web Service, support plug-and-play of services for exchanging or upgrading as we like.

  38. Enterprise Service Bus (2) Fig 9. Enterprise Service Bus Architecture by Web Services

  39. Thank You Doddy Lukito dlukito@infinitechnology.com dlukito@alumni.carnegiemellon.edu

More Related