Web Services Inter- Operability CS 409 Application Services

Web Services Inter- Operability CS 409 Application Services Even Semester 2007

Motivation • 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. 2

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 … 3

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. 4

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 integrateable. 5

Integration Level • Traditional Integration: – Data level integration. – Application level integration. • Enterprise Application Integration (EAI): – Process integration. 6

Integration Level (2) Process Application EAI traditional integration Data Fig 1. Fundamental Integration Levels 7

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. 8

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. 9

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. 10

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 interoperability model across various integration architectures. 11

Role of WS in Integration (2) Middle ware Data Web Service Integration Layer Application A Data Application B Fig 2. Integration Layers by Web Services 12 Middle ware

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. 13

Application B Service A WSDL Service B WSDL Service C WSDL Service D WSDL Service E WSDL Integration endpoint services Fig 3. Integration of Services 14 Application C Application A Integration with WS (2)

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). 15

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. 16

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. 17

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. 18

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”. 19

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. 20

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. 21

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. 22

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, Rosetta. Net, OMG. OAG, etc). 23

Interoperability Standards (2) • Primary WS-I deliverables: – Sets of profiles. – Sample application based on the profiles. – Test tools to verify the conformance of custombuilt services to the profiles. 24

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). 25

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. 26

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 (2 nd Edition)” by Steve Graham, et al page 611 to 647 for complete information about WS-I Basic Profile 1. 0 27

WS-I Sample Application • The purpose is to show to build interoperable 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. 28

WS-I Sample Application (2) Demo System Consumer Retailer System Logging Service Retailer Service Warehouse Service Manufacturing System Warehouse Callback Service Fig 4. WS-I Sample Application Architecture 29 Manufacturer Service

WS-I Sample Application (3) • Architecture document and download the source code: http: //www. wsi. org/deliverables/workinggroup. aspx? wg=s ampleapps 30

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. 31

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 logger formats the intercepted messages into understandable standard formats in message log. 32

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. 33

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. 34

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 35

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. – Warning test failed, but test type is only “recommended”. – not. Applicable context condition did not exist or prerequisite test was failed. – missing. Input the data was not specified as input or it did not exist in the particular artifact being tested. 36

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