Web Service Integration
39
Web Service Integration CS409 Application Services Even Semester 2007 with Legacy System and Enterprise System
description
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. - PowerPoint PPT Presentation
Transcript of Web Service Integration
Web Service Integration
CS409 Application ServicesEven Semester 2007
with Legacy System and Enterprise System
2
• Definition of “legacy” for SOA:– Systems that preceded the distributed
computing platform.– Integration solutions that are using proprietary
remoting technologies.
What is Legacy System?
Important Aspects for Integration
a. Service models.
b. Integration components.
c. Integration models.– a, b, and c are important for integration with
both, legacy and enterprise system.
3
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) intermediary
only 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
IntegrationLayer
Middleware
DB
Application A
Middleware
DB
BusinessService
Application B
Fig 1. Batch Export-Import by Web Services
Adapter
Queue
Adapter
IntegrationLayer
SOAPwith
attachment
15
Direct Data Access
Wrapperservice
IntegrationLayer
Middleware
DB
Application A
Middleware
DB
BusinessService
Application B
Fig 2. Direct data access by Web Services
Adapter
IntegrationLayer
SOAP
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
IntegrationLayer
Middleware
DB
Application A
Middleware
DB
WrapperService
Application B
Fig 3. Homogenous Integration by Web Services
Adapter Adapter
IntegrationLayer
SOAP
18
Heterogeneous Systems Integration
Wrapperservice
IntegrationLayer
Middleware
DB
Application A
Middleware
DB
BusinessService
Application B
Fig 4. Heterogeneous Integration by Web Services
Adapter Adapter
IntegrationLayer
SOAP
Middleware
DB
Application C
Adapter
19
Component-Based Integration
Proxyservice
IntegrationLayer
Component
DB
Application A
ProxyService
Application B
Fig 5. Component-Based Integration by Web Services
IntegrationLayer
SOAP
Component
Component
Component
Proxyservice
SOAP
ProxyService
Component
DB
Component
Component
Component
SOAP
Platform 1Platform 1
orPlatform 2
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
Centralized-Database Integration
Wrapperservice
IntegrationLayerDB
Application A
WrapperService
Database Application
Fig 6. Centralized-Database Integration by Web Services
IntegrationLayer
Middleware
SharedDB
Adapter
Businessservice
IntegrationLayerDB
Application B
Component
ComponentCompo
nent
SOAP
SOAP
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:1. Retrieve requested data from source database.
2. Validate source data using source schema.
3. Broker the data format.
4. Validate target data using target schema.
5. 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:1.Request data from orchestration (not from any specific
application).2.Request data from application.3.Return response to orchestration (not to any specific
application).4.Process orchestration logic.5.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
