Web Services Inter- Operability

CS409 Application ServicesEven Semester 2007

2

• For two or more application to be involved in the process of data transfer among each other.

• The merger and collaboration of two or more applications’ data, resources, and business logics, to support an automated process.

Motivation

3

Underlying Reasons

• Some sample cases:– Application A needs periodic/regular access to

application B’s database.– Application A needs to borrow some of application B’s

business logic for processing a business function.– Applications A & B need to share a common repository

to avoid storing redundant data.– Application A is collecting data that will be stored in

application B’s database.– etc …

4

Types of Integration

• Extensions to existing application.– When existing system must able to support

new or modified features, access logic in another system, but to avoid redevelopment of existing features.

– Challenge: when the two systems are based on different technology platforms or operating environments.

5

Types of Integration (2)

• New business processes.– When existing system must able to support

corporate mergers, organization restructuring, service expansions, but still need the existing features.

– Challenge: when the new process needs a number of legacy systems to work together, but the legacies were not designed to be integrate-able.

6

Integration Level

• Traditional Integration:– Data level integration.– Application level integration.

• Enterprise Application Integration (EAI):– Process integration.

7

Process

Integration Level (2)

Application

Datatraditional

integration

EAI

Fig 1. Fundamental Integration Levels

8

Integration Level (3)

• Data-Level Integration:– Data sharing only, not involving logic.

• Example: application A have direct access to application B’s database, so none of application B’s logic is involved in this process.

– Data replication from one application’s database to the other.

– Normally work as one-way data transfer and central database models.

9

Integration Level (4)

• Application-Level Integration:– Exchange of data between applications where

each system’s business logics control the flow of data.

– Often occurred because:• Direct data access is not an option (security reason,

unparalleled interfaces, etc).• Data or logic in the targeted application is protected

by layers of business logics.

10

Integration Level (5)

• Process-Level Integration:– Data and/or business logic sharing involves a

new business process.– The new process is called broker or

orchestration process.– The new process doesn’t have its own logic

nor data, but just combining data and logic from the legacies.

11

Role of WS in Integration

• Web services do not provide an integration solution by themselves.

• It is helpful in creating integration layer by exposing legacy systems’ APIs to share data and programming logics via a standardized approach.

• It establishes a platform-independent inter-operability model across various integration architectures.

12

Role of WS in Integration (2)

WebService

Integration

Layer

Middleware

Data

Application A

Middleware

Data

WebService

Integration

Layer

Application B

Fig 2. Integration Layers by Web Services

13

Integration with WS

• Issue: how to maximize the quality of web services that represent external contact points for legacy systems?

• Integration endpoint services (IES): an environment that unifies variety of applications through a set of standardized service interfaces.

14

Integration with WS (2)

WSDLService

A

WSDLService

B

WSDLService

C

WSDLService

D

WSDLService

E

Integration endpoint services

App

licat

ion

AA

pplic

atio

n B

Application C

Fig 3. Integration of Services

15

Designing IES

• Strategies for streamlining IES:– Make more generic interfaces.

• Legacy systems normally were not designed with interoperability, so you need to make it capable.

– Consolidate legacy interfaces.• Combining execution of multiple legacy functions

into one operation call.

– Consolidate proxy interfaces.• Replace proxy service (RPC-style) with business

service (represent collection of processes).

16

Designing IES (2)

• … streamlining IES:– Supplement legacy logic with external logic.

• Only if benefit of quality and performance are high, beware of the amount of cost and effort.

– Add multiple data output format.• Even it is not necessary for current requirements,

but prepare for future integration requirements.

– Alternative interfaces for different clients.• Different access points for different types of clients

into the same application logic.

17

Designing IES (3)

• Strategies for optimizing IES:– Minimize service intermediaries usage.

• Keep it as simple as possible.

– Using service interceptors.• Delegate reusable functions to other services.• Keep it small, do not put business logic within

interceptor.

18

Designing IES (4)

• … optimizing IES:– Delegate data processing activities.

• Direct input/output data validation process to other component.

– Cache WSDL from provider.• Reduce repetitive processing of WSDL every time

the application create a message.• Only recommended for integration connections that

are expected to remain relatively static.

19

Designing IES (5)

• Strategies for integrating legacy systems:– Partial integration layers.

• If time is the constraint, partial integration only can be less disruptive than entire integration layer.

• Be careful! May convoluted the design.

– In-Memory Database (IMDB) data caching.• Cache document-type-definition, XML schema, etc.• Improve overall responsiveness since legacy

systems normally not designed to accommodate “service-oriented application performance”.

20

Designing IES (6)

• … integrating legacy systems:– Adding a queue for scalability demands.

• Legacy systems normally not designed to accommodate “service-oriented application performance”.

• Build a queue to manage overflow requests to the legacy system.

– Adding a mini-hub.• Is the third integration layer that is not attached into the

legacies.• Used to abstract generic functionality for future integration

outside the original boundaries.

21

Designing IES (7)

• … integrating legacy systems:– Abstract legacy’s adapter technology.

• Create utility layer to connect integration layer with legacy’s logic.

• Remove dependencies between vendor’s adapter and the integration layer (in case vendor upgrades the technology, service layer won’t be affected).

– Leverage legacy integration architecture.• To connect two or more group of applications that are already

integrated, preserve the architecture “within” them.• Simply append web service integration layers to the group

level of the applications.

22

Designing IES (8)

• Designing the interface is separate task from the development of the process logic.

• Service interface designer:– Own the WSDL document developers only supply

the implementation code.– In charge of SOAP documents to ensure consistent

message format.– Defines interface standards and naming conventions.– Has a broad outlook for interface extensibility.

23

Interoperability Standards

• Web Services Interoperability Organization:– WS-I Organization, www.ws-i.org– An industry consortium to promote the

adoption of web service technologies.– Founded by 9 companies (MS, IBM, BEA,

SAP, Oracle, HP, et al.), now has more than 150 members.

– Also has associate members that produce other standards (OASIS, RosettaNet, OMG. OAG, etc).

24

Interoperability Standards (2)

• Primary WS-I deliverables:– Sets of profiles.– Sample application based on the profiles.– Test tools to verify the conformance of custom-

built services to the profiles.

25

WS-I Profile

• References to existing set of web services standards and guidance on how to use them.

• The first profile is WS-I Basic Profile 1.0• Conformance targets:

1. SOAP message, WSDL document, and UDDI entries.

2. Service provider, service requestor, and service registry roles.

3. Requirements for message sender and message receiver (can be done by both service provider or requestor).

26

WS-I Profile (2)

• Summary of the most important guidelines:– The only binding supported is SOAP/HTTP

binding.– The only SOAP bindings permitted are document-literal (RPC-encoded binding is not permitted).

– The part element for a message must reference a complex type definition using type attribute.

27

WS-I Profile (3)

• … most important guidelines:– The only message exchange pattern operation

types supported are request-response and one-way.

• Please read “Building Web Services with Java : Making Sense of XML, SOAP, WSDL, and UDDI (2nd Edition)” by Steve Graham, et al page 611 to 647 for complete information about WS-I Basic Profile 1.0

28

WS-I Sample Application

• The purpose is to show how to build inter-operable web services.

• The usage scenario is based on a SCM application that consists of: retailer system, manufacturing system, and demo system.

• The sample has been implemented by some companies and tested by WS-I Sample Application Working Group.

29

WS-I Sample Application (2)

Demo System

ConsumerLoggingService

Retailer System

RetailerService

WarehouseService

WarehouseCallbackService

Manufacturing System

ManufacturerService

Fig 4. WS-I Sample Application Architecture

30

WS-I Sample Application (3)

• Architecture document and download the source code:http://www.ws-i.org/deliverables/workinggroup.aspx?wg=sampleapps

31

WS-I Test Tools

• Provides an easy way to determine if a web service conforms to the requirements of WS-I Basic Profile.

• Test tools are implemented in Java and C#.

• Contains two tools:– The monitor.– The analyzer.

32

The Monitor

• Provides a way to log web service messages using “man-in-the-middle” approach.

• Contains 2 primary functions:– Message interceptor

intercepts messages sent from requestor to provider and vice versa.

– Message loggerformats the intercepted messages into understandable standard formats in message log.

33

The Monitor (2)

• Monitor functions are controlled by a configuration file.– Listen to exact ports for incoming messages

then forward the messages into specific location of the actual destination web services.

• The message sender sees the monitor as if it is the destination web service.

34

The Analyzer

• To determine if a set of web services related artifacts conforms to WS-I Basic Profile requirements by processing a set of test assertions.

• Types of artifacts:– messages

set of messages logged by the monitor.– description

the service description (in WSDL document).– discovery

the UDDI entries for the web service.

35

The Analyzer (2)

• All test assertions are listed in the test assertion document.

• Input for the analyzer:– Location of test assertion document.– References to the web service artifacts.

• Output from the analyzer:– Conformance report

36

The Analyzer (3)

• Possible results in conformance reports:– Passed

the artifact is passed the stated assertion.– Failed

an error was detected when processing the test assertion.

– Warningtest failed, but test type is only “recommended”.

– notApplicablecontext condition did not exist or prerequisite test was failed.

– missingInputthe data was not specified as input or it did not exist in the particular artifact being tested.

Thank You

Doddy Lukitodlukito@infinitechnology.com

dlukito@alumni.carnegiemellon.edu