Introduction into Web Services (WS)
Agenda
• Background and the need for WS
• SOAP – the first Internet-ready RPC
• Basic Web Services
• Advanced Web Services
• Case Studies
• The ebXML framework
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
Remote Procedure Call
Distributed Objects
DCOM (COM+) – Microsoft Standard
Windows-dependent
CORBA – Object Management Group
(OMG) Standard
OMG – vendor-neutral consortium
J2EE Distributed Components
From http://www.tusc.com.au/tutorial/html/chap2.html
General J2EE Architecture
Why do we need more?
• Interoperability issues
– DCOM can‘t natively talk to CORBA
– CORBA can‘t natively talk to J2EE
– Expensive bridging solutions required
– CORBA applications from different vendors
can‘t talk between themselves
– J2EE components are not portable between
different servers
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
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
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
Web Services pioneer - XML-RPC (1998)
XML-RPC Protocol
• Uses XML and HTTP
• Very simple to use
• Allows disparate systems
to communicate
Merits of XML and HTTP
• XML
– Extensible Markup Language
– Platform agnostic
– Existing parsers for many languages
• HTTP
– Ubiquitous
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/
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
SOAP Envelope
From http://www.techmetrix.com/trendmarkers/publi.php?C=EW2I
SOAP-based Communication
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_soap.htm
– http://ws.apache.org/soap/
SOAP in Action – Deployment View
Reverse Proxy Firewall SMS Processor CN FR/NL Cancer The Internet OracleDB Server Linux SOAP Server CN FR/NL Cancer BT Router Production / Intranet DMZ Aspiro SMS Switch Kiala SMS Infrastructure A. Svirskas Firewall Outbound ProxySo 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
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/wsdlWSDL Structure
•
WSDL Ports
– The <portType> 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 <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language.
•
WSDL Messages
– The <message> 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 <types> 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 <binding> element defines the message format and protocol details for each port.
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
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
Web Services Examples
• Google.com -
http://www.google.com/apis/• Amazon.com
-http://associates.amazon.com/exec/panama/associates/join/developer/faq.html
• eBay.com -
http://www.internetnews.com/dev-news/article.php/3312341How do I write my own WS?
• Download a toolkit:
– IBM - http://www.alphaworks.ibm.com/tech/ettk
– Sun - http://java.sun.com/webservices/downloads/webservicespack.html
– Many more implementations
• Read a tutorial
– http://www.theserverside.com/articles/article.tss?l=Systinet-web-services-part-1 – http://www.systinet.com/download/TutorialOne.pdf
• Implement a service and test it
• Enjoy the new experience
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
Advanced Web Services Architecture
From http://www-306.ibm.com/software/solutions/webservices/pdf/SecureReliableTransactedWSAction.pdf
Vendors such as
IBM, BEA, Microsoft teamed up together with OASIS and W3C
to provide business-grade Web Services framework
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
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
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
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
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
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
