Grenoble Ecole de Management MEDFORIST Workshop B2B Interoperability: Web Services Approach

1. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 1 Grenoble Ecole de ManagementMEDFORIST WorkshopB2B Interoperability: Web Services Approach Asuman Dogac Middle East Technical University Software R&D Center Ankara, Türkiye

2. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 2/89 What B2B integration involves?

3. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 3/89 Challenge of Application Integration

4. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 4/89 What B2B integration involves? The message formats exchanged (e.g. a Purchase Order) Business Vocabulary (e.g., product names, numbers, etc.) The sequencing of messages (e.g. after sending a purchase order message, an Purchase Order Acknowledgement message must be received)

5. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 5/89 What B2B integration involves? The public business process (e.g. after a purchase order is accepted, the an invoice must be sent) The network protocol and the transport binding (Internet (http, ftp, etc.) or VAN) The security to be provided (like encryption, non-repudiation)

6. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 6/89 Why do we need integration standards? A proprietary solution means that a company has to to deal with several such solutions, one for each of its trading partners Complying with a B2B interoperability standard means that the company needs only one solution to deal with all the companies complying with that standard

7. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 7/89 The major B2B Integration Standards EDI Web Services RosettaNet ebXML

8. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 8/89 Web Services is a new model for using the Web to: Automatically initiate processes via the Web using programs Method for describing, publishing & initiating processes dynamically in a distributed environment Not necessarily using a Web browser Actually, the Web is not required? The content- oriented Web is now complimented by the service-oriented Web

9. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 9/89 Web Services If you can imagine a way of electronically delivering something Of value to a customer That will solve a problem, or Provide some usefulness Then you have a viable example of a Web service

10. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 10/89 Some Use Examples A service to accept purchase orders (B2B) A service for completing tax forms (B2C) An insurance policy service to insure the products being shipped A financing service to ensure payment according to vendor terms A health-care service to access health-care records

11. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 11/89 Web Services Web services encapsulate business functions Check credit card number Payment processing Stock quotes Request for quote, bid processes They can be used to compose business processes Travel planning Health care …

12. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 12/89 What is a Web Service?

13. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 13/89 Benefits of a Web service Includes: Decoupling of service interfaces from the implementation Enabling dynamic service binding Providing interoperability among different platforms

14. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 14/89 These Benefits Derive From: XML based standards: Simple Object Access Protocol (SOAP) Web Services Description Language (WSDL) HTML == user-to-machine XML/SOAP == machine-to-machine

15. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 15/89 Web Services

16. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 16/89 Web Services A Business function made available via Internet by a service provider, and accessible by clients that could be human users or software applications World Wide Web Consortium’s Web service definition: A software application: Identified by a URI Its interfaces and binding are capable of being defined, described and discovered by XML artifacts and Supports direct interactions with other software applications Using XML based messages via Internet-based protocols

17. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 17/89 Web Services The Web Services Reference Model Service Provider Service Registry Service Consumer Major Standards WSDL (Web Services Description Language) SOAP (Simple Object Access Protocol) UDDI (Universal Description, Discovery and Integration) registries ebXML (Electronic Business XML)

18. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 18/89 Why Web Services? For B2B interactions, applications need to talk to each other on the Web: Interoperability is needed A change in an application should not effect the apps it is talking to Web services provide these through WSDL and SOAP However, the current practice of generating WSDL from the code is incorrect because when the code changes so does the WSDL Yet WSDL is your established public contract with the outside world

19. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 19/89 Web Services Realities Web services are not very efficient Dynamic discovery is essential Web services infrastructure is easy What is difficult is defining domain specific ontologies for service discovery

20. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 20/89 WS-Security Microsoft and IBM partnership Enhancement of SOAP messages to provide Message integrity Message confidentiality Message authentication

21. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 21/89 Security Properties

22. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 22/89 Web Service Model

23. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 23/89 Web Service Description

24. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 24/89 WSDL Structure

25. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 25/89 Web Services Description Language

26. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 26/89 XML Messaging: SOAP The current standard for XML Messaging is Simple Object Access protocol (SOAP) Applications typically communicate with Web services via SOAP messaging Typically HTTP is used as RPC transport XML is used as RPC encoding scheme

27. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 27/89 Why SOAP? There are a number of wire protocols for RPC Internet Inter ORB Protocol for Common Object Request Broker Architecture (CORBA) Java Remote Method Protocol (JRMP) for Java Remote Method Invocation (RMI) The key difference between SOAP and these protocols are the way they encode data

28. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 28/89 Why SOAP? Data encoding in RPC involves converting the data (integers, character strings or complex objects) to be sent to the remote computer executing the procedure SOAP uses XML for this purpose since it is textual, whereas IIOP and JRMP are binary protocols Using XML for data encoding makes SOAP very user friendly for firewalls and for debugging purposes Furthermore, the need for specialized software such as a CORBA compliant ORB (for IIOP) is not needed

29. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 29/89 Layered model of Web service Communication

30. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 30/89 SOAP SOAP consists of three parts: an envelope that defines what is in a message, a set of encoding rules for expressing instances of application-defined data types, and a convention for representing remote procedure calls (RPC) and responses SOAP can be used in combination with by a variety of network protocols such as HTTP, SMTP, FTP, MQ or RMI over IIOP

31. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 31/89 SOAP over HTTP

32. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 32/89 The SOAP Envelope

33. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 33/89 SOAP Endpoint Reference

34. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 34/89 SOAP Envelope <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema">

35. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 35/89 SOAP Header Optional Provides info such as transaction identifier, security information

36. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 36/89 SOAP Body <SOAP-ENV:Header /> <SOAP-ENV:Body> <s:getPrice xmlns:s="http://www.srdc.metu.edu.tr/ProductCatalog"> <product_name xsi:type="xsd:string">Palm Pilot</product_name> </s:getPrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

37. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 37/89 SOAP Response HTTP/1.0 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: 400 <SOAP-ENV:Envelope xmlns:SOAP-ENV=" http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle=" http://schemas.xmlsoap.org/soap/encoding" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:xsd="http://www.w3.org/1999/XMLSchema"> <SOAP-ENV:Header /> <SOAP-ENV:Body> <s:getPriceResponse xmlns:s="http://www.srdc.metu.edu.tr/ProductCatalog"> <product_price xsi:type="xsd:float">2000.</product_price> </s:getPriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

38. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 38/89 Universal Descriprion, Discovery, Integration (UDDI) The future of ecommerce seems to be Web services! UDDI is jointly proposed by IBM, Microsoft and Ariba It is a service registry architecture that presents a standard way for businesses to build a registry, discover each other, and describe how to interact over the Internet Currently IBM and Microsoft are running public registries and Hewlett-Packard is expected to launch a third one More than 175 companies, including Boeing, Ford, CommerceOne and Sun Microsystems, have endorsed the UDDI initiative by contractually agreeing to support its future development

39. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 39/89 UDDI Registry Data Businesses register public informationabout themselves Standards bodies, Programmers, Businesses register information about their Service Types

40. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 40/89 UDDI Conceptually, the information provided in UDDI registries consist of three components: ``white pages'' of company contact information; "yellow pages" that categorize businesses by standard taxonomies; and "green pages" that document the technical information about services

41. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 41/89 UDDI The UDDI information model, defined through an XML schema, identifies five core types These core types are business, service, binding, service specifications information and relationship information between two parties

42. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 42/89 UDDI Through these data structures, business entities describe information about businesses like their name, description, services offered and contact data Business services provide more detail on each service being offered Services can then have multiple binding templates, each describing a technical entry point for a service (e.g., mailto, http, ftp, phone, etc.) These structures use category bags for categorization purposes

43. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 43/89 UDDI An item in a category bag contains a tModel key and an associated OverviewDoc element tModels provide the ability to describe compliance with a specification, a concept, or a shared design When a particular specification is registered with the UDDI as a tModel, it is assigned a unique key, which is then used in the description of service instances to indicate compliance with the specification The specification is not included in the tModel itself The "OverviewDoc" and "OverviewURL" elements of tModels are used to point at the actual source of a specification

44. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 44/89 UDDI More precisely, the use of tModels in UDDI is two-fold: Defining the technical fingerprint of services: The primary role that a tModel plays is to represent a technical specification on how to invoke a registered service, providing information on the data being exchanged, the sequence of messages for an operation and the location of the service Examples of such technical specifications include WSDL descriptions and RosettaNet PIPs Note that the tModel mechanism describes only the signature of the services; it does not provide any information on the functionality of the service

45. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 45/89 UDDI Providing abstract namespace references:In UDDI, businesses, services and tModels can specify the categories to which they belong in their category bags Categorization facilitates to locate businesses and services by relating them to some well-known industry, product or geographic categorization code set Currently UDDI uses the North American Industrial Classification Scheme (NAICS) taxonomy for describing what a business does; the Universal Standard Products and Services Classification (UNSPSC) for describing products and services offered; and ISO 3166, a geographical taxonomy for determining where a business is located

46. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 46/89 Current Classification Schemes in UDDI UNSPSC (Universal Standard Products and Services Classification, e.g., “43” Computer and Communication equipment, or “43172304” Disk arrays) NAICS (North American Industrial Classification Scheme, e.g., “E1041” for Gold Ores, or “N4911” for Electric services) ISO3166 (A geographical taxonomy) DUNS Number as identifier

47. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 47/89 UDDI It should be noted that any number of categories could be referenced in category bags In UDDI, it is possible to annotate businesses and tModels with identifiers The purpose of identifiers is to locate data more easily by using formal identifiers such as DUNS numbers, tax identifiers, or any other kind of organizational identifiers, regardless of whether these are private or shared UDDI provides built-in tModel specifications for DUNS and Thomas register

48. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 48/89 UDDI The UDDI specification also defines an API for interacting with UDDI registries Inquiry APIs locate businesses, services, bindings, or tModels Publishing APIs create or delete UDDI data in the registries An UDDI registry by IBM, implementing these APIs through a browser-based interface

49. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 49/89 UDDI It is possible to locate businesses and their services by their names published in the UDDI registry The categories referenced in the category bags can be used to find businesses or services of a particular category For example a user looking for a service for a particular product type can first obtain the product code from one of the defined taxonomies, like NAICS or UNSPSC

50. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 50/89 UDDI Assuming that the user wants to access the services related with optical computer disks, he obtains the UNSPSC code of "Magneto optical disks" which is "43.18.16.07.00" and searches the UDDI registry by using the APIs provided to find the businesses and their services that contain this code in their category bags However if a business fails to provide this exact code in its category bag, it becomes impossible to locate it in this way UDDI expresses the compliance of businesses and services that reference the same tModel in their descriptions

51. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 51/89 UDDI It should be noted that a tModel is not a service description language Services need to be described in service description languages like Web Service Description Language (WSDL) There is also a need for a remote method invocation mechanism like Simple Object Access Protocol (SOAP)

52. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 52/89 White Pages Business Name Text Description list of multi-language text strings Contact info names, phone numbers, fax numbers, web sites… Known Identifiers list of identifiers that a business may be known by - DUNS, Thomas, other

53. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 53/89 Yellow Pages Business categories 3 standard taxonomies in V1 Industry: NAICS - North American Industrial Classification Scheme (Industry codes - US Govt.) Product/Services: UN/SPSC - Universal Standard Products and Services Classification (ECMA) Location: ISO 3166 Geographical taxonomy

54. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 54/89 Green Pages Business processes Service descriptions Binding information

55. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 55/89 Business Registration XML document Created by end-user company (or on their behalf) Can have multiple service listings Can have multiple taxonomy listings

56. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 56/89 UDDI and SOAP

57. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 57/89 Registry APIs (SOAP Messages) Inquiry API Find find_business find_service find_binding find_tModel Get Details get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail Publishers API Save save_business save_service save_binding save_tModel Delete delete_business delete_service delete_binding delete_tModel 28 messages currently defined (pre taxonomy input/agreement)28 messages currently defined (pre taxonomy input/agreement)

58. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 58/89

59. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 59/89

60. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 60/89

61. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 61/89

62. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 62/89 Web service deployment Most Web service development is being accomplished today using either Microsoft .NET, or Sun Microsystems’ J2EE specification Note however that Web services development and deployment requires no specific underlying platform In other words, Web services do not rely on J2EE or .NET: They ride on SOAP and XML

63. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 63/89 The current J2EE vs. .NET is more about the application development environment

64. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 64/89 What is available in the market? BEA WebLogic Integration, http://www.bea.com/products/weblogic/integration/index.shtml Cyclone, http://www.cyclonecommerce.com/index.cyc IBM WebSphere, http://www-3.ibm.com/software/info1/websphere/index.jsp?tab=highlights IONA Netfish, http://www.iona.com/products Microsoft .NET, http://www.microsoft.com/net/ Microsoft BizTalk, http://www.microsoft.com/biztalk/

65. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 65/89 What is available in the market? Oracle Application Server, http://www.oracle.com/ip/deploy/ias/ Vitria Business Ware, http://www.vitria.com/products/ Webmethods B2Bi, http://www.webmethods.com/content/1,1107,Overview,FF.html Tibco Active Exchange, http://www.tibco.com/solutions/products/active_exchange/default.jsp

66. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 66/89 For more information SOAP http://www.w3c.org/TR/soap WSDL http://www.w3c.org/TR/wsdl UDDI http://www.uddi.org

67. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 67/89 Microsoft .NET Platform

68. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 68/89 The .NET Framework

69. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 69/89 Web Services with .NET

70. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 70/89 Microsoft .NET vs. J2EE .NET supports many programming languages .NET runs only on Windows servers J2EE is Java centric J2EE runs on any operating system

71. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 71/89 Microsoft .NET vs. J2EE

72. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 72 Workflow Systems

73. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 73/89 Workflow Workflows are activities involving the coordinated execution of multiple tasks performed by different processing entities, mostly in distributed heterogeneous environments which are very common in enterprises of even moderate complexity

74. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 74/89 Workflow A workflow system can be defined as a collection of processing steps (also termed as tasks or activities) organized to accomplish some business process A task may represent a manual operation by a human or a computerazible task to execute legacy applications, access databases, control instrumentation, sense events in the external world, or even affect physical changes

75. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 75/89 Workflow In addition to the collection of tasks, a workflow defines the order of task invocation or condition(s) under which tasks must be invoked (i.e. control-flow) and data-flow between these tasks

76. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 76/89 IBM MQ Series Workflow

77. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 77/89 Ultimus

78. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 78/89 How to define Public Processes through Web Services: Web Service Composition We had WSFL (Web Services Flow Language) from IBM and XLANG from Microsoft IBM and Microsoft have agreed to replace them with BPEL4WS BPEL4WS: Business Process Execution Language for Web Services

79. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 79/89 Service Composition: Travel Service Example

80. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 80/89 Business Process Execution Language for Web Services (BPEL4WS) Specifications proposed by IBM, Microsoft, BEA Unifies XLANG, WSFL XML-based workflow definition language Describe business processes that both provide and consume web services Implemented as an interaction with a web service

81. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 81/89 Business Process Execution Language for Web Services (BPEL4WS) BPEL4WS is Complemented by WS Coordination specification Allows to web services involved in a process to share information that “links” them WS Transaction specification Allows to monitor the success/failure of each coordinated activity Reliably cancel the business process Involves compensating activities

82. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 82/89 Business Process Execution Language for Web Services (BPEL4WS) Business process defines Potential execution order of operations (web services) Data shared between the web services Partners involved in business process Joint exception handling for collection of web services Long running transactions between web services

83. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 83/89 Important note Standards address Public Business Processes, exchanged documents, the messaging services, etc. Standards do not address how to integrate with the back-end applications BizTalk provides a mapper to map one document (eg a PO in XML to iDoc of SAP)

84. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 84/89 Another important issue for B2B integration is Back-end system integration

85. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 85/89 Future Research and Development Challenges of B2B Interoperability Although foundations are there, the B2B integration is not mature yet! Automating B2B Integration Automating B2B Integration implies data extracted from back end applications (ERP, SCM, CRM, etc.) of Company A are send to the trading partner, Company B, where it is automatically inserted into the back-end applications

86. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 86/89 Future Research and Development Challenges of B2B Interoperability Flexibility to dynamically adapt to changes Changes in the Public Business Processes: E.g., acknowledging a purchase order not in one POA but by acknowledging line items separately in several POAs Changes in message formats: E.g., adding fields for additional data in a purchase order

87. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 87/89 Future Research and Development Challenges of B2B Interoperability Creating Dynamic and Transient Relationships among partners Dynamic Virtual Organizations The establishment of “on demand” and “real-time” partnership

88. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 88/89 Future Research and Development Challenges of B2B Interoperability: Exploiting Web Service Semantics Currently, the mechanism to incorporate semantics to service registries (UDDI and ebXML) are through taxonomies like UNSPSC NAICS ISO3166 Taxonomies provide only limited semantics (class/subclass hierarchy) Unless semantic is incorporated into Web services, it is not possible to achieve dynamic networked enterprises

89. A. Dogac Grenoble Ecole de Management MEDFORIST Workshop 89/89 Thank you for your attention!