web services foundations
TRANSCRIPT
Web Services Foundations
Š Copyright 1999â2004 IONA Technologies PLC. All rights reserved
IONA Technologies PLC IONA Technologies Inc. The IONA Building 200 West Street Shelbourne Road Waltham, MA 02451 Dublin 4, Ireland USA Telephone: + 353 1 637 2000 Telephone: +1 781 902 8000 Fax: + 353 1 637 2888 Fax: +1 781 902 8001 IONA Technologies Japan, Ltd. Training: [email protected] Akasaka Sanchome Building 7/F Sales: [email protected] 3-21-16 Akasaka, Minato-ku FTP site: [email protected] Tokyo, Japan 107-0052 Web: www.iona.com Telephone: +813 3560 5611 Fax: +813 3560 5612
Table of Contents
Chapter 0: Introduction, Overview, Schedule 1 Chapter 1: Web Services â Setting the Stage 5 Chapter 2: Why Web Services? 17 Chapter 3: Web Services Technologies 23 Chapter 4: Web Services Tools and Demo 57 Chapter 5: Service Oriented Architecture 87 Chapter 6: Web Service Design Aspects 99 Chapter 7: Advanced Topics 109 Chapter 8: Summary, References and Useful links 119
Š Copyright 1999 - 2004 IONA Technologies PLC. All rights reserved.
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 1
1
Web Services FoundationsSean Baker
Eric NewcomerWolfgang Schulze
Rich BonneauAdrian Trenaman
IONA Technologies
Version 8
0-2
What you will see/learn âŚ
⢠Real Web services in action⢠An overview of the major WS technologies⢠Live demos of typical WS development tools⢠Insight into Service Oriented Architecture as a
way to design Web Service-based systemsâ Design and best practices
⢠An overview of advanced Web Services topics and futures
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 2
0-3
What This Course is About
⢠In scopeâ Grand tour of Web service technologyâ Using services to migrate and contain legacy applications and
legacy middlewareâ Consolidating redundant functionality â Incrementally building enterprise-wide infrastructure
⢠Close, but out of scopeâ Methodologyâ Model-Driven Architectureâ Web (development) technology in a broader senseâ âClassicalâ B2B (RosettaNet, ebXML, EDI, UCCnet,âŚ) â Utility computing, Grid computing, agent technology
⢠Intended Audience
0-4Course Schedule
Break3:15Service Oriented Architecture and Web Services52:30
Web Services Design Aspects63:30
Why Web Services?29:50Break10:15
87
4
3
10
Chapter Number
Advanced Web Service Topics and Futures4:15Summary/References/Useful Links/Q&A4:45
WS â Development Tools and Demo1:00Lunch12:00
WS Technologies: XML, SOAP, WSDL, UDDI 10:30
Setting the stage: An introductory WS demo9:15Overview and Schedule9:00
TopicsTime
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 3
0-5
Acronyms (For Reference Purposes)
⢠SOA Service Oriented Architecture⢠UDDI Universal Definition, Discovery and Integration
(of Web Services)⢠W3C World Wide Web Consortium⢠WS Web Service⢠WSDL Web Service Description Language⢠WS-I Web Services Interoperability organization⢠WSID Web Services Interoperability Demonstration⢠XML Extensible Markup Language⢠XSLT XML Stylesheet Language (Transform)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 5
1
Chapter 1Web Services â Setting the Stage
A simple, live, interactive demo illustrating Web Services as XML document exchange between a client and a server
Version 12
1-2
A simple live interactive scenario
⢠Stock quote exampleâ Supply a symbolâ Get a price quote back
⢠How ?â Build up the Web Service XML request documentâ Invoke the service, supplying the document â Review the XML response document
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 6
1-3
Letâs go â using a simple environment⢠We could use any number of tools for this demo
but to show the simplicity of WS, we will use:
â A simple text editor (Text Pad) to construct the XML document
â A small part of the popular XMLSPY tool: to invoke the service and review the results
â A remote, independent Web Service server to return the quotes
⢠The SOAP protocol will carry the message to the service, and the reply back to the client
1-4
How will all of this work? A Web Services Infrastructure
WS Client WS ServerXML document
XML document
Web Service
SOAP Support
SOAP Support
SOAP message
SOAP message
HTTP Support over network
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 7
1-5
The simplest of data - a stock symbol!
1-6
Self-identify as a stock symbol
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 8
1-7Extend our XML document to indicate the type of message (request)
1-8Wrap the document within a SOAP message (envelope and body)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 9
1-9
One âtechnical detailâ re namespaces
1-10Transmit to a waiting Web Service Server. Weâll use XMLSPY to transmit the SOAP message
FORD</
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 10
1-11
Response message from server
1-12Change the symbol to âIBMâ and re-send.Hereâs the response:
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 11
1-13Hereâs a more complex document returnedfrom a different stock quote service:
1-14How did we know what structure of XML to send; and what weâd get back in response?
⢠The WSDL (Web Services Description Language) file specified the Stock Quote service:â Operations â names and parametersâ Message formatsâ Endpoint URL
⢠Letâs look quickly at the WSDL file for the original simple Stock Quote service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 12
1-15
Screen shot of WSDL file
1-16Web Service Technologies RelationshipsRun time vs Design Time
E.g.,HTTP
Client WebService
SOAPRequest
SOAPResponse
XML
Run
time
exec
utio
n
WSDL Specifies âŚ
Operations,Structure and
Typing of Messages
EncodingAnd Transport of
Messages
PhysicalEndpoint
ServiceCommunicationsRequirements:
Des
ign
and
Dep
loy
time
XML Schema
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 13
1-17
What is the Web Service Server Doing?
⢠The typical server pattern âŚ
â Wait on arriving XML documents contained within a SOAP envelope
â Extract and analyze the documentâ Interact with other software components to complete
the processing of the documentâ Optionally return another XML document in response
WebService
SOAPRequest
SOAPResponse
server
1-18
Points to be made about demo
⢠This is not the same as Web pagesâ No browsers, web servers, HTML, CGI, ASP pages,
GUIs, etc⢠Rather â exchange of XML documents between
âco-operatingâ programsâ Web Services is intended for program-to-program
communications â Not human-to-web page communications
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 14
1-19
../cont.
⢠Uses newer information exchange standardsâ XML technologies for documents
⢠ASCII, human-readable, self-describing, extendable, simple, and portable across OS, hardware, programming languages
â SOAP as vehicle for transmitting/receiving XML documentsâ WSDL to specify definition/structure/rules of the service
⢠Messages/documents ⢠Location of service for access⢠Transport options, etc.
⢠More enterprise-level WS standards emerging for such aspects as transactions, security, choreography of services, etc.
1-20
Points to be made about demo (cont.)
⢠We accessed the service using Web Services
â Web Services is an âinterfacing technologyâ
â It is not a technology for implementing servers (or clients)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 15
1-21
Final points âŚâ˘ Can easily read, edit, re-transmit and interpret the XML
documents and SOAP messages - because itâs all text⢠There are simple tools to help you to make WS calls
from inside your programs, and to accept such calls into your server programsâ Create and send SOAP messages from the client programsâ Accept and handle them in server programs
⢠Remember that some XML documents can be very complex (as weâve seen)â So these tools can save you a lot of effort
⢠Weâll see some of these tools in later chapters
1-22
Transition to the rest of the course
⢠We will explore in greater detail the list of technologies touched upon in this short demo:â XML technologies â how to represent documents
⢠Including XML Schema (not introduced yet)â SOAP â how to wrap documents to be sent outâ WSDL â how to describe services and document exchangesâ UDDI (not discussed yet) â how to register, find services
⢠Also we will present alternative solutions and approaches beyond what we have seenâ Other transports, protocols, options, etc.â Best practices for designing WS-based systems
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 17
Chapter 2Why Web Services?
Version 7
2-2BrainstormingWhy might I want to use Web Services?
Some of the vague reasons seen often in the press:
⢠I read so much about it, and Iâm afraid to get left behind⢠Our CIO told me to⢠Our competitor claims to have saved 2 million dollars with it⢠I hate vendor lock-in!⢠Because itâs cool!⢠Because vendor XY tells me itâs useful⢠Everyone uses it!⢠Do I even have a choice?⢠Itâs cheaper
Letâs get serious . . .
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 18
2-3
Why Web Services? â Overview of this chapter
⢠Different reasons for different people!â Cost-centric â largest IT cost is laborâ Integration-centricâ Business-drivenâ Reuse-centricâ The answer is always a mixture
⢠But: Web Services are not for everything!â In a later chapter, weâll talk about when Web Services
is not the right technology⢠Summary
2-4Why Web Services?Cost-centric reasons
⢠Situationâ Currently, we use <xyz> to interconnect applications
that costs x million $ in annual support and maintenance⢠Yet integration is still a major challenge for us
â If integration was easier, we could spend more time building new useful functionality
â Experts are needed for design and implementation⢠Benefits of Web Services
â Simple technology, short learning curveâ Standards minimize the risk of vendor lock-inâ Cheap, no huge initial investment
⢠Example â Replacing âhomegrownâ solutions
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 19
2-5Why Web Services?Integration-centric reasons (EAI scenario)
⢠Situationâ Two or more applications need to be integratedâ Business need and budget for solving the problem â Choices: âtraditional EAI toolâ vs. Web Services
⢠Benefits of Web Servicesâ Instead of just doing a point-to-point integration between two
applications, you can build a set of services that can be used by other applications in your enterprise
⢠You can avoid a short-term tactical point-to-point integration⢠Services can call other services, so you can do even better than
integration: you use services to consolidate some of your enterprise systems
⢠Potential to rip out some middle-tiers / hubs (âdisintermediationâ)â Implementations on all platforms available (incl. mainframe)
⢠Exampleâ Integrate a set of J2EE and .NET applications, and later allow some of
these services to be used by other environments
2-6Why Web Services?Integration-centric reasons (B2B scenario)
⢠Situationâ need to link up my business processes with partnerâ Canât or donât want to agree on a heavyweight B2B
protocol, or none applies for this problem⢠Benefits of Web Services
â We can create light-weight B2B protocolsâ Web Services rely only on Internet standardsâ Both partners can use development tools from different
vendors (incl. Open source)â Low cost of entry (no expensive software purchases)
⢠Exampleâ Low cost alternative to EDI
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 20
2-7Why Web Services?Provider scenario
⢠Situationâ Useful service (e.g. check flight status, shipping status) to
be made available programmatically⢠Short term goal: Market share⢠Long term goal: Charge!
â Requirements for delivery: Open, widely used, reach maximum number of clients, secure, etc.
⢠Benefits of Web Servicesâ Web Services rely only on internet standardsâ Low cost of entry (no expensive software purchases)
⢠Exampleâ Amazon.comâs virtual storefront services
2-8Why Web Services?Consumer scenario
⢠Situationâ Number of useful web services is growing
(Just look at www.salcentral.com or www.xmethods.net !)⢠You may want to use some of these in your programs and/or on your web
pagesâ Albeit that most of these public Web Services donât come with any guarantees
â Some of these offer services that you couldnât implement yourself ⢠e.g. validate CC transaction
⢠Benefits of Web Servicesâ Itâs easier to incorporate useful features into client apps or web pages
⢠regardless whether they are hosted internally or on the internet
⢠Exampleâ Your own web page with automatically updated stock prices and
sports scores (what more would you need in life).
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 21
2-9Why Web Services?reuse-centric (intra-enterprise)
⢠Situationâ Most enterprises would benefit from sharing services
⢠Rather than re-implementing them in many projects (and supporting all of these)
⢠These days, lowering costs and consolidation are keyâ The many technology âwarsâ have given us many technology islands
within each enterprise⢠Benefits of Web Services
â Web Services can be used to bridge across these technology islands⢠We can use it to create an architecture aimed at re-use
â Expect lower resistance than with prior technologies⢠Because Web Services isnât used to implement clients or servers
â Itâs a âneutral interface technologyââ Growing internal use of XML, so often no need to transform data
⢠Exampleâ Reuse existing services across technology islands
2-10
Overview of web service usages-Scope-Organizational impact-Complexity
-Number of involved applications/services
Niche usage
Provider-centric
Consumer-centric
Integration usage
EAI
Enterprise infrastructurefocus: reuse
Architecture for re-use of
servicesB2B
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 22
2-11SummaryWhy should I use Web Services?
⢠To replace existing or homegrown middleware with cheaper off-the-shelf, standards-based solution (cost-centric)
⢠I need to integrate these two (or more) applications in order to achieve a certain business goal (integration-centric, EAI)
⢠I want to build a link with a business partner over the internet(integration-centric, B2B)
⢠I have built a cool service and I would like others to use it (provider only)
⢠I could add a cool feature to my application if I could easily make use of that web service which I found (consumer only)
⢠I am an Enterprise Architect and it would be great if we could achieve better reuse by sharing as many common services as possible between different applications. Avoiding redundancy could save a lot of money. (reuse-centric)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 23
1
Chapter 3Web Services Technologies
XML and SOAPWSDL and UDDI
Version 10
3-2
Web Services Technologies
⢠A collection of XML technology standards that work together to provide Web Services capabilitiesâ We will provide an overview of the more prominent WS standards
⢠Web Services Technologies are primarily an integration or interfacing technology â NOT an application development technologyâ Still can develop in existing or new software development
environments⢠Web Services Technologies make it easier to tie together
existing or planned software components â Due to the language-, platform-, OS-, hardware-neutral
characteristics of the standards⢠As we will see a later chapter, Web Services
Technologies provide one approach to implementing the interfaces and messages for a Service Oriented Architecture-based system
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 24
3-3Participants in a Web Services Environment:the roadmap for this chapter
3-4
XML / Web services â in action
IntegratedApplicationOr domain
LocalTransforms
LocalData Model
UDDI Registry IntegratedApplicationOr domain
LocalTransforms
LocalData Model
WS/SOAP client
XML mapping
SOAP server
ServiceDescription
(WSDL)
SOAP server
ServiceDescription
(WSDL)
1) Register2) Inquire
4) Request/Response
SOAP messages
(XML)3) Get WSDL
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 25
3-5
Web Services Technologies Overview⢠XML Technologies
â âExtensible Markup Languageââ Base XML for documentsâ XML Schema for describing XML documents
⢠SOAPâ âSimple Object Access Protocolâ
⢠A simple way to send documents (some people have calledi t âemail for documentsâ)
â How to format XML documents for transmission⢠WSDL
â âWeb Services Description Languageââ Defines all details about a service
⢠UDDIâ âUniversal Definition, Discovery and Integrationââ One way to advertise and discover services
3-6Participants in a Web Services Environment:Part 1 - XML Technologies
XML documentswithin
SOAP messagesdefined by
WSDLdiscovered via
UDDI
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 26
3-7
XML Technologies
⢠Collection of extensible information representation and manipulation technologies â XML itself â the base document standardâ XML Schema â for data typing and document
structuringâ XSLT â for transforming XML to other XML or other
formatsâ Parsing strategies for XML document processing
⢠DOM â Document Object Model⢠SAX â Simple API for XML
â Others: XPATH, XQUERY, etc.
3-8XML TechnologiesXML â eXtensible Markup Language
⢠Originally a derivative of SGML in the family of markup languages
⢠Similar to HTML in appearance, but with a very different goalâ to separate data content from data presentation
⢠Now, a full and evolving W3C standard⢠Parsable, extensible and self-describing text format for
exchanging informationâ Platform-, hardware-, programming-language-neutralâ Highly portable across heterogeneous networks
⢠Reference: http://www.w3.org/XML/
SGML : Structured Generalized Markup Language
W3C : World Wide Web Consortium
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 27
3-9XML TechnologiesImportant characteristics of XML⢠Similar in appearance to HTML
â HTML has a fixed set of tags, XML has a variable set⢠Two major structuring mechanisms:
â Elements that may contain other elementsâ Attributes characterize elements with simple strings
⢠Elements are demarcated by Tags at the start and end:⢠E.g., a MyElement element
<MyElement> âŚ. </MyElement> ⢠Nested elements are used to model complex data
⢠Weâll see many examples of this
⢠Extensible â can define new elements and attributes easily⢠But â sometimes considered âas wasteful and inefficientâ!!
⢠Letâs look at very simple XML documents â teach by example
3-10XML TechnologiesSimple XML Document Exchange
Example of an XML-based request documentFour elements:getQuotesymbol
getQuoteResponseReturn
Two containother elements.
Two containsimple text content.
<getQuote><symbol>FORD</symbol>
</getQuote>
Example of an XML-based response document
<getQuoteResponse><Result>56.5</Result>
</getQuoteResponse>
Each XML document can have only one top-most element.
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 28
3-11XML TechnologiesSimple XML Document Exchange with attributes
<getQuoteResponse date=â02-01-2004â><Return>56.5</Return>
</getQuoteResponse>
Date attributeExample of an XML-based request
<getQuote date=â02-01-2004â><symbol>FORD</symbol>
</getQuote>
Example of an XML-based response document Date attribute
3-12Shortcut if there is no value between
the tags⢠if the symbol was changed to be an attribute, then
you could write either this:
<getQuote smybol=âFORDâdate=â02-01-2004â>
</getQuote>
<getQuote smybol=âFORDâdate=â02-01-2004â />
⢠Or use a shortcut:
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 29
3-13XML TechnologiesXML Namespaces
⢠Used to avoid element and attribute name clashes when creating complex XML documents
⢠Attributes of the form xmlns:prefix=identifier are used to introduce a namespace and establish the prefixâ Subsequently, names within the namespace must be written as
prefix:name
⢠There is also a way of setting up a default namespace so you do not have to write the prefix: xmlns=identifier
⢠As weâll see, the identifier is typically a URL.⢠Let look at some examples
3-14XML TechnologiesNamespaces â a simple example⢠Example of a simple XML request document with a
namespace
<WSMsg:getQuote xmlns:WSMsg=âhttp://www.WS.com/msgâ><WSMsg:symbol>FORD</WSMsg:symbol>
</WSMsg:getQuote>
⢠Example of a simple XML response document with a namespace
<WSMsg:getQuoteResponse xmlns:WSMsg=âhttp://www.WS.com/msgâ ><WSMsg:Result>78.9</WSMsg:Result>
</WSMsg:greetMeResponse>
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 30
3-15SOAP OverviewMore Complex Namespace Example
<?xml version='1.0' encoding='utf-8'?><ENV:Envelope
xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>
<m1:greetMe > <m1:stringParam0 xsi:type="xsd:string">
Hello From WS Client</m1:stringParam0>
</m1:greetMe></ENV:Body>
</ENV:Envelope>
3-16XML TechnologiesXML Schema â Data Typing for XML documents⢠How do we know what elements and attributes to use?
⢠XML Schema provides the way to define an XML document type
⢠So, the structure of a document is expressed in an XML Schema fileâ The schema is an XML document itself â It supplies the definitions of elements and types
⢠XML tools can check if a given XML document conforms to a given XML Schema
⢠Resource: http://www.w3.org/XML/Schemaâ the primer document is quite readable
(http://www.w3.org/TR/xmlschema-0/ )
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 31
3-17XML Technologies
XML Schema Fundamentals
⢠Define XML elements using the built-in and user-defined types:â Simple types
⢠Built-in types (e.g. string, numbers, unsigned bytes, characters )⢠Restricted & enumerated types
â Complex types by composing other types using⢠Sequence (an ordered record)⢠All (an unordered record)⢠Choice⢠Able to specify limits on repetition (e.g., 0 to N, 5 to unlimited âŚ)
using minOccurs, maxOccurs attributesâ So you can create lists
⢠Can access element definitions from other Schema files using the include element
3-18XML TechnologiesXML Schema - examples
⢠Address.xsd â a very simple schema⢠Company.xsd â nested schema â imports two
other schemas:â Person.xsd â referenced by Companyâ Product.xsd â referenced by Company
⢠BookStore.xsd â more complex exampleâ A nested list of nested structures
Each of these specifies it target namespace, using an attribute.For example:
<xsd:schema targetNamespace=âhttp://www.address.orgâ ...
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 32
3-19Address.xsd â simple element with several string components
3-20
Address.xml â consistent with schema
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 33
3-21
Company.xsd â unlimited number of Persons and Products â types from âincludedâ schema files
3-22
Person.xsd â Persontype elements
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 34
3-23
Product.xsd â ProductType element
3-24
Sample Company XML file
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 35
3-25BookStore.xsd â unlimited list of Bookstructures each containing 5 fields
3-26
BookStore.XML
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 36
3-27XML TechnologiesXSLT for Transforming Data⢠eXtensible Stylesheet Language - Transform⢠Need ways to take XML data and transform it to other
forms for various purposesâ XML isnât always the format that you want to work with
⢠Examplesâ Transform XML information into HTML format for web page displayâ Transform XML data to conform to another XML Schemaâ Transform between international representations (dates, currency) â Transform data into several different presentation formats (browser
screen, handheld, pure text âŚ)⢠Actually two specs: XSL (stylesheet language part) and
the Transform part⢠Resource: http://www.w3.org/Style/XSL/
3-28
XSLT Fundamentals⢠Applies transformation rules to elements found in the
XMLâ You tell it what elements to find, and what to output when each is
found
⢠It leverages the XPath specificationâ A powerful way to name nested elements in a document
⢠Uses a nested programming-language-like syntax for matching, repetition, etc. to support complex document parsing
⢠Letâs look at an example
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 37
3-29
XML document containing company info
3-30
(Part of) XSLT for transforming data
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 38
3-31
Transformed Data in HTML format âŚ
3-32XML TechnologiesParsing XML documents⢠Processing XML documents within programs typically
requires XML parsing capabilities⢠Two most popular parsing approaches:
â DOM â Document Object Model⢠Read and represent entire document in memory as a tree of nodes
allowing for easy traversal throughout the document⢠You can modify the tree, and make a call to DOM to tell it to output
the new tree as a documentâ SAX â Simple API for XML
⢠Event driven parsing model that invokes callbacks for major XML elements as they are read from the document
⢠Can be more efficient than DOM for large document processing⢠Used more for extracting sub-document information and specific
processing
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 39
3-33XML TechnologiesOther XML Specifications
⢠XPATHâ XML-based syntax to provide sophisticated access to parts of an
XML document
⢠XQUERYâ An SQL-like dialect for querying parts of varying XML data
sourcesâ Extension to XPATH
⢠XML-Encryption â (to be seen later in more detail)â Process for encrypting/decrypting parts of XML docs
⢠XML-Signature â (to be seen later in more detail)â To ensure origin and integrity of XML docs
3-34Participants in a Web Services Environment:Part 2 - SOAP Technology
XML documentswithin
SOAP messagesdefined by
WSDLdiscovered via
UDDI
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 40
3-35SOAP OverviewStructure of a SOAP Message
⢠A SOAP message consists of:â Envelope - identifies the message boundary and
includes:⢠Header - contains meta-data/auxiliary (optional)⢠Body - contains the request and response XML
documents
EnvelopeHeader
Body
⢠Fault informationmay also besupplied â notshown here
⢠Often the header contains system level data (see later chapters)
3-36SOAP OverviewSkeleton SOAP Message in XML
<?xml version="1.0"?> <soap:Envelope xmlns:soap=â ... ">
<soap:Header>... ...
</soap:Header><soap:Body>
... ... < ⌠message payload goes here ⌠>
</soap:Body></soap:Envelope>
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 41
3-37SOAP OverviewOur Simple Example â in SOAP
<?xml version='1.0' encoding='utf-8'?><ENV:Envelope
xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>
<m1:greetMe > <stringParam0 xsi:type="xsd:string">
Hello From WS Client</stringParam0>
</m1:greetMe></ENV:Body>
</ENV:Envelope>
3-38SOAP OverviewSimple Example Response â in SOAP<?xml version='1.0' encoding='utf-8'?><ENV:Envelope
xmlns:ENV="http://schemas.xmlsoap.org/soap/envelope/"xmlns:ENC="http://schemas.xmlsoap.org/soap/encoding/"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:xsd="http://www.w3.org/2001/XMLSchema"xmlns:m1="http://IONA.com/HelloWorld"><ENV:Body>
<m1:greetMeResponse> <return xsi:type="xsd:string">
Echo: Hello From WS Client</return>
</m1:greetMeResponse></ENV:Body>
</ENV:Envelope>
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 42
3-39SOAP OverviewSOAP Processing
⢠Within the SOAP environment, the software responsible for the generation, transmission, reception and analysis of these messages is known as a SOAP Processor
⢠These processors can be standalone listeners on TCP portsâ Accepting incoming SOAP messages and passing them up in
the stack
⢠Also, most Web Servers include a SOAP processorâ but if your Web Server doesnât include a SOAP processor, then
most Web application development environments allow you to add a âSOAP plug-inâ.
3-40Participants in a Web Services Environment:Part 3 - WSDL Technology
XML documentswithin
SOAP messagesdefined by
WSDLdiscovered via
UDDI
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 43
3-41
WSDL Technology
⢠Web Services Description Language⢠WSDL is the KEY to using Web Services
â WSDL provides an OS-, platform- language-neutral definition of a Web Service
⢠THE contract between Web Service provider and consumer
⢠Completely describes a Web Service:â Messages and types of data used in messagesâ Operations with associated in and out messagesâ Bindings of operations to transportsâ Physical location of service (endpoint) specifications
⢠Large and complex standard, continually undergoing development and proposed extensions
⢠Reference: http://www.w3.org/TR/wsdl
3-42WSDL OverviewMajor WSDL Elements
Part
Type
Message
Operation
PortType
Binding
Port
Service
Logical aspects
Physical aspects
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 44
3-43WSDL OverviewMajor WSDL Elements
â binding: specifies concrete protocol and data formats for the operations and messages defined by a particular portType.
â port: specifies an address for a binding, thus defining a single communication endpoint.
â service: used to aggregate a set of related ports.
⢠The top level XML element is the definitions element<definitions> . . . </definitions>
⢠Services are defined using eight major elements:â types: data type definitions used to describe the messages exchanged. â message: abstract definition of the data being transmitted in a
message. A message consists of logical parts, each of which has one of the defined types.
â operation: Each operation can have an input message and an output message.
â porttype: a set of operations.
3-44WSDL OverviewThe <types> element
⢠Types are specialized building blocks for data content exchanged via Web Services
⢠Normally the <types> element uses XML Schema to define types and elements used in the WSDL documentâ But another type system could be used (this isnât very well
defined now)⢠So normally specified in terms of XML Schema
constructsâ Simple typesâ Complex types â including sequences and nested structures
⢠E.g. a purchase order with multiple items
⢠Weâll see examples of these later.
Part
Type
Message
Operation
PortType
Binding
Port
Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 45
3-45WSDL OverviewThe <message> element
⢠Messages are the packaging of data that are transferred (in or out) via web service operations
⢠A message can contain zero or more partsâ And each part can contain one element or one type
Part
Type
Message
Operation
PortType
Binding
Port
Service
3-46WSDL OverviewThe <operation> element
⢠An operation can have an input message and an output message
Part
Type
Message
Operation
PortType
Binding
Port
Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 46
3-47WSDL OverviewThe <porttype> element
⢠A <porttype> is a collection of named operationsâ each with an input and/or an output message
⢠This is the key to the logical definition of a web serviceâ What operations are available for accessâ What input message is required for each operationâ What output message is generated by each operation
Part
Type
Message
Operation
PortType
Binding
Port
Service
3-48It may help to view the Logical aspects as follows:
Part
Type
Message
Operation
PortTypeLogical aspects
// interface
// method
// the messages that flow// in and out of an operation
// parameters
// type of parameters
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 47
3-49Letâs look at our simple example,within a WSDL file ⌠HelloWorld.wsdl
3-50WSDL OverviewThe <binding> element
⢠The <binding> element specifies how the logical content (messages, operations) is mapped onto transports for exchange between requestor and provider
⢠HTTP + SOAP are the predominant binding options, but many more are becoming available to support integration throughout and among enterprises
⢠Note that multiple bindings for the same PortType are possible!
Part
Type
Message
Operation
PortType
Binding
Port
Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 48
3-51WSDL OverviewThe <port> element
⢠The <port> element specifies the physical location/destination for sending the service requests
⢠Typically supplied as a URL
Part
Type
Message
Operation
PortType
Binding
Port
Service
3-52WSDL OverviewThe <service> element
⢠The <service> element specifies a collection of ports âI.e. locations where the operations of the service are accessible to potential service requestors
⢠Typically, the ports of a service refer to the different locations where the different possible bindings specified elsewhere in the WSDL file are implemented and available
⢠Example: one port may supply the location where HTTP is the transport binding, another port may supply the location where it is FTP
⢠Letâs look at the rest of our simple example within a WSDL file ⌠HelloWorld.wsdl
Part
Type
Message
Operation
PortType
Binding
Port
Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 49
3-53
HelloWorld.WSDL
3-54WSDL OverviewA Few Concrete WSDL Examples
⢠Stock Quote WSDL â remotely stored WSDL file at Xmethods.netâ Simple data model and operations list used for our early
demo
⢠WS-I Manufacturer WSDL file (Warehouse.wsdl)â Imported schemas, shared among different WSDL filesâ Sample request and response SOAP messages
documented in the fileâ Documentation discipline â commentary, headers, etc.
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 50
3-55
Stock Quote WSDL File
3-56
WS-I Warehouse WSDL
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 51
3-57
WSDL Element Relationships
Part
Type
Message
Operation
PortType
Binding
Port
Service1
*
1,2
*
*
*
1
1
Logical aspects
Physical aspects
3-58Web Service Technologies RelationshipsRun time vs Design Time
E.g.,HTTP
Client WebService
SOAPRequest
SOAPResponse
XML
Run
time
exec
utio
n
WSDL Specifies âŚ
Operations,Structure and
Typing of Messages
EncodingAnd Transport of
Messages
PhysicalEndpoint
ServiceCommunicationsRequirements:
Des
ign
and
Dep
loy
time
XML Schema
<portType> <binding> <service>
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 52
3-59Participants in a Web Services Environment:Part 4 - UDDI Technology
XML documentswithin
SOAP messagesdefined by
WSDLdiscovered via
UDDI
3-60
UDDI Technology
⢠Universal Description, Discovery and Integrationof Web Services
⢠Sponsored by the OASIS organization⢠Supports the ability to register and find services
on the internetâ Service Providers register/publish services including
WSDL file along with searchable attributesâ Potential clients search UDDI registries to retrieve
WSDL suiting their service needs⢠Resource: http://www.uddi.org
UDDI is the least accepted of the SOAP, WSDL, UDDI triangle. It is overly complex, and over burdened by a lot of business level aspects (e.g., descriptions of a business).
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 53
3-61UDDI OverviewUDDI â APIâs
⢠Defined by â what else by â WSDL filesâ UDDI services are Web Services !
⢠Register/publish web services APIâ Register_WSDL for publishing â Major operations: save_service, save_binding, âŚ
⢠Inquire for web services APIâ Inquire_WSDL for inquiringâ Major inquire operations: find_business, find_service,
find_binding, get_binding_detail,get_service_detail, âŚ
3-62
Sample UDDI Registry Listing
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 54
3-63Correlating the WS StandardsWeb Services Interoperability Organization (WS-I)⢠Web Services depend heavily on agreed-upon standards
(XML, SOAP, WSDL, etc.) that are relatively independent of each other
⢠Keeping up with the changes and nuances that exist among these is difficult and time-consuming
⢠WS-I has the mission of doing this for the IT industryâ advising on how to use these WS standards appropriately and
interoperably⢠Primary deliverables:
â Basic Profile 1.0: this supplies advice about which combinations of the standards should be used together, and which features should be avoided or emphasized from each standard
â Test Tools for verifying compliance with the Basic Profileâ Sample Applications for assisting others in building compliant
systems⢠Visit http://ws-I.org/ for more details âŚ
3-64
Conclusions
⢠Web Service technologies allow the exchange of XML documentsâ XML, XML Schema define data to be exchangedâ SOAP is the protocol used for the exchange of the dataâ WSDL specifies the details of services, messages, and endpointsâ UDDI supports the publishing and locating of services
⢠The platform-, OS-, programming language-neutral aspects of Web Services allow heterogeneous environments to interoperate easily
⢠Defining the information/data structures/messages is central to the overall processâ Utilize the XML Schema and WSDL types facilities to represent
your data appropriatelyâ Let development tools provide automatic mappings between
programming language structures and Web Services structures
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 55
3-65Participants in a Web Services Environment:Review
XML documentswithin
SOAP messagesdefined by
WSDLdiscovered via
UDDI
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 57
1
Chapter 4Web Services Tools and Demo
Typical Tools for Design, Development and Deployment of Web ServicesWith demos of creating simple WS clients and WS servers
Version 11
24-2
WS tools and demos â the âHow Toâsâ of WS
⢠Tools are needed for:â Creating/defining XML documents and schemasâ Creating/modifying service definitions/WSDL filesâ Mapping WS artifacts to/from programming concepts
⢠Both directions may be needed depending on the integration scenarioâ Managing and locating deployed Web Services
⢠Some typical and available tools:â XMLSPY â General Purpose for XML docs and WSDL filesâ Artix â C++/Java-based Web Services
⢠Enterprise Web Services & middleware integration toolkit from IONAâ VS.NET tool set - Microsoftâ J2EE/App Servers â J2EE in general â e.g. EJBâ Many vendors and many tools, ⌠and more everyday
⢠IONA, IBM, Sun, BEA, Cape Clear, Altova (XMLSpy), etc.
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 58
34-3
Building a Web Service - Two Basic Approaches
⢠From Scratch â a new application or systemâ Start with WSDL and/or data/message schemas and produce
the application using generated application building artifacts:⢠âblankâ client and server, client-side stubs & server-side skeletons
â Write the business logic in the âblankâ serverâ Fill out the âblankâ client code
⢠From Existing Systems â eitherâ Automatically derive the WSDL from the existing interfaces for
the application or from data schema files⢠There are automatic WSDL generators for CORBA IDL, Java
classes, J2EE EJBs, COBOL, other middleware (MQ, Tuxedo,âŚ), message/XML Schema files, . . .
⢠Often you have to enhance the generated WSDLâ Do a top down design of the WSDL, and implement the service
using new code and the existing systems⢠You may get better WSDL. Remember that one of the main goals of
a service is to keep its clients simple.
44-4Diagrams to show these Development Approaches
WSDL File WS ServerEndpoint
Existing AppExisting App has an APIExtract WSDL from APIBuild client and server skeletonClient calls App API through WS
Extract WSDL
WSDL File WS ServerEndpoint
Create serverServiceDesign a WSDL (top down)
Create client and server skeletonImplement server/service codeClient calls service through WS
WSDL File
WSDLEditor
Create/Edit WSDLDesign/update the WSDL Utilize in above scenarios duringdevelopment/evolution of system
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 59
54-5
Typical WS Development/Deployment Components
64-6
Development Demo Scenarios âŚ
⢠Automatic client generation â Seeing WS clients in action âŚ
⢠Hello World â VB.NET client creationâ Local Artix server
⢠Stock Quote â VB.NET client creationâ Our original example - again
⢠Hello World â VB.NET Web Service Creation
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 60
74-7
Automated WS Client Generation
⢠A number of tools available for this task⢠Generate Java, VB, C#, Javascript, ASP, JSP and other⢠We will use Web Services Studio 2.0
â Freeware product â 114KB â simple installâ Reads/analyzes a WSDL file, located anywhere on the netâ Creates/displays automatically generated client/proxy codeâ Simplifies the invocation of WS methods with arbitrary inputs, and
then viewing the response messagesâ Can view the actual SOAP messages involved
⢠Available from:⢠http://www.gotdotnet.com/ - locate WebServiceStudio 2.0 page⢠Requires .NET SDK environment
⢠Letâs see it in action âŚ
84-8
Screen Shot â WS Studio 2.0
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 61
94-9Web Service Client Created and Executed
104-10
SOAP Messages to/from Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 62
114-11
WSDL File display
124-12
Generated Proxy Code
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 63
134-13
Generated Client Code
144-14
A Different Stock Symbol ⌠and result
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 64
154-15A Different Stock Quote â the SOAP messages
164-16A Different Stock Quote Web Service âmore operations & more data returned
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 65
174-17
Writing Client Code â Simple Examples
⢠Using Visual Basic within Visual Studio.NET⢠Simple, unpolished examples⢠Illustrate the underlying theme of ease of access
to Web Services from most development environments
⢠Major building stepâ Add a âWeb Referenceâ to the current projectâ Based solely on a WSDL file specification:
⢠Local/remote file system⢠Remote URL
184-18
HelloWorld VB.NET Client
⢠Use a remotely stored WSDL file (HelloWorld.wsdl) on our demo systemâ Simple data exchange serviceâ Only two operations â greetMe and sayHi
⢠Create a simple client (using VB.NET)⢠Execute the client to invoke a remote service
â Server written in C++ using IONA Artix product running on a remote server
⢠Letâs do it!
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 66
194-19
204-20
Windows Application for our Examples
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 67
214-21
Key Step: Add a Web Reference
224-22
Add Web Reference Dialog
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 68
234-23
Create a Proxy object to WS server
244-24
Invoke operation via Proxy Object
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 69
254-25
264-26
Web Service response
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 70
274-27
Invoke another operation
284-28
Service response
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 71
294-29
Web Service Server Log
304-30
StockQuote Client
⢠Externally available serviceâ WSDL file discovered using WWW.XMETHODS.NET siteâ StockQuote WSDL file
⢠Simple data interface â strings in and out⢠Single operation - getQuote⢠Build simple client from the WSDL and then execute the
serverâ Donât even know how the service is implemented or where
located physicallyâ But it doesnât matter!
⢠Letâs do it - again
⢠See a slightly more advanced version of a client
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 72
314-31
Add Web Reference Wizard
324-32
More client code â invoke Stock Quote
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 73
334-33
344-34
A VB.NET Client to StockQuote Web Service
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 74
354-35
Creating a Web Service from Language Constructs
⢠Within most Web Service tools, it is easy to expose a function/method as a web service
⢠With VS.NET, we simply create an ASP.NET Web Service application, and add to any public function declaration(s) the attribute:
<WebMethod()>
⢠This allows the .NET framework to supply the necessary WS aspects to expose the method as WS operation and invoke from a remote client
⢠Letâs see simple illustrations of this using VB.NET âŚ
Implementing a service
364-36
Create a Web Service Project âŚ
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 75
374-37Generated Source File âŚ
384-38
Add Code by removing comments
Need to Build the solution from here âŚ
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 76
394-39
Using WS Studio Client â for SOAP
404-40
SOAP Messages to/from Server
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 77
414-41
Additional Operation: with a parameter
424-42
Invoke the service with a parameter
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 78
434-43Invoke the service via HTTP âŚ
Right click here
444-44
HTTP Response â instead of SOAP!
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 79
454-45
Server Code Generation
⢠Web Service ToolKits can also generate server side code skeletons directly from WSDL files
â Java, C++, CORBA and other environmentsâ Typically a collection of classes and interfaces
⢠Then the programmer must add the code to implement the operations (possibly implementing them using existing systems)
⢠Last step is to deploy the server side implementation into the web service container, to allow it to be invoked by remote clients
⢠No time to do here, but a later section describes how this was done for a Java-based environment (WSID)
464-46
Tools to create WSDL files
⢠XMLSPY â somewhat generic XML support, but it can be made to work OK for WSDL
⢠WSDL support embedded in other tool sets â Microsoft Visual Studioâ BEAâs WebLogic, etc.
⢠Visually oriented (GUI) WSDL construction tools becoming available â See next few slides for a sample tool (IONAâs Artix)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 80
474-47
Top level WSDL structure
484-48
Detailed WSDL element wizard - Port
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 81
494-49
Summary of Development Demos⢠These capabilities are available in most WS toolsets
⢠Simple to access remote service WSDL files to:â Create simplistic clients for immediate access/testingâ Create simple client in programming language of choiceâ Create stubs for server components
⢠These tools mean that you donât need to understand the details of WSDLâ The tools handle the WSDL, and give you stub and skeleton
functions that you can use to program your clients and services.
50
Web Services Execution DemoWeb Services Interoperability Demo (WSID)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 82
514-51
A Web Service Case Study
⢠Web Services Interoperability Demo (WSID)⢠Group of industry vendors (IBM, Microsoft, IONA, The
Mind Electric, Amberpoint, WebMethods âŚ)⢠Joint development of specs and implementations⢠Development done globally, demonstrated at numerous
trade shows (e.g., XML-ONE)⢠Multiple platforms, OS, programming languages
â .NET, several J2EE systems, straight Java, and some unknown!
⢠WSDL files as the key definition / specification for the project
⢠Tony Hong of XMETHODS.NET was the technical leaderhttp://www.xmethods.net/wsid-03-2003/
524-52
Web Services Interoperability Demo
Client
Warehouse
Supplier
Warehouse Floor: Embedded WS Client
5. Ship Confirm
1. Send PO
4. Ship Request
3. Charge
Bank
2. Check Inventory
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 83
534-53
WSID Architecture
Customer
Supplier
CreditBureau
Warehouse
debit()
checkAvailability()
getCatalog()sendPO()getPOStatus()getInvo ice()
shipRequest()
shipCon firm()
Bank
Charge()
WarehouseGUI
WarehouseGUI
GUI
XARFiles
(Local orRemote)
Deployment
ConfigControlFiles
(Remote)
Initialization
RunTimeFiles
(Local)Run Time Logging
(Remote)
Real Time Logging and display tools
.NET clientwill be shown
544-54
Building Web Service-based Application
From Xmethods
Initial Code
Initial Code
Deployment
ImplementTo WSID
Specs
Build/Rebuild
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 84
554-55
.NET (VB) Client for WSID
564-56
Java Swing Client for WSID
Letâs see WSID in action âŚ
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 85
574-57
Logging screen shot
584-58
Browser view of logs
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 86
594-59
WSID Demo Summary
⢠What we saw in this demo âŚ
⢠Multiple interacting web services⢠Implementing a typical Supply Chain Example⢠Multiple Language GUI Clients⢠Web Service server also acting a Web Service client
⢠Each of these components has been implemented by a set of WS vendorsâ And it has been tested with arbitrary selections of these
components, running on machines distributed across the US!
604-60
Chapter Summary
⢠Web Services are real â here and now -â You can design, develop and deploy with them now â Both for internal use and between enterprise vendorsâ Existing services can be discovered and accessed easily
⢠Many tools available with varying degrees of maturity and complexity â and more to comeâ Evolution of tool capabilities ultimately drives ease of use of WS
⢠The most interesting part of designing a system with Web Services is the high-level architecture of the systemâ What services should exist, and how should they interact?â What is the right structure for the information that should pass
between clients and services?â These are the topics of the next chapter
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 87
Chapter 5Service Oriented Architecture
Version 6
25-2
Overview
â A guiding analogyâ Terminology excursion
⢠Service, interface, architecture model, architecture style, service-oriented architecture
â Benefits of service-oriented designâ Successful example of service-oriented designâ What does this mean to you?
⢠How to prepare for SOA
â Summary
Ok, now we understand the Web Service technology, but how about Service Oriented Architectures?
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 88
35-3From just using a Web Service to
having a Service-oriented architectureIntermediate stage: Individual services broken out
Application
Application
service
service
Application
Application
service
Service-oriented architecture
service
service
service
service
Application
Monolithic applications
Application
45-4A guiding exampleBank Teller analogy for service-orientation
⢠Different types of tellers offer different servicesâ Tellers specialized to perform only certain types of transactions (which
are typically closely related)â Example partitioning:
⢠Account Management (Opening and closing accounts)⢠Credits (inquiry about conditions, consulting, applying for mortgages)⢠Cash Register (Withdrawals, deposits, funds transfers)⢠Currency exchange (buy and sell foreign currencies)
⢠There may be several tellers offering the same set of services (for load balancing / failover)
⢠What happens behind the counter is not your business (bulletproof glass, iron bars)
⢠If you require a complex transaction, you may have to visit several tellers (customer as transaction coordinator)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 89
55-5Terms and DefinitionsService (Definition)
â A service is a package of closely related standardized functions, which are called repeatedly in a similar fashion, and should therefore be implemented by a dedicated facility, which can be specialized to perform them.
Example: Account Management
â A service can be partitioned and have multiple service functions.
Example: Open new account
â The smallest subunits within service functions are called service primitives.
Example: Generate next available account number
65-6Terms and DefinitionsCharacteristics to completely describe a service
â Service requester (âclientâ)⢠Who/which components use or need the service?⢠For the service requester, the provided service is most important, and
not how it is implemented (principle of information and implementation hiding)
â Service provider (âserverâ)⢠Who/which components implement or provide the service?⢠is responsible for hosting the service, and ensuring the promised QoS⢠may charge for service usage
â Qualities of Service (QoS)⢠What are the parameters that allow to distinguish good service
provisioning from bad?⢠Examples: Reliable, predictable execution, cost, execution time, level of
privacy, other guarantees
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 90
75-7Terms and DefinitionsInterface (Definition)
⢠An interface constitutes the specification of a service, that is implemented by a certain component. The interface defines a contract, to which the component that implements it has to comply.
⢠Signature of interfaces can be described using formal languagesâ Web Services Description Language (WSDL)â OMG/ISO Interface Definition Language (IDL) (for CORBA)â UML Object Constraint Language (OCL)â But also: Java, C++ headers, . . .
⢠Type-safe interfaces sometimes introduce tight couplingâ Web Services donât force you into type-safe interfaces
⢠Different message types may be acceptable to a service
85-8Terms and DefinitionsSoftware Architecture (Definition)
Software architecture encompasses the set of significant decisions about the organization of a software system
⢠selection of the structural elements from which the system is composed, and the interfaces to these
⢠behavior as specified in collaborations among those elements
⢠(de)composition of these structural and behavioral elements into a larger system
⢠architectural style that guides this organization
Mary Shaw (Carnegie Mellon Univ.)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 91
95-9
⢠An architectural style defines a family of systems in terms of a pattern of structural organization [Garland/Shaw 96]
⢠An architectural style defines:â a vocabulary of design elements
components (client, server, filter, layer, adapterâŚ), andconnector types (pipe, broadcast, queue,...)
â a set of configuration rules (constraints) on how they can be combined
⢠Example styles in Software Architecture: Event-based, Repository-based, virtual machines, layered
Terms and DefinitionsArchitectural Style (Definition)
105-10
⢠The architectural style of an application is called service-oriented if it meets the following criteria:â It is not monolithic; common blocks of functionality are broken
out of the applications and are instead provided by services⢠A significant part of the overall functionality is implemented by services,
which exist otherwise independent of the applicationâ Design elements for an SOA are:
⢠Components: Services (can be composites), consumers, providers⢠Connector type: (Remote) Service invocations
â Configuration rules for an SOA are: ⢠No strict layering (Service implementations can use other services)⢠No centralized control entity⢠Services are designed for shared use, and for use that may not even
have been anticipated at design time
Terms and DefinitionsService-Oriented Architecture (SOA)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 92
115-11
⢠Service-Orientation is an organizational principleâ A set of principles for building large systemsâ It is not tied to any particular technology
⢠Examples:â Common âhorizontalâ services:
⢠Logging, authentication/single-sign-on, systems management, Directory lookup of services, event notification
â âVerticalâ services, specific to your business domain⢠Product feature search service, Address management,
Order Status Tracking Service, Truck/trailer tracking service⢠As in organizations, there is always more than one way
to structure a large system⢠The most important question: How to decompose?
â What is the guiding abstraction mechanism?â Why would one favor one decomposition for another?
Terms and DefinitionsService-Orientation
125-12Terms and DefinitionsQuality criteria for (software) architectures
Q: What makes one decomposition better than the other?A: Depends on the priorities of your requirements!
⢠Quality criteria used to measure the result:
1. Derived from top rank use cases (adequateness)2. Balanced with existing assets: platform technology,
frameworks, components3. Balanced with requirements (trade-offs, performance vs. security,âŚ)4. Compliance with (domain-specific) industry standards and
reference models (interoperability, readiness for merging)5. Designed to make the system more resilient to future
changes (20 years?) (maintainability)6. Designed for substantial reuse, and with substantial reuse7. Intuitively understandable (people buy-in!) (usability)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 93
135-13Terms and DefinitionsForces and quality factors for software arch.
FunctionalitySoftwareArchitecture
Fault Tolerance
PerformanceCostThroughput
Capacity
Availability
Interoperability Fail safe
Maintainability
Scalability
145-14
Challenges and problems
⢠Technology heterogeneity of existing applications⢠Many integration projects during the last three years
â Have been tactical, not strategic (no enterprise focus)â Only solved problems for one project (e.g. for one channel)â Result: Stovepipe integrations
⢠Large organizations run literally hundreds of packaged applications and often even multiple ERP systems
⢠These systems were designed as stand-alone and independent of each other
⢠They overlap in functionality ⢠They overlap in the data they manage
â Integration does not remove any overlapâ Consolidation would be better
⢠SOA helps to address these issues
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 94
155-15
Benefits of service-oriented design (1)
⢠More flexibility (âbusiness agilityâ)â Assumption: business process logic and business rules are no
longer buried inside applicationsâ Result:
⢠Since they are now explicit, processes can be changed easier⢠Existing services can be used in different contexts⢠Shorter time-to market for changed processes
⢠Reduced cost of operation through consolidationâ Assumption: Redundant functionality is eliminatedâ Result:
⢠Fewer servers ⢠Fewer licenses ⢠Fewer assets to manage ⢠Lower maintenance cost
165-16
Benefits of service-oriented design (2)
⢠Higher qualityâ Eliminating redundancy will reduce inconsistent data and
inconsistent behaviorâ More transparencyâ Improved system architecture â easier to understand
⢠Reduced risk, cost and complexity for developmentâ Clean architecture â reduced cost and riskâ Increased developer productivity through reuse
⢠Projects can leverage existing servicesâ âBlack boxâ reuse instead of copy&paste reuse
⢠Lessen the dependencies on vendorsâ Service implementations can be replaced as long as interfaces
stay the sameâ Services can be relocated from one platform to anotherâ Services can even be outsourced to an external provider
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 95
175-17
Benefits of service-oriented design (3)
⢠Good service design (partitioning) will outlive your middleware or implementation technologyâ All you have to do is to put a wrapper around it, if requiredâ Many mainframe systems today provide many useful services that
should be made available to applications elsewhere in the enterprise⢠Commoditizing more and more parts of the IT infrastructure
â Off-the-shelf infrastructure components are moving up the layers and coming closer to the application!
â Due to existing industry standards and available products, developers stop building this stuff themselves:
⢠1990: DBMS, TP Monitors⢠1992: Networking stacks⢠1995: CORBA, RPC Middleware, Reliable Messaging⢠1998: Naming Service, Publish and Subscribe, Event Notification⢠2000: Various J2EE Services
185-18Case StudyCredit Suisseâs Enterprise Architecture Model
OS/390OS/390OS/390 OS/390OS/390OS/390 OS/390OS/390OS/390 OS/390OS/390OS/390OS/390OS/390OS/390
JavaJavaJava CORBACORBACORBAJ2EEJ2EEJ2EE COMCOMCOM C++C++C++
Credit Suisse Information BusCredit Suisse Information BusCredit Suisse Information Bus
Ă Implementedstandards-based interfaces everywhereâŚ
Ă âŚand then enabledservices-oriented access to all applicationsystems.
ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService
ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService ServiceServiceService
ServiceServiceService
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 96
195-19Case StudyCredit Suisseâs Enterprise Architecture Model
"There is no need for us to dismantle our existing infrastructure to deploy on-line business opportunities. IONA enables us to leverage multiple technology generations in a flexible system, which ensures shorter development cycles and investment protection.â
Stephan Murer, Credit Suisse
§ 500 business service
§ 50-plus front-end composite applications
§ 100,000 users
§ 7 million service invocations per week
205-20
What does all this mean for you? (1)
⢠Your role: Developer or Software Architectâ Project-focused (âget this doneâ)â Success metric: Project / deliverable completed in timeâ Goal: Minimize time and cost of developmentâ Granularity of re-use: class libraries, source code,
classes, frameworks⢠What you need to do
â be familiar with Web Services standards and technologies
â get your feet wetâ be aware of existing services in your enterprise
⢠try to (re)use them as much as possible
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 97
215-21
What does all this mean for you? (2)
⢠Your role: Enterprise Architect or CIOâ Enterprise- or infrastructure-focusedâ Success metric: Resourcefulnessâ Goals: Minimize TCO across projects, reduce
complexity, maximize âbusiness agilityââ Granularity of re-use: services, infrastructure
⢠What you need to doâ understand Web Services technologiesâ define the roadmap, act as catalystâ define the business architectureâ work for the application teams and encourage them to
use the services of âyourâ infrastructure
225-22
Summary
⢠Precise terminology helps â to understand and handle the problemâ to identify and debunk unbaked concepts
⢠Service-orientation is an architectural style⢠Web services are a good technology to build
service oriented architectures â Simple, easy to understandâ Inexpensive technology, no major investment neededâ Can start small and proceed incrementally
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 99
Chapter 6Web Service Design Aspects
Version 7
6-2
Web Services Design Aspects Overview
⢠Introduction⢠General Design Guidelines⢠Best practices
â For the design of individual Web Servicesâ For the design of a collection of Web Services
⢠Organizational guidelines⢠Summary
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 100
6-3
Introduction
⢠Clean design and adequate architecture are more important than tools and GUIs.
⢠A well designed service can outlive the application context in which it was designed.
⢠What best practices can one follow to develop an architecture that can successfully evolve over the next 20 years?
⢠Once you start designing services, are there any design rules and guidelines?
6-4
General Design guidelines (1)⢠Re-use existing Web services
â Avoid duplication of servicesâ Encourage developers and architects to use existing services
wherever possible⢠Small is beautiful
â You canât redesign your whole enterprise IT in one shot, therefore start with small teams and small projects
â Get developers gradually used to the ideaâ Simple Web services first, just to get used to the technology
⢠Take the concept of service registries and dynamic services lookup with a grain of saltâ Any introduction to Web Services must mention the purist âtriangleâ
⢠service provider â service registry â service clientâ But no service registry may be needed for your first experimentsâ The need for a registry will grow with your environment
⢠But dynamic look up based off a set of properties will often be inappropriate for all but initial toy systems that youâll build
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 101
6-5
General Design guidelines (2)
⢠Donât repeat the mistakes of the pastâ Web Services are not silver bullets. There are none!â New technologies often have great features, but they take time to
mature. Web services lack certain capabilities that took other middlewares a decade to get right
⢠Use the right tool for the right jobâ Use Web Services
⢠for âlarge grainedâ operations ⢠when interoperability is key and tools from different vendors are involved⢠when the underlying business problem is already document-oriented
â Use other Middleware (CORBA, MQ, J2EE, .NET, âŚ) where it is better suited
⢠for small-grained, more âlocalâ operations/services (components rather than services)
⢠for ultra-high performance requirements⢠for projects with sophisticated QoS requirements which cannot wait
for Web services to mature
⢠Consider a technology mix
6-6Best practicesDesign of individual Web Services (1)
⢠Design Web Services with a clear scope and purposeâ Usage, purpose and value (!) must be easy to understand
⢠Design Web Services as open and sharedâ This is the key difference from point-to-point integrationâ Benefits of services only achieved if they are (re)used across
multiple application systemsâ The higher the amount of sharing, the higher the value of a serviceâ Shared â reuse
⢠Web Services are not inherently statefulâ Core standards donât provide the concept of a session âmemoryâ
⢠If you need logical connection between messages, you have to take care of this yourself
⢠Standards for this are under development (WS-CAF, WS-CTX, see Advanced Topics)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 102
6-7Best practicesDesign of individual Web Services (2)
⢠Donât ignore performance aspectsâ Location transparency does not mean that usage of a Web
Service should be treated like a local function callâ Donât ignore network latencyâ Bundling several short messages into one, with a larger payload,
will result in better performanceâ Consider offering different operations with different granularity to
reflect usage patterns for a wide range of client types⢠Transaction requested from a J2ME-enabled phone: One at a time⢠Transactions requested from partner: batch! (hundreds, thousandsâŚ)
⢠Find compromise for granularityâ If more work gets done in one invocation, the service is typically
more specific and more difficult to re-use
6-8Best practicesDesign of individual Web Services (3)⢠Properly encapsulate underlying applications
â Do not allow limitations of underlying applications or products to influence your Web service interface design (too much)
⢠Scenario: existing mainframe application uses 5-digit account numbers⢠Trade-off: thin-layer (expose the 5-digits), vs. introducing a mapping
layer to make the Web service more future-proofâ Avoid âblob-typeâ messages
⢠Scenario: existing application produces complex return message for transactions, non-trivial to parse
⢠Trade-off: leave it as is (a long string) & burden client with interpretation vs. parse the string & return an XML sequence
⢠Encapsulate underlying middlewareâ Do not allow the underlying middleware to show through Web
Services interfaces. Hide protocol and encoding dependencies!â The granularity of existing middleware service interfaces may not be
right to expose âas isâ as Web Service interfaces
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 103
6-9Best practicesDesign of individual Web Services (4)
⢠Benefit from WSDL type safety and schemasâ Use the built-in primitive and complex data typesâ Rely on schema validation by an external parserâ Do not encode additional information in attributes, even if the
underlying application does⢠âIf zip code is <00000>, this means that the address is abroadâ
â SOAP with Attachments allows transmission of binary data, butâŚâ˘ Use binary data only where appropriate (for payload), otherwise many
XML benefits will be lost (filtering, content-based routing,âŚ)
⢠Have well defined interfaces and policiesâ There is more to an interface than just the signatures in the WSDLâ Semantics is equally important, but hard to formalizeâ âQuality parameters of serviceâ (availability, security, âŚ) and error
handling are also part of the contract
6-10Best practicesDesign of individual Web Services (5)
⢠Web Services doesnât provide a versioning mechanismâ For now, itâs up to you to find a way to handle change
management. E.g., ⢠assign different ports to different versions
â Or use one port but use naming conventions to distinguish the operations that apply to different versions
⢠Design your services to ignore elements of a message that it doesnât recognise, so it can accept extended messages from a new version of the interface
â This isnât always safe.
⢠Donât call it a service, againâ The name of the Account Management service is
âAccount Managementâ, not âAccount Management Serviceâ
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 104
6-11Best practicesDesign of multiple services (1)⢠Services should use other services wherever possible for
common tasksâ Example: authentication, logging, etc.
⢠Design Web services orthogonal to each otherâ Avoid redundancy and functional overlap
⢠Any exceptions to that rule have to be scrutinizedâ Some call this rule the âBauhaus Principleâ
⢠Web service usage should not have hidden side effectsâ The service implementation should do only what its specification
says it does, and nothing else⢠Donât break the encapsulation when communicating
between servicesâ Service implementations may use each other, butâŚ
⢠A service should not bypass another serviceâs interface by going directly to the underlying implementation of it
6-12Best practicesDesign of multiple services (2)⢠Collections of related Web Services should use the same
type system (and the same formatting and semantics for the elements within these)â Transformations at runtime are (still) expensiveâ Wherever available and applicable for your vertical, find and use
standardized schemas/DTDs, vocabulary, format conventions, ⢠Type-level: encoding for money/currencies, date/time, etc.⢠Element-level: address, patient, funds transfer, tax payer information⢠Schema-level: Hundreds of specific XML-based languages exist for
every vertical, from Court Filings (Legal XML), Clinical Data Interchange, to Financial Products (FpML)
⢠Try to make Web services coarse-grained and consume coarse-grained parameters. Two reasons:â Sending a series of many short messages takes longer than
one with a larger payload (network latency!)â Business people find it easier to understand coarse-grained calls
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 105
6-13Best practicesFor the organization (1)⢠Encourage, and reward (re-)use of Web Services
â Make reuse a virtue; give incentivesâ Monthly award for the team/developer whose Web service was
reused the most that monthâ Charge-back system, where the internal users of a WS reward
those that implemented itâ Awards for team/developers who build new applications writing
the fewest lines of new code.â Make sure your annual salary reviews encourage use of Web
services in your SOA⢠Enforce Web services reuse
â âmost effective tack [âŚ] has been punishment for not reusing [services]âŚâ (Gartner analyst Michael Blechar)
â Have Architecture Gurus (no committee), who need to approve exceptions when existing services are not used
â Have people who work between projects and teams to encourage re-use (see later)
6-14Best practicesFor the organization (2)⢠âBuild it, and they will comeâ
â Web Services will be re-used⢠If they are good quality, and have good documentation, and⢠are advertised well, and⢠you encourage reuse in your organisation
â Every development project is done under time pressure. If using existing Web Services allows them to get there faster with manageable risk, they will use them!
⢠Have a Web services registry and a roadmap of future onesâ Publish this to your developersâ Identify low-hanging fruit and consider potential risk/benefit â Look for best practices in your vertical domain (are there
existing/relevant reference models?)â Enterprise-wide services infrastructure can only be built step by step
⢠Keep an eye on internal integration projectsâ Evaluate those already ongoing!
⢠They might be building another stove-pipeâ With little more effort, they might be building new services
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 106
6-15Best practicesFor the organization (3)⢠Educate your architects and developers on services and
re-use⢠Do your marketing
â Communicate! (and constantly collect feedback)â Advertise benefits of Web service usage, advertise successesâ Create and provide precise documentation and descriptions of
servicesâ interfaces⢠Give exact description of semantics of parameters⢠Precise description of the behavior
â Give regular presentations, offer mentoring and trainingâ Have an intranet portal, providing information about provided
and potential Web servicesâ Provide usage examples and provide sample code if possible
⢠Watch out for ownership issuesâ The ânot-invented hereâ syndrome
6-16Best practicesFor the organization (4)
⢠Build an infrastructure team for Web Servicesâ Team members
⢠Senior Architects (both familiar with business requirements and (almost) every piece in the IT landscape of your enterprise)
⢠Cross-functional experience⢠Good mediators, good political skills, good existing network⢠Compensated based on overall cost savings, not project related
â Mission⢠Mission is NOT to administer the enterprise infrastructure nirvana⢠Advisory role, organizational âhelperâ, not dictators⢠They act as âre-useâ mentors ⢠BUT, projects shouldnât abdicate responsibility for re-use to these people
â They are there to help. They are not the scapegoats for lack of re-use.â When do you get these people involved?
⢠Early in each project life cycle⢠And also throughout itâs lifetime
â Some of the services that it needs to build wonât be clear at the startâ Some of the âexternalâ services that it needs to use wonât be clear at the startâ To identify services that it can offer other parts of the organization
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 107
6-17Best practicesFor the organization (5)
effort
Project-1Business
Logic
Project-1services
InfrastructureDeployed Web services, ready for reuse
Project-2Business
Logic
Project-2services
Infrastructure
Project-3Business
LogicProject-3services
Infrastructure
Project-?Business
Logic
Developmentprocess
prioritization
time
%done
⢠Donât expect too much too early⢠Web Services Infrastructure will grow over time
6-18
Supporting measures
⢠Even with Web services, fixing mistakes in production applications will be costly
⢠Get design mentoring and assistance from someone who has done it beforeâ Getting consultants may sound âexpensiveâ, but
finding out by try-and-error yourself is even more expensive
⢠Good quality has its price
⢠Invest in trainingâ Web service early adopters did not have that luxuryâ Self-learning does not work well for everyoneâ Training can give confidence and fresh ideas
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 108
6-19
Summary
⢠Most guidelines are common senseâ think back to the component reuse discussions of yesteryear!
⢠Using one or two Web services â having a SOAâ To justify the term âservice-orientedâ, a significant part of the
functionality should be implement as servicesâ Choose Web Service tools that encourage SOA
⢠Building enterprise-wide service infrastructure is not easy ⢠Start simple, start small, start building experience!⢠Immediate cost savings are possible, even with small
projects⢠Make sure the prerequisites are there
â Tools, Educationâ Team structureâ Incentives (and lack of dis-incentives)
6-20
Summary⢠Most guidelines are common sense
â think back to the component reuse discussions of yesteryear!⢠Using one or two Web services â having a SOA
â To justify the term âservice-orientedâ, a significant part of the functionality should be implement as services
â Choose Web Service tools that encourage SOA⢠Building enterprise-wide service infrastructure is not easy ⢠Start simple, start small, start building experience!⢠The ROI can be short term
â Even small projects can use SOA principles to give good architectures (this is the system-level equivalent of functional decomposition)
⢠And good architectures are easier to implementâ Re-use can happen early if you provide the incentives
⢠Make sure the prerequisites are thereâ Tools, Education, Team structureâ Incentives (and lack of disincentives)
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 109
Chapter 7:Advanced Topics
Where things are now and where they are going âŚ
Version 7
7-2
Section 7 â Advanced Topics
⢠Enterprise Web Services ⢠Industry trends and organizations ⢠Security and Reliability⢠Transactions⢠Choreography and Orchestration
â Composite web services⢠Interoperability Requirements
â Encoding discussion ⢠Futures
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 110
7-3
Enterprise Web Services
⢠Extending WS throughout the enterprise and among enterprises â greater emphasis onQualities Of Service (QoS)
⢠Security, Reliability, Transactions, Scalability⢠Systems Management ⢠Interoperability
⢠Itâs also important to allow it to be used over more transports(other than SOAP over HTTP)â IIOP (CORBA)â MQ Series messagingâ TIBCO Rendezvousâ Tuxedoâ SOAP over FTPâ JMS (J2EE)
7-4
Enterprise Standards are Evolving
SOAPMessage Payload
UDDILook-Up & Discovery
WSDLService Contract
XML Encryption, XKMS,XRML, WS-Security, SAML Security
Transactions WS-CAF, WS-T & WS-C
Management Web ServicesDistributed Management (WSDM)
Orchestration BPEL4WS, WS-Choreography
Reliable Messaging WS-Reliability,WS-ReliableMessaging
Others WS-Eventing, WS-Notification, WS-Resource Framework
Competing Standards Bodies
⢠Microsoft & IBM⢠Sun & Oracle⢠Others
Competing Vendor Groups
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 111
7-5
Industry organizations
⢠Helping to develop the necessary web services related standardsâ W3C
⢠SOAP (XMLP working group), WSDL, WS Architecture, WS Choreography
â OMG⢠IDL to WSDL, WSDL to IDL (WSDL 1.1), WSDL to C++
â OASIS⢠UDDI, WS-Security, WS-Reliability, WS-CAF, etc.
â JCP (Java Community Process)⢠JAX-RPC, JWSDL, JAXM, JAXR, âŚ
â Others⢠WS-I, etc.
7-6
Security⢠Confidentiality â no one can see my data⢠Integrity â my data gets there in one piece⢠Authentication â a user or program is confirmed to be
who they say they are⢠Authorization â ensuring access to services and data
only by those who are supposed to access them⢠No overall architecture yet defined
â May include firewalls, proxies, security servers, and identity management
⢠WS-Security a well-agreed framework (OASIS)
Security
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 112
7-7
SOAP Header example (WS-Security)
<S11:Envelope xmlns:S11="..." xmlns:wsse="..." xmlns:wsu="...â xmlns:ds="..."><S11:Header>
<wsse:Security xmlns:wsse="..."> <fabtok:CustomToken wsu:Id="MyID" xmlns:fabtok="http://fabrikam123/tokenâ />
<ds:Signature> . . . </ds:Signature><ds:SignedInfo> . . . </ds:SignedInfo>
</wsse:Security></S11:Header>
...</S11:Envelope>
Security
7-8
Reliability requirements⢠Reliability of message delivery is critical to many
applicationsâ Guarantee of message delivery (both request and response)
⢠At least once (duplicates are allowed)⢠At most once (âbest effortâ, ok to drop some messages)⢠Once and only once
â Eliminate duplicates (if any)â Preserve message ordering (when important)
⢠Some of these features are provided as standard when WS are carried on a connection-oriented protocolâ The âsessionsâ and correlation IDs of the connection-oriented
protocol ensures features such as orderingâ But some QoS must still be added (e.g., store-and-forward to
allow clients to send messages even if a server isnât running)
Reliability
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 113
7-9Example message flow
(WS-ReliableMessaging)
Reliability
7-10
Web Services: Implications for TP
⢠Persistent sessions are missing from HTTPâ Need to define a common context sharing mechanismâ Transport âagnosticâ means LCD
⢠Itâs difficult to write a new WS spec that assumes a more sophisticated protocol than HTTP
⢠Need a solution that is also suited for document-oriented transactionsâ Compensation, transactional âqueuesâ neededâ Reliable messaging needed
⢠Business process orchestrationâ Cancel/adjust transactions in long-running flight â Mixture of existing and new technologies
Transaction Processing
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 114
7-11
Current status of standardization⢠First attempt â SOAP-TIP
â Didnât work because it assumed persistent sessions (and these arenât provided by HTTP)
⢠XAML diedâ No one really wanted World Wide XA
⢠BTP not widely implementedâ A bit complex and hard to map to existing systems
⢠WS-Coordination and WS-Transaction not openâ Difficult to implement because itâs under-specified,â and itâs not very interoperable
⢠WS-Composite Application Framework (WS-CAF)â Current proposal at OASISâ Is able to co-ordinate between different transaction systems
⢠Resolves the differences in the co-ordinator, not in the end-points
TP
7-12
Web Services Composition⢠Once you have a âcritical massâ of Web services, you
may want to:â link them together to create (composite) complex Web servicesâ implement whole business processes based on those services
⢠Of course you can âhard-codeâ this, but the result will beâ inflexible (hard to maintain)â proprietary, not explicit (business logic will be buried in code)
⢠Better: Standardized high-level mechanisms for defining business processesâ Standardized declarative, non-programmatic way to compose
sequences of web service calls to accomplish a business function
⢠Efforts ongoing to provideâ WS-BPEL (seems to be winning at present)â WS-Choreography (more B2B oriented)
Composition
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 115
7-13
AdaptersMessage queuing system â A2A/B2B Integration broker
.NET Server Or App Server
With WebService APIs
Other applications
Orchestration Architecture
Database tables and stored procedures
ERP, CRM, Accounting
, etc.
Web service interfaces
Composition
Often, you have selection and loops as well just sequencing
This overall sequence is viewed as a WS from outside
You can also do transformation of data within this overall WS
7-14
Interoperability Requirements
⢠Within the enterprise and among enterprisesâ Across hardware platforms, operating systems, programming
languages, middleware and component technologies
⢠SoapBuilders and WS-I have been working to correlate the many WS standards into more interoperable configurations. E.g.,â Defining a consistent selection of standardsâ Subsetting (âprofilingâ) a standard
⢠Ensuring compatible message encoding is another key part of interoperabilityâ As discussed in the new few slides
Interoperability
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 116
7-15
You have a choice of the encoding for complex data in msgs
⢠The recommendation is literalâ This uses XMLSchema in the normal way
⢠The message references a schema that defines the elements and types for formatting arrays, sequences, records/structures, and other complex types
⢠The message uses these elements and types
⢠The alternative is SOAP encodedâ This defines a set of elements that can be used for complex data
⢠Mostly, these elements were good at formatting data that typically arises in RPC calls
â It was first introduced before XMLSchema was available⢠Newer versions (SOAP 1.2) use XMLSchema.
â The difference then between it and literal is that SOAP encoded fixes the set of tags/types. This has advantages and disadvantages.
â Many existing Web Services use SOAP encoded, but literal is recommended by WS-I for SOAP 1.1
⢠WS-I hasnât yet profiled SOAP 1.2, so it is silent on whether SOAP encoding is OK in SOAP 1.2
Encoding & Message Style
7-16You also have a choice between two
message styles⢠The choice is rpc or document
â document style is recommended by WS-I for SOAP 1.1 (albeit most existing Web services examples use rpc style)
⢠Recall that each operation has an input and an optional output messageâ In rpc style, each message can have zero or more parts
<message name=âgetQuoteRequestâ><part name=âsymbolâ type=s:stringâ><part name=âdateâ type=âs:string>
</message>â In document style, each message can have at most one part (and
this needs to be an XML element, not a type).
WS-I has yet to profile SOAP 1.2
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 117
7-17
Combining these two choices:
document RPC
literal
SOAPencoded
This combination is used by many existing services.
Encoding & Message Style
7-18
Futures â Quickly !!
⢠Advances in Standardsâ Ratification of newer versions of standards (SOAP, WSDL, etc.)â Emergence of newer standards to support the evolution of WS
into enterprise environments (WS-CAF, etc.)
⢠Advances in deployment supportâ Additional availability of transports/protocols for greater
penetration within enterprises without requiring infrastructure changes
⢠Interoperability advancesâ More shake-out of interop issuesâ More adoption of recommendations from WS-I, OASIS, etc
Futures
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 119
Chapter 8:Summary, References and Useful links
Version 3
8-2
Summary
⢠Challenges facing systems integration across heterogeneous networks, operating systems, software development environments and third party systems
⢠Service Oriented Architecture provides a paradigm for organizing high-level solutions to integration problems by emphasizing a simple service client and provider model
⢠Web Services exploit SOA concepts with implementations over ubiquitous (Web-based) transports and using platform-independent messaging technology standards
⢠Tools and technologies for Web Services simplify the design, development and deployment of solutions
⢠Stability and maturity of technologies still an issue but rapidly improving â with significant efforts in delivering enterprise Qualities of Service over Web Services
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 120
8-3
Summary (cont.)
⢠We have only scratched the surface of the detailed technology emerging around Web Services â We could spend much more time on each of the
technologies and tools areas you have seen today.⢠Plenty of reference and research material to
consider in doing your own research â See the following slides on links, references and
booksâ Try doing a Google Search on âWeb Servicesâ !!!
8-4Sources and Links⢠W3C - World Wide Web Consortium
â http://w3c.org/⢠OASIS - Organization for the Advancement of Structured Information Standards
â http://oasis-open.org/⢠WS-I - Web Services Interoperability Organization
â http://www.ws-i.org/⢠Worldwide Institute of Software Architects
â http://www.wwisa.org/⢠Enterprise Architect Online
â http://www.enterprise-architect.net/⢠Web Services Architect
â http://www.webservicesarchitect.com/⢠John McDowallâs homepage and blog
â http://www.mcdowall.com/⢠Mary Shawâs homepage
â http://spoke.compose.cs.cmu.edu/shaweb/
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 121
8-5Sources and Links (Cont.)⢠Web Services Journal
â http://sys-con.com/webservices/⢠The Zachman Framework
â http://www.zifa.com⢠DevX web site
â http://www.devx.com/⢠Web Services.org
â http://www.webservices.org/⢠IBM DeveloperWorks â Web Services
â http://www-106.ibm.com/developerworks/webservices/⢠XML & Web Services Magazine
â http://www.ftponline.com/xmlmag/⢠.NET Magazine (now known as Windows Server System)
â http://www.ftponline.com/wss/⢠JavaPro
â http://www.ftponline.com/javapro/
8-6
Books
⢠Eric Newcomer : âUnderstanding Web Services: XML, WSDL, SOAP, and UDDIâ, Addison-Wesley, Paper-back, 368 pages, May 2002, ISBN: 0201750813
⢠James McGovern (Editor): âJava Web Services Architectureâ, Morgan Kaufmann, 831 pages, April 2003, ISBN: 1558609008
⢠William L. Oellermann Jr.: âArchitecting Web Servicesâ, Apress, Paperback, 672 pages, October 2001, ISBN: 1893115585
⢠Martin Fowler: âPatterns of Enterprise Application Architectureâ, Addison-Wesley, 560 pages, November 2002, ISBN: 0321127420
ŠCopyright 1999-2004 IONA Technologies PLC. All rights reserved. Page 122
8-7
Books (cont.)
⢠M. L. Brodie, M. Stonebraker: âMigrating Legacy Systems: Gateways, Interfaces, and the Incremental Approachâ, Morgan-Kaufman, 1995
⢠Scott Seely, Eric Smith, Deon Schaffer: âCreating and Consuming Web Services in Visual Basicâ, Addison-Wesley, Paperback, 394 pages, May 2002, ISBN: 0672321564
⢠Henry Bequet, Meeraj Moidoo Kunnumpurath, Sean Rhody, Andre Tost: âBeginning Java Web Servicesâ, WROX, Paperback, Sept. 2002, ISBN: 1861007531
⢠Cauldwell et al: âProfessional XML Web Servicesâ, WROX, Paperback, 803 pages, 2001, ISBN: 1861005091
8-8
Thank You