Introduction into Web Services (WS)

1
Introduction into Web Services (WS)

• Adomas Svirskas

2
Agenda

• Background and the need for WS
• SOAP the first Internet-ready RPC
• Basic Web Services
• Advanced Web Services
• Case Studies
• The ebXML framework
• How do I use/develop Web Services?

3
Background and the need for WS

• There is almost always a need for processes
  (objects, modules, components) to communicate
• Inter-process communication alternatives
• Shared memory
• Shared databases
• Transport-level network protocols (Pipes,
  Sockets)
• Remote procedure calls (RPC)
• Distributed objects and components
• Asynchronous message passing

4
Remote Procedure Call
From http//users.uma.maine.edu/faculty/rsm/slides
/slides.htm
5
Distributed Objects
DCOM (COM) Microsoft Standard Windows-dependen
t
CORBA Object Management Group (OMG)
Standard OMG vendor-neutral consortium http//w
ww.omg.org OS and programming language neutral
From http//www.byte.com
6
J2EE Distributed Components
General J2EE Architecture
Component communications
From http//www.tusc.com.au/tutorial/html/chap2.ht
ml
7
Why do we need more?

• Interoperability issues
• DCOM cant natively talk to CORBA
• CORBA cant natively talk to J2EE
• Expensive bridging solutions required
• CORBA applications from different vendors cant
  talk between themselves
• J2EE components are not portable between
  different servers

8
Why do we need more?

• The Internet changed it all
• Number of systems involved in interactions is
  vast compared to that within the corporate
  boundaries
• Discovery issues
• Scalability issues
• Security issues
• Interoperability no longer depends on decisions
  of the CTO of a company

9
Why do we need more?

• All mentioned technologies failed to ensure
  integration and interoperability in the Internet
  environment
• They were designed for the Intranets
• The Internet dictated its own rules, mostly
  bottom-up standards and protocols, based on their
  widespread success

10
What is needed?

• An RPC-like solution which would
• Be OS and vendor agnostic
• Use the standard Internet protocols (HTTP, SMTP),
  i.e. firewall-friendly communication
• Have simple API from different programming
  languages
• Use simple data representation

11
Web Services pioneer - XML-RPC (1998)
http//www.xmlrpc.com/
From http//www-106.ibm.com/developerworks/librar
y/ws-xpc1/
12
XML-RPC Protocol

• Uses XML and HTTP
• Very simple to use
• Allows disparate systems
• to communicate

13
Merits of XML and HTTP

• XML
• Extensible Markup Language
• Platform agnostic
• Existing parsers for many languages
• HTTP
• Ubiquitous
• Widely supported and firewall-friendly

14
Simple Object Access Protocol

• SOAP uses the same principles as XML-RPC and
  builds on its success
• SOAP tries to pick up where XML-RPC left off by
  implementing user defined data types, the ability
  to specify the recipient, message specific
  processing control, and other features.
• SOAP was supported by IBM and Microsoft from its
  inception in 1999
• Currently SOAP 1.2 is under W3C control
  http//www.w3.org/TR/soap/

15
Simple Object Access Protocol

• The SOAP specification consists of roughly these
  areas
• A content-neutral packaging scheme
• Extensibility for additional functionality
• Rules for encoding common application data
  structures,
• Types in an XML format
• Bindings to HTTP transport.
• SOAP's primary strength comes from its simple and
  extensible packaging scheme

16
SOAP Envelope
From http//www.techmetrix.com/trendmarkers/publi.
php?CEW2I
From http//developer.apple.com/documentation/WebO
bjects/Web_Services/Introduction/chapter_2_section
_5.html
17
SOAP-based Communication
From http//www.techmetrix.com/trendmarkers/publi.
php?CEW2I
18
Simple Object Access Protocol

• SOAP is way more powerful and complex than
  XML-RPC
• Implementations by
• IBM/Apache
• Sun Microsystems
• Microsoft
• And others...
• More useful links
• http//www-106.ibm.com/developerworks/webservices/
  library/ws-ref1.html
• http//weblog.masukomi.org/writings/xml-rpc_vs_soa
  p.htm
• http//ws.apache.org/soap/
• http//www.xml.com/pub/a/2000/07/12/soap/mssoaptut
  orial.html

19
SOAP in Action Logical View
20
SOAP in Action Deployment View
21
SOAP in Action Java/MS
A. Svirskas December 2000
22
So what else do we need?

• Wbe can do RPC over the Internet! Great!
• But... we need standard ways for
• Describing SOAP service capabilities
• Publishing the services
• Discovering the services
• Interacting with the services
• Otherwise we would search for a needle in a
  haystack

23
Service Oriented Architecture
From http//www.jot.fm/issues/issue_2002_07/column
5
24
Web Services Description Language

• WSDL stands for Web Services Description Language
  
• WSDL is written in XML
• WSDL is an XML document
• WSDL is used to describe Web services
• WSDL is also used to locate Web services
• WSDL Spec http//www.w3.org/TR/wsdl

25
WSDL Example
Real world example http//soap.amazon.com/schemas
3/AmazonWebServices.wsdl
26
WSDL Structure

• WSDL Ports
• The ltportTypegt element is the most important WSDL
  element.
• It defines a web service, the operations that can
  be performed, and the messages that are involved.
• The ltportTypegt element can be compared to a
  function library (or a module, or a class) in a
  traditional programming language.
• WSDL Messages
• The ltmessagegt element defines the data elements
  of an operation.
• Each messages can consist of one or more parts.
  The parts can be compared to the parameters of a
  function call in a traditional programming
  language.
• WSDL Types
• The lttypesgt element defines the data type that
  are used by the web service.
• For maximum platform neutrality, WSDL uses XML
  Schema syntax to define data types.
• WSDL Bindings
• The ltbindinggt element defines the message format
  and protocol details for each port.

27
Universal Description, Discovery and Integration

• UDDI stands for Universal Description, Discovery
  and Integration
• UDDI is a directory for storing information about
  web services
• UDDI is a directory of web service interfaces
  described by WSDL
• UDDI communicates via SOAP
• UDDI Spec http//www.oasis-open.org/committees/ud
  di-spec/

28
Web Services in Operation
29
Types of Web Services
From http//www.computerworld.com/developmenttopi
cs/development/story/0,10801,79698,00.html
30
Asynchronous Web Services

• In some situations, responses to Web service
  requests are not provided immediately, but rather
  sometime after the initial request transactions
  complete
• Different types of underlying middleware might be
  used to accomplish this task HTTP, SMTP, JMS

From http//www-106.ibm.com/developerworks/librar
y/ws-asynch2/index.html
31
Asynchronous Web Services
From http//www.computerworld.com/developmenttopi
cs/development/story/0,10801,79698,00.html
32
Web Services Examples

• Google.com - http//www.google.com/apis/
• Amazon.com - http//associates.amazon.com/exec/pan
  ama/associates/join/developer/faq.html
• eBay.com - http//www.internetnews.com/dev-news/ar
  ticle.php/3312341
• Many more - http//www.salcentral.com/salnet/webse
  rvicewhat.asp

33
How do I write my own WS?

• Download a toolkit
• IBM - http//www.alphaworks.ibm.com/tech/ettk
• Sun - http//java.sun.com/webservices/downloads/we
  bservicespack.html
• Many more implementations
• Read a tutorial
• http//www.theserverside.com/articles/article.tss?
  lSystinet-web-services-part-1
• http//www.systinet.com/download/TutorialOne.pdf
• Implement a service and test it
• Enjoy the new experience

34
Do we need more?

• So we can develop, publish, discover, invoke Web
  Services
• But... this is an application integration
• While the business world needs business process
  integration
• Thus we need composable, orchestrated,
  transactable, secure Web Services

35
Advanced Web Services Architecture
From http//www.w3.org/TR/2004/NOTE-ws-arch-200402
11/
36
Advanced Web Services Architecture
Vendors such as IBM, BEA, Microsoft teamed up
together with OASIS and W3C to provide
business-grade Web Services framework
From http//www-306.ibm.com/software/solutions/web
services/pdf/SecureReliableTransactedWSAction.pdf
37
E-business Integration Patterns

• The document exchange pattern
• The exposed applications pattern
• The exposed business services pattern
• The managed public processes pattern
• The managed public and private processes pattern

38
Exposed Business Services Pattern
39
Exposed Business Services Pattern

• A layer between the backend enterprise system and
  partner tier
• This layer exposes an e-business oriented
  interface
• Business service interface to be agreed by
  partners
• Web Services technology is an example

40
Managed Public Process Pattern
41
Managed Public Process Pattern

• Private and Public processes are separated more
  strictly
• Public processes are identified, analysed and
  formally described
• Integration occurs at Business Process level
• RosettaNet is an example
• Trading Partner Agreements TPA

42
ebXML Framework

• A framework of specifications for E-business
  integration based on state-of-the-art software
  architecture concepts and on experience in
  development of E-business systems
• E-business interactions between organizations are
  modelled, standardised and published via
  E-business registries
• The use of XML-based, declarative specification
  languages provides configurability and
  interoperability
• Architectural separation of business and
  information technology aspects of e-business
  systems

43
ebXML and Integration Patterns

• ebXML is intended to support managed public
  processes pattern
• Various middleware types are supported
• Focus on E-business application rather
  application integration
• Declarative definition of public business
  processes
• Support of partner agreements

44
ebXML Modelling Methodology
45
ebXML Business Operational View

• The BOV Addresses
• The semantics of business data in transactions
  and associated data interchanges
• The architecture for business transactions,
  including
• Operational conventions
• Agreements and arrangements
• Mutual obligations and requirements

46
ebXML Functional Services View

• The FSV Addresses
• Functional capabilities
• Business Service Interfaces
• Protocols and Messaging Services

47
ebXML Framework contd

• Business Process Specification Schema (BPSS) is
  an XML-based specification language that formally
  defines "public" business processes. It focuses
  on the collaboration of trading partners, and the
  business transaction activities they perform in
  the context of those collaborations.

48
ebXML Framework contd

• Core Components Those provide the business
  information that is encoded in business documents
  that are exchanged between business partners.
• Registry/Repository This is useful for more than
  merely conducting business searches. Some
  business scenarios depend heavily on registries
  to support setting up business relationships.

49
ebXML Framework contd

• Collaboration Protocol Profiles (CPP) and
  Agreements (CPA) These are XML documents that
  encode a party's e-business capabilities or two
  parties' e-business agreements, respectively.
• Transport, Routing and Packaging The ebXML
  messaging services provide an elegant
  general-purpose messaging mechanism. The ebXML
  messaging service is layered over SOAP (Simple
  Object Access Protocol) and can transport
  arbitrary types of business content.

50
ebXML Business Scenario
51
Conclusions

• Web Services emerged as a synthesis of RPC
  expertise and the Internet opportunities
• Web Services matured over past few years into a
  business-grade solution
• Web Services field continues to expand
• Questions, comments
• Adomas Svirskas a.svirskas_at_kingston.ac.uk