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

1
Grenoble Ecole de ManagementMEDFORIST
WorkshopB2B Interoperability Web Services
Approach

• Asuman Dogac
• Middle East Technical University
• Software RD Center
• Ankara, Türkiye

2
What B2B integration involves?
Purchase Order
Trading Partner A
Trading Partner B
Purchase Order Acknowledgement
Network
3
Challenge of Application Integration
Data Extraction Process
Data Mapping Process
Data Posting Process
Data Mapping Process
4
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
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
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
The major B2B Integration Standards

• EDI
• Web Services
• RosettaNet
• ebXML

8
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
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
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
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
What is a Web Service?

• To put it simply, a Web service is nothing but a
  server that listens for and replies with SOAP
  generally via HTTP

• A Web Service is an interface that describes
• a collection of operations
• that are network accessible
• through standardized XML messaging

13
Benefits of a Web service

• Includes
• Decoupling of service interfaces from the
  implementation
• Enabling dynamic service binding
• Providing interoperability among different
  platforms

14
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
Web Services

• Existing applications can be wrapped as Web
  services
• Client and Service can use different platforms
  and programming languages
• Services can be composed to make composite
  services

16
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 Consortiums 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
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
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
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
WS-Security

• Microsoft and IBM partnership
• Enhancement of SOAP messages to provide
• Message integrity
• Message confidentiality
• Message authentication

21
Security Properties
22
Web Service Model
Service Registry (ebXML or UDDI) - Web service
descriptions
Discover service
Publish service
Service Consumer
Service Provider - Web service - Service
Description in WSDL
Invoke service through SOAP
23
Web Service Description
Web Service Description
defines
Web Service
Service Consumer
uses
24
WSDL Structure
Service
Where to access it
Port (e.g. http//host/svc)
Port
How to access it
Binding (e.g. SOAP, JMS, direct call)
Binding
Operation An Exchange of Messages between a
service Requestor and a Service provider
Abstract definition of the service (set
of Operations)
Abstract interface
portType
operation(s)
inMesage
outMessage
25
Web Services Description Language
26
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
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
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
Layered model of Web service Communication
Message Encoding SOAP
SOAP defines the content of the message in XML
Message Transport
Message transport protocol is typically HTTP
Transport
The transport protocol used in Web Service
communication is typically TCP
30
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
SOAP over HTTP
HTTP POST Message
SOAP Endpoint Reference
XML Message
SOAP Payload
SOAP Envelope
SOAP Header
SOAP Body
32
The SOAP Envelope
ltSOAP-ENVEnvelope xmlns"http//schemas.xmls
oap.org/soap/envelope/"gt lt SOAP-ENVHeadergt
... lt/ SOAP-ENVHeadergt lt
SOAP-ENVBodygt ... lt/ SOAP-ENVBodygt
... lt/ SOAP-ENV Envelopegt
33
SOAP Endpoint Reference
IP Host Address
TCP Port No
Object Endpoint ID
144.122.230.16
80
/ProductCataloggetPrice
POST /ProductCatalog HTTP/1.0 Host
http//www.srdc.metu.edu.tr Content-Type
text/xml charset"utf-8" Content-Length
500 SOAPAction http//www.srdc.metu.edu.tr/P
roductCataloggetPrice"
34
SOAP Envelope

• ltSOAP-ENVEnvelope
• xmlnsSOAP-ENV" http//schemas.xmlsoap.org/
  soap/envelope/"
• SOAP-ENVencodingStyle" http//schemas.xmls
  oap.org/soap/encoding"
• xmlnsxsi"http//www.w3.org/1999/XMLSchema-
  instance"
• xmlnsxsd"http//www.w3.org/1999/XMLSchema"
  gt

35
SOAP Header

• Optional
• Provides info such as transaction identifier,
  security information

36
SOAP Body

• ltSOAP-ENVHeader /gt
• ltSOAP-ENVBodygt
• ltsgetPrice xmlnss"http//www.srdc.metu.edu.tr
  /ProductCatalog"gt
• ltproduct_name xsitype"xsdstring"gtPalm
  Pilotlt/product_namegt
• lt/sgetPricegt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

Method Name
Input Parameter
37
SOAP Response

• HTTP/1.0 200 OK
• Content-Type text/xml charset"utf-8"
• Content-Length 400
• ltSOAP-ENVEnvelope
• xmlnsSOAP-ENV" http//schemas.xmlsoap.org/
  soap/envelope/"
• SOAP-ENVencodingStyle" http//schemas.xmls
  oap.org/soap/encoding"
• xmlnsxsi"http//www.w3.org/1999/XMLSchema-
  instance"
• xmlnsxsd"http//www.w3.org/1999/XMLSchema"
  gt
• ltSOAP-ENVHeader /gt
• ltSOAP-ENVBodygt
• ltsgetPriceResponse xmlnss"http//www.srdc.me
  tu.edu.tr/ProductCatalog"gt
• ltproduct_price xsitype"xsdfloat"gt2000.lt/prod
  uct_pricegt
• lt/sgetPriceResponsegt
• lt/SOAP-ENVBodygt
• lt/SOAP-ENVEnvelopegt

Standard Suffix
38
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
UDDI Registry Data
WhitePages

• Businesses register public informationabout
  themselves
• Standards bodies, Programmers, Businesses
  register information about their Service Types

YellowPages
GreenPages
Service Type Registrations
40
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
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
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
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
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
UDDI

• Providing abstract namespace referencesIn 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
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
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
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
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
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
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
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
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
Green Pages

• Business processes
• Service descriptions
• Binding information

55
Business Registration

• XML document
• Created by end-user company (or on their behalf)
• Can have multiple service listings
• Can have multiple taxonomy listings

56
UDDI and SOAP
UDDI RegistryNode
User
UDDISOAP Request
HTTPServer
SOAPProcessor
UDDISOAP Response
UDDIRegistry Service
B2B Directory
Create, View, Update, and Deleteregistrations
Implementation-neutral
57
Registry APIs (SOAP Messages)

• Publishers API
• Save
• save_business
• save_service
• save_binding
• save_tModel
• Delete
• delete_business
• delete_service
• delete_binding
• delete_tModel

• Inquiry API
• Find
• find_business
• find_service
• find_binding
• find_tModel
• Get Details
• get_businessDetail
• get_serviceDetail
• get_bindingDetail
• get_tModelDetail

58
(No Transcript)
59
(No Transcript)
60
(No Transcript)
61
(No Transcript)
62
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
The current J2EE vs. .NET is more about the
application development environment
64
What is available in the market?

• BEA WebLogic Integration, http//www.bea.com/produ
  cts/weblogic/integration/index.shtml
• Cyclone, http//www.cyclonecommerce.com/index.cyc
• IBM WebSphere, http//www-3.ibm.com/software/info1
  /websphere/index.jsp?tabhighlights
• IONA Netfish, http//www.iona.com/products
• Microsoft .NET, http//www.microsoft.com/net/
• Microsoft BizTalk, http//www.microsoft.com/biztal
  k/

65
What is available in the market?

• Oracle Application Server, http//www.oracle.com/i
  p/deploy/ias/
• Vitria Business Ware, http//www.vitria.com/produc
  ts/
• Webmethods B2Bi, http//www.webmethods.com/content
  /1,1107,Overview,FF.html
• Tibco Active Exchange, http//www.tibco.com/solut
  ions/products/active_exchange/default.jsp

66
For more information

• SOAP
• http//www.w3c.org/TR/soap
• WSDL
• http//www.w3c.org/TR/wsdl
• UDDI
• http//www.uddi.org

67
Microsoft .NET Platform
Directory of services UDDI
Service discovery DISCO
Service descriptions WSDL
Service interactions SOAP
Universal type system XSD
Universal data format XML
Ubiquitous communication Internet
68
The .NET Framework
Visual Studio.NET
Common Language Specification
ADO.NET and XML
Base Class Library
Common Language Runtime
Operating System
69
Web Services with .NET
70
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
Microsoft .NET vs. J2EE
72
Workflow Systems
73
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
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
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
IBM MQ Series Workflow
77
Ultimus
78
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
Service Composition Travel Service Example
80
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
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
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
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
Another important issue for B2B integration is
Back-end system integration
ERP SAP
Private Process
Transformations
Transformations
ERP Oracle
Execute A legacy
Transform To RN PO
Process PO
Transform to SAP PO
Transform To Oracle POA
Process POA
Transform to RN POA
Process SAP PO
Network
85
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
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
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
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
Thank you for your attention!