SW501 501: : Introduction to Web Services with IBM Rational Application Developer V6
Course description Introduction to Web Services Development with IBM Rational Application Developer V6 Duration: 2 Days Description: This course covers the technologies involved in developing, testing, and consuming Web services using SOAP, WSDL, and UDDI This course covers the development of Web services using Java and XML with IBM Rational Application Developer Version 6
Course objectives After completing this course, students should be able to: Identify the components of a SOAP and WSDL message Publish and find Web services in a UDDI registry Generate Web services from a JavaBean or WSDL document using the Web services wizard Debug and monitor Web services using the TCP/IP monitor Configure Web services using the Web services deployment descriptors
Course prerequisites Practical Java development experience using IBM Rational Application Developer
Student introductions Please introduce yourself and provide your: Name and organization Knowledge of Java Knowledge of XML Experience using Rational Application Developer Knowledge of Web services Goals you hope to achieve
Agenda: Day 1 Unit 1 Course introduction Unit 2 Role of Web services in enterprise applications Unit 3 Web services technology overview Unit 4 XML and XML schema Unit 5 Introduction to SOAP Exercise 1: Simple SOAP messaging Lunch Unit 6 - Web Services Description Language (WSDL) Exercise 2: Creating a WSDL document using the WSDL editor Unit 7 J2EE support for Web services Unit 8 Creating Web services using IBM Rational Application Developer
Agenda: Day 2 Unit 9 Exercise overview Exercise 3: Create a Web service from a JavaBean Exercise 4: Create a Web service from a WSDL Unit 10 Creating Web service clients using Rational Application Developer V6 Exercise 5: Generate Web service clients from a WSDL Lunch Unit 11: Overview of UDDI Unit 12: Publishing Web services to a UDDI registry Exercise 6: Publishing Web services to a UDDI registry Unit 13: Course summary
Unit summary In this module, you have learned: The course objectives you will achieve The prerequisite skills needed to take this course The agenda for the course
Role of Web services in enterprise applications
Unit objectives After completing this unit, you should be able to: Describe the role of service-oriented architectures (SOA) in an enterprise system. Describe the role of Web services in an SOA.
Business integration What s behind the call for business integration? Enterprise application integration Mergers and acquisitions Business partner integration How is business integration accomplished? Application integration Interoperability Standards
Existing integration technologies The following are examples of common distributed computing technologies, already in widespread use: CORBA Common Object Request Broker Architecture by OMG Language-neutral, object-oriented distributed computing standard Problem: Interoperability issues since there is no guarantee that vendors implement the complete CORBA specification DCOM Distributed Component Object Model Microsoft s distributed object programming technology Problem: Implemented in Windows only, which limits interoperability Java RMI Remote Method Invocation Java-to-Java object distribution Problem: Not language-neutral RMI over IIOP Java RMI style programming using CORBA IIOP for communication The technique clients use to access Enterprise JavaBeans Problem: Dependency on CORBA for communication and Java for interface
Distributed system challenges Performance and scalability Management Accomplishment of loose coupling Defining granularity of interactions Maintenance of context across systems Transaction, security, session state Protocol conversions Versioning Firewall and other security challenges Network bandwidth Failover Problem determination and root cause analysis Development, integration, and test costs
What is a service-oriented architecture? An architectural style for building distributed systems that deliver application functionality as services to either user applications or other services Leverages open standards to represent software assets as services Provides a standard way of representing and interacting with software assets Allows individual software assets to become building blocks that can be reused in developing other applications Shifts focus to application assembly rather than implementation details Can be used internally to create new applications out of existing components Can be used externally to integrate with applications outside of the enterprise
What is a service? A service is an application function packaged as a reusable component that can be used in a business process. Exposes a well defined interface Appears as a self-contained function Uses messages to hide implementation details Has no dependencies on the state of other services Provides information to a requester or facilitates a change to business data from one valid, consistent state to another
What are Web services? A software system identified by a URI, defined, described and discovered by XML artifacts, which interacts with other software systems using XML messages through Internetbased protocols (W3C Web Services Architecture Group) Definition does not mandate any particular specification, for example, SOAP, WSDL, and UDDI Definition does not declare any specific protocols like HTTP
Web services and SOA Service registry Find Service requester UDDI Publish WSDL Bind SOAP Service provider SOA is the architectural strategy of building applications based on services, and deals with the arrangement of services in application systems. Web services is a particular set of standardized technologies that can be used to create an SOA.
IBM s s view of Web services Described by WSDL which is independent of a transport protocol Evolutionary Starts with good distributed design principles Enabling technology for serviceoriented architectures and on demand systems Standards, Standards, Standards Interoperability User Experience Management Business Processes Transactions Reliability Security Discovery Publication Description Messaging Enterprise Security Connection
Examples of SOA-based solutions Successful SOA and Web service implementations have provided solutions to challenges in a number of industries: Transportation Need to quote realistic prices made difficult when shipments travel over multiple carriers Banking Need to provide banking services to multiple requesters Need to integrate large numbers of internal applications Government Need to share and access data across agencies
Common uses for Web services Interoperability between heterogeneous systems B2B interactions Lower cost than EDI and proprietary alternatives Multiple requesters Particularly for heterogeneous platforms, protocols, and channels Encapsulation of legacy systems Isolation from changing systems Enterprise standardization of services Integration of third-party packages Process choreography Portal development
Checkpoint questions 1. Name some common distributed computing technologies and describe some of their limitations. 2. Describe some characteristics of a service-oriented architecture. 3. What is the relationship between a service-oriented architecture and Web services? 4. What makes IBM s view of Web services unique?
Unit summary In this module, you have learned: The differences between a Web service and an SOA as well as how they relate to one another The importance of SOA as an architectural strategy
Web services technology overview
Unit objectives After completing this unit, you should be able to: Describe the role of XML in Web services standards Define the core standards involved in Web services Describe the role of SOAP, WSDL, and UDDI in Web services Identify how to implement portable standards-bases Java Web services Use the tooling available to develop Web services that will be deployed on the IBM WebSphere V6 Web services runtime State the importance of interoperability between Web services Identify real-world scenarios involving Web services
Using XML and XML schema XML: Allows us to model data in a vendor, language, and platform neutral way Is self-describing Markup consists of tags and text Is designed for interoperability and ease of implementation <streetaddress>123 State Street</streetaddress> XML schema: Allows you to define and constrain the content of an XML document Allows you to define custom types Allows you to define simple types and complex types <element name = streetaddress type= string />
Sample XML document <?xml version= 1.0 encoding = UTF-8?> <! - Namespace declarations removed for brevity --> <porttype name="stockquoteservice"> <operation name="getquote"> <input message= impl:getquoterequest name="getquoterequest"/> <output message="impl:getquoteresponse name="getquoteresponse"/> <operation> </porttype> Attribute Prolog Element
XML and Web services XML is part of the definition of Web services according to the W3C Web Services Architecture Group. defined, described and discovered by XML artifacts interacts with other software systems using XML messages XML is the basis for many of the Web services standards. XML characteristics map well to your business integration needs. Interoperability WSDL Vendor, platform, language neutral Service Requester SOAP Service Provider UDDI
What is SOAP? Protocol for carrying XML messages across a network a SOAP message itself is an XML document Network, transport, and programming language independent Envelope Header Holds processing information and directives Body Holds application specific information for example, parameters for a Web service call
What is WSDL? Web Services Definition Language Describes the interface of a Web service using XML Bindings Operations Location of specific implementation Defines operations and messages abstractly Uses XML schema for expressing type information definitions types holds custom type information for the service message defines message names and parameters porttype defines available operations binding describes supported protocols service maps binding to specific network address
What is UDDI? The UDDI project defines: Structure for the service and service provider registry API for accessing the service registry Classifications for data Interactions with a UDDI registry include: Publishing information Finding information Using the obtained information
Relationship of core standards Service Broker Reference or URL Service Description (WSDL) Find UDDI UDDI Publish Create description Service Requester SOAP Bind or interact Service Provider Service
Service-oriented architecture stack Functions Quality of Service Business Process Service Service Description WSDL XML Service Communication Protocol Service Registry SOAP BPEL4WS Transport WS-ReliableMessaging HTTP JMS SMTP UDDI Policy Security Transaction Management WS-Inspection WS-Policy WS-Security WS-Trust WS-AtomicTransaction WS-Coordination WS-BusinessActivity WS-Manageability Current Standards Emerging Standards
Web services and J2EE J2EE Defines standards for containers, services, and communications Provides a compatibility test suite and reference implementation Specifies best practices for Java development JAX-RPC (JSR101) Defines a standard programming model for Java Web service clients and endpoints Ensures that conforming Web service runtime environments provide the same level of functionality Web Services for J2EE (JSRs 109, 921) Defines a structure and a packaging standard for Web services implemented as a J2EE application Defines the deployment model for services running in a J2EE application server
Web services development Existing code can be wrapped within a Web service shell. You can expose the following J2EE components as Web services: JavaBean EJB Web services and clients can be generated from a WSDL. IBM Rational Application Developer is the development environment. Any server that supports SOAP, WSDL, and HTTP can host and use Web services. Command line tools for Web service development are packaged with WebSphere Application Server.
Web services runtime environments Allow deployment of Web services in an application server Implement Web services specifications, such as SOAP IBM Rational Application Developer V6 supports three runtime environments: IBM WebSphere V6 Web services Apache Axis 1.0 IBM SOAP*
Generating a Web service 1. Enable Web service development capabilities in Rational Application Developer 2. Start with: WSDL file JavaBean Stateless session EJB 3. Specify deployment options using a wizard Application server and Web service runtime Methods to be deployed Transport protocol (HTTP or JMS) 4. Test the Web service Web Services Explorer JSP test client Custom client
Web service components Service endpoint interface WSDLs WebSphere bindings and extensions JAX-RPC mapping file Web services deployment descriptor
Overview of Web service standards Web service standards come from many different organizations: World Wide Web Consortium (W3C) SOAP WSDL XML Organization for the Advancement of Structured Information Standards (OASIS) UDDI WS-Security BPEL4WS Java Community Process (JCP) Web Services for J2EE JAX-RPC Vendors WSIL WS-Addressing WS-ReliableMessaging
It is all about interoperability Web Services Interoperability WS-I.org Founded in 2002 135+ members Accenture, BEA, Fujitsu, Hewlett-Packard, IBM, Intel, Microsoft, Oracle, SAP, Sun, webmethods, Ford, BT, Charles Schwab, Fidelity, AOL, Merrill Lynch, JP Morgan Chase, IONA, Adobe, CA, DCX, Nokia, OAG, OMG, OASIS, RosettaNet, AIAG, POSC, Acord, Accelerate adoption and promote interoperability Profiles, testing tools, sample applications Best Practice #1
WS-I I Basic Profile Basic Profile 1.0 (final) Defines support for SOAP1.1, WSDL1.1, XML schema, HTTP, UDDI2.0, and so forth Provides guidance on the use of the above standards Is well received in the market Basic Profile 1.1 (final) Incorporates errata from version 1.0 Factors out envelope serialization rules into a separate profile Is composable with envelope serialization profiles Basic Profile 1.0 Basic Profile 1.1 A combined claim of conformance to both the Basic Profile 1.1 and the Simple SOAP Binding Profile 1.0 is roughly equivalent to a claim of conformance to the Basic Profile 1.0 Simple SOAP Binding Profile 1.0 Attachments Profile 1.0
Web services application Service Broker Travel industry association Customer UDDI application UDDI SOAP SOAP WSDL uses Service Requester Travel Plus travel agent application SOAP Service Providers Car Airline Hotel hotel reservation system
Web services challenges Routing Web services and Web services reliability How can reliability be measured and communicated? What happens when a Web service is temporarily unavailable? Security How do you know which Web service providers you can trust? How does a Web service authenticate users? What level of security is required? Transaction How can transactions be handled within Web services? Several Web services may be involved in a single transaction Attachments How can documents be attached to Web services messages? Accountability How long can a user access and execute a Web service? How do you charge for Web services?
Web service standards support Web Services for J2EE 1.0 (JSR 109) SOAP 1.1 WSIL 1.0 SOAP with Attachments SAAJ 1.2 WSDL 1.1 UDDI 2.0 and 3.0 Rational Application Developer V6.0 Web Services for J2EE 1.1 (JSR 921) JAX-RPC 1.0 and 1.1 JAXR 1.0 WS-I Basic Profile 1.1 WS-Security 1.0
Checkpoint questions (1 of 2) 1. The WS-I: A. Defines a basic profile B. Acts as a standards integrator C. Creates a set of new interoperable specifications D. Clarifies usage of existing standards 2. Core standards associated with Web services are: A. WSDL, SOAP, and UDDI B. XML and SOAP C. WSDL and Java D. WSDL and WS-Security 3. Which standard defines an XML-based interface for Web services? A. SOAP B. WSDL C. UDDI D. WSIL
Checkpoint questions (2 of 2) 4. Which of the following standards organizations manages the UDDI specification? A. W3C B. JCP C. IETF D. OASIS 5. Web services can be created from which of the following components? A. JavaBean B. Web services deployment descriptor C. WSDL D. EJB
Unit summary In this module, you have learned: The core standards involved in a Web service implementation The relationship of XML to SOAP, WSDL, and UDDI That SOAP is a messaging protocol That WSDL provides a standard for describing Web services That UDDI provides a registry service for Web services That standards are necessary for interoperability How Java standards promote portable Java Web services
XML and XML schema
Unit objectives After completing this unit, you should be able to: Identify the purpose of XML schema Define simple and complex XML types in an XML schema Examine tools for handling XML Define relationship between XML schema and Web services
What is XML? Extensible Markup Language (XML) is a metalanguage XML is text that follows a well-defined set of rules XML is about describing data Custom markup languages for documents can be defined via a DTD or an XML schema
Parts of an XML document Prolog <?xml version="1.0" encoding="utf-8"?> <definitions name="stockquote" targetnamespace="http://example.com/stockquote/definitions" Root xmlns:tns="http://example.com/stockquote/definitions" xmlns:xsd1="http://example.com/stockquote/schemas" Element xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:import namespace="http://example.com/stockquote/schemas" location="http://example.com/stockquote/stockquote.xsd"/> <wsdl:message name="getlasttradepriceinput"> <wsdl:part name="body" element="xsd1:tradepricerequest"/> </wsdl:message> <wsdl:message name="getlasttradepriceoutput"> <wsdl:part name="body" element="xsd1:tradeprice"/> </wsdl:message> <wsdl:porttype name="stockquoteporttype"> <wsdl:operation name="getlasttradeprice"> <wsdl:input message="tns:getlasttradepriceinput"/> <wsdl:output message="tns:getlasttradepriceoutput"/> </wsdl:operation> </wsdl:porttype> </wsdl:definitions> Element Attribute
The need for namespaces <wsdl:definitions name="stockquote" targetnamespace="http://example.com/stockquote/definitions" xmlns:tns="http://example.com/stockquote/definitions" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> <wsdl:binding name="stockquotesoap" type="tns:stockquoteporttype"> <soap:binding style="document" transport="http://example.com/smtp"/> <wsdl:operation name="subscribetoquotes"> <wsdl:input message="tns:subscribetoquotes"> <soap:header message="tns:subscribetoquotes part="subscribeheader" use="literal"/> <soap:body parts="body" use="literal"/> </wsdl:input> </wsdl:operation> </wsdl:binding> </wsdl:definitions> Without namespaces, a processor cannot easily distinguish between the two <binding> elements
Declaring XML namespaces Combination of prefix, element name, and URI creates a namespace declaration: <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"> Once declared, any child element or attribute can use the defined prefix Prefix + Element/Attribute = Qualified Name (or QName) Default namespaces for all unqualified elements or attributes can also be defined: <definitions xmlns="http://schemas.xmlsoap.org/wsdl/"> Default namespaces do not apply to attributes Default namespaces can be redefined for different parts of an XML document
Well-formed and valid documents A well-formed XML document follows the conventions of XML syntax Exactly one element (root) exists that does not appear in the content of any other element All elements are delimited by start and end tags and nested properly within each other Naming rules are respected A valid XML document complies with the grammar defined in its schema Being well-formed and valid does not tell you anything about the information inside the document itself
What is XML schema? An XML schema: Is a document created using the XML schema definition language Defines elements and attributes that can appear in an XML document Describes constraints on those elements and attributes The XML schema definition language: Is an XML-based markup language Is a specification managed by the W3C
Creating an XML schema <Schema> is the root element in an XML schema Defines a document as an XML schema Serves as a container for element and attribute information item declarations Sets global attributes affecting all declarations within a schema, such as: targetnamespace Sets all declared elements and attributes to belong to that namespace elementformdefault Indicates whether locally declared elements must be qualified by the target namespace in an instance document attributeformdefault Indicates whether locally declared attributes must be qualified by the target namespace in an instance document
XML schema example <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns="http://samples.ibm.com/person/ targetnamespace="http://samples.ibm.com/person/" elementformdefault="qualified"> <xs:element name= person'> <xs:complextype> <xs:sequence> <xs:element name='firstname' type='xs:string'/> <xs:element name= middlename type= xs:string minoccurs= 0 maxoccurs= 3 /> <xs:element name='lastname' type='xs:string' /> <xs:element name='age' type='xs:positiveinteger'/> </xs:sequence> <xs:attribute name= person_id' type='xs:int' use='required'/> </xs:complextype> </xs:element> Person.xsd </xs:schema>
Defining elements in an XML schema The <xs:element> defines elements that appear in an XML document: <xs:element name="username" type="xsd:string" /> name attribute specifies the element name type attribute restricts the content within an element ref attribute references a previously defined element Example of valid XML according to the above definition: <username>user2175</username>
Element type categories Two different categories for element type exist: Simple types Contains only character data No attributes or child elements Complex types Can contain attributes, child elements, or character data <xs:element name="username" type="xsd:string" />
Built-in in simple types anysimpletype boolean float decimal integer nonpositiveinteger nonnegativeinteger string time Examples True, false, 0, 1 31415E-4, NaN 3.14152396 314152396..., -2, -1, 0 0, 1, 2,... Hello World! 14:20:00-5:00
Using simple types Designed for encoding character data only Elements using simple types: Cannot contain any child elements Cannot contain any attributes All attributes must use simple types All simple types are restrictions, lists, or unions of other simple types All simple types stem from one base type, anysimpletype Create a subset of an existing simple type using restrictions Combine two or more sets of simple types using unions Create groups of simple types using lists
Using complex types Designed for a hierarchy of elements Elements using complex types: Can contain character data Can contain child elements Can contain attributes Can contain no data at all (empty element) Attributes can only use simple types Cannot contain other elements or attributes Two subcategories of complex type exist: Simple content Can contain character encoding and attributes Complex content Can contain child elements and attributes Cannot contain character encoding unless mixed = true
Elements with child elements <xs:complexcontent> allows child elements and attributes <xs:element name="stockaction"> <xs:complextype> <xs:complexcontent> <xs:attribute name="category" type="xs:string" /> <xs:element name="stocksymbol" type="xs:string" /> </xs:complexcontent> </xs:complextype> </xs:element> Sample XML instance document: <stockaction category="buy"> <stocksymbol>ibm</stocksymbol> </stockaction>
Creating an XML schema for a WSDL Right-click inside the Types box on the WSDL editor and select Add Schema
XML schema tooling Graph view allows you to see the relationships between complex types Define and modify Complex types Simple types Elements Attributes Context Menu Validate Generate XML Java HTML DDL
Checkpoint questions (1 of 2) 1. Why is XML schema important to Web services? 2. XML documents A. Must always be well-formed B. Always exist as a physical file C. Must always be valid D. Contain tags and text 3. Where can an XML namespace be declared? A. Only in the start tag of the root element B. Prior to the XML declaration C. In the start tag of any element D. In the end tag of any element 4. Which of the following XML snippets are well-formed? A. <Name> some content goes here </name> B. <attribute name= name type= string /> C. <parent><child></parent> D. <PERSON id= E1723 ><firstname>joe</firstname></person>
Checkpoint questions (2 of 2) 5. Which of the following XML snippets is valid according to the following schema? <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" <!--Name space declarations removed for brevity --> <xs:element name=person'> <xs:complextype> <xs:sequence> <xs:element name='fname' type='xs:string'/> <xs:element name='lname' type='xs:string' /> </xs:sequence> <xs:attribute name=person_id' type='xs:int' use='required'/> </xs:complextype> </xs:element> </xs:schema> A. <person id= 123 > <fname>bob</fname> <lname>buchanan</lname></person> B. <person><fname>bob</fname><lname>buchanan</lname></person> C. <person id= e17 ><fname>bob</fname><lname>buchanan</lname></person> D. <person>lname>buchanan</lname><fname>bob</fname><</person>
Unit summary In this module, you have learned: About the importance of XML namespaces About document validity and well-formedness About XML schema and its relationship to WSDL About XML schema tooling in Application Developer
Appendix The following topics are included for your reference: Examples of simple and complex type declarations Importing and including XML schemas
Creating subsets of simple types Declare a new simple type using <simpletype> Use facets to restrict the value space of a simple type length, minlength, maxlength (for string and binary types) maxinclusive, maxexclusive, mininclusive, minexclusive, totaldigits, fractiondigits for numeric types <xs:simpletype name="userid"> <xs:restriction base="xs:string"> <xs:maxlength value="8"/> </xs:restriction> </xs:simpletype> <xs:simpletype name="lotterynumber"> <xs:restriction base="xs:integer"> <xs:mininclusive value="1"/> <xs:maxinclusive value="49"/> </xs:restriction> </xs:simpletype>
Restricting character content Restrict a sequence of characters using a pattern <xs:simpletype name="uspostalcodetype"> <xs:restriction base="xs:string"> <xs:pattern value="[0-9]{5}(-[0-9]{4})?"/> </xs:restriction> </xs:simpletype> Restrict a list of characters using an enumeration <xs:simpletype name="neighboringstatetype"> <xs:restriction base="xs:string"> <xs:enumeration value="nc"/> <xs:enumeration value="sc"/> <xs:enumeration value="va"/> </xs:restriction> </xs:simpletype>
Creating a group of character content Use lists to create an unordered sequence of character data, separated by white space Specify a list of tokens composed of atomic types Cannot create lists of complex types or lists of lists <xs:simpletype name="neighboringstatelist"> <xs:list itemtype="neighboringstatetype"> </xs:simpletype> Use unions to create a new simple type by combining the values from two or more simple types Can combine multiple atomic or list types <xsd:simpletype name="stateandzipcodetype"> <xsd:union membertypes="neighboringstatetype zipcode"/> </xsd:simpletype>
Elements with character content <xs:simplecontent> allows character-encoded content and attributes <xs:element name="stockaction"> <xs:complextype> <xs:simplecontent> <xs:extension base="xs:string"> <xs:attribute name="category" type="xs:string" /> </xs:extension> </xs:simplecontent> </xs:complextype> </xs:element> Sample XML instance document: <stockaction category="buy"> Transaction complete </stockaction>
Elements with mixed content Setting mixed to true in <xs:complexcontent> allows both character-encoded content and child elements <xs:element name="stockaction"> <xs:complextype mixed="true"> <xs:sequence> <xs:element name="category" type="xs:string"/> <xs:element name="status" type="xs:string"/> </xs:sequence> </xs:complextype> </xs:element> Sample XML instance document: <stockaction> Transaction <category>buy</category> <status>complete</status> </stockaction>
Elements with no content Using xs:anytype without declaring any element or character-encoded content creates an empty element <xs:element name="stockaction"> <xs:complextype> <xs:complexcontent> <xs:restriction base="xs:anytype"> <xs:attribute name="category" type="xs:string"/> </xs:restriction> </xs:complexcontent> </xs:complextype> </xs:element> Sample XML instance document: <stockaction category="buy"/>
Elements with any type of content <xs:any> specifies that any element and any attribute is allowed within an element <xs:element name="stockaction"> <xs:complextype> <xs:sequence> <xs:any namespace="http:/www.w3.org/1999/xhtml" minoccurs="0" maxoccurs="unbounded" processcontents="skip" /> </xs:sequence> </xs:complextype> </xs:element> Sample XML instance document: <stockaction> <h1>transaction <b>complete</b></h1><br/> </stockaction>
Limiting element occurrence Specifies how many times an element can appear in an instance document minoccurs attribute Least number of times an element can appear Default value of 1 maxoccurs attribute Greatest number of times an element can appear Default value of 1 fixed attribute Value assigned to an element, regardless of its actual value in an XML document default attribute Value assigned to an element if none is defined
Limiting attribute occurrence Since attributes appear at most once in an element, maxoccurs and minoccurs do not apply fixed attribute Value assigned to an element or attribute, regardless of its actual value in an XML document default attribute Value assigned to an element or attribute if none is defined use attribute Indicates whether an attribute can or should appear required means that the attribute must appear exactly once optional means that the attribute can appear 0 or 1 times prohibited means that the attribute cannot appear Default value is optional
Including definitions from another schema <xs:include> Allows access to definitions within included schema as if it were in the same document as the original Target namespaces of both original and included schemas must match <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/xmlschema" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" targetnamespace="http://schemas.xmlsoap.org/wsdl/" elementformdefault="qualified"> <xs:include schemalocation="wsdl.xsd"> </xs:schema>
Importing definitions from another schema <xs:import> Allows schemas from different target namespaces to share definitions Only globally defined types can be accessed through import <?xml version="1.0" encoding="utf-8"?> <xs:schema xs:xmlns="http://www.w3.org/2001/xmlschema" xmlns:html="http://www.w3.org/1999/xhtml" targetnamespace="http://www.example.org/"> <xs:import namespace="http://www.w3.org/1999/xhtml"/> <xs:complextype name="mytype"> <xs:sequence> <xs:element ref="html:p" minoccurs="0"/> </xs:sequence> </xs:complextype> </xs:schema>
Introduction to SOAP
Unit objectives After completing this unit, you should be able to: Describe the role of SOAP in Web services Identify parts of a SOAP message Identify SOAP messaging styles Identify the parts of a SOAP fault Explain how SOAP messages are transported Explain how a SOAP message is processed by a SOAP runtime
SOAP overview SOAP is a lightweight messaging protocol Developed for the exchange of structured information in a decentralized, distributed environment Many Web services today use SOAP as the messaging protocol SOAP defines an XML messaging format for packaging Web service requests and responses SOAP 1.1 is the most common version supported by runtime environments This lecture focuses on SOAP 1.1 SOAP Node SOAP SOAP Message Message Internet Internet SOAP Node
Where does SOAP fit in SOA? SOAP is the messaging protocol used to interact with a service entity. SOAP depends on an underlying transport for sending and receiving messages. Reference or URL Service Broker Service Description (WSDL) Find SOAP SOAP Publish Create description Service Requester SOAP Bind or interact Service Provider Service
SOAP messages SOAP messages are XML documents that contain: Two mandatory elements: Envelope and Body One optional element: Header The Header contains application specific delivery instructions Envelope The Envelope contains the rest of the SOAP message, but not an address Header Body Body The Body carries the actual message
SOAP message structure The root element is always Envelope SOAP 1.1 namespace <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:header> The optional <!-- Insert header info here --> Header element <soapenv:header> <soapenv:body> The required <!-- Insert message body here --> Body element </soapenv:body> contains the SOAP </soapenv:envelope> request
SOAP envelope The Envelope element serves as the root element of a SOAP message The Envelope element MUST be namespace qualified with the appropriate SOAP version There are only two immediate child elements that are allowed: Header, which is optional Body, which is mandatory
SOAP headers Optional element, used for application specific processing Within a scope of a SOAP message there may be multiple nodes each with different roles that process the message Nodes within the message path may have specific roles, for example, authenticator, logger, router, and so forth The SOAP header element provides a location in the SOAP message where role-related information can be stored for use as the message travels though the message chain Two commonly used attributes: actor: URI that specifies the role of the node that has to process the header mustunderstand: Boolean to specify if node has to understand the information in the header
SOAP body The SOAP body element carries the content of the message. The SOAP body element MUST be namespace qualified and reside in the same namespace as the SOAP envelope element. A SOAP body may contain any number of child elements: The fault element, which is used for error handling Defined by the SOAP specification If present, only child element allowed Application-related child elements Not defined by the SOAP specification, since it is application specific Should be associated with an application-specific namespace
Example SOAP message <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:q0="http://www.example.com/"> <soapenv:header> <q0:logmode SOAP-ENV:actor="http://somecompany.com/log" SOAP-ENV:mustUnderstand="1"> Secure </q0:logmode> <soapenv:header> <soapenv:body> <q0:register> <q0:firstname>john</q0:firstname> <q0:lastname>doe</q0:lastname> </q0:register> </soapenv:body> </soapenv:envelope>
SOAP message exchange Two different types of messaging: Document exchange The SOAP body contains one or more child elements called parts, which can follow any format (specific to an application) For example, the SOAP body may contain an XML-formatted purchase order Remote procedure call (RPC) The SOAP message identifies the name of an operation supported by the recipient node and includes the parameters required to execute the operation For example, a request for the recent price of a given stock
SOAP document exchange The information format is application-specific. The format is not covered by the SOAP specification. The contents of the message must still be well formed XML. Use XML entities where necessary (for example, using < to represent < ) Applications that process the SOAP messages need access to an XML schema that defines the structure and syntax of the message. Sequences of messages exchanged in this manner may conform to some pre-defined workflow.
Document exchange message pattern Processor 1 Processor 2 purchaseorder creditinfoupdaterequest SOAP Msg Time SOAP Msg creditinfo SOAP Msg...
SOAP document exchange example <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:body> <purchaseorder xmlns="http://purchaseorder.beans > <orderinfo> <orderid> 9876 </orderid> <itemname> Car </itemname> </orderinfo> <custinfo> <customerid> 9876 </customerid> <customername> John Doe <customername> </custinfo> </purchaseorder> </soapenv:body> </soapenv:envelope>
SOAP remote procedure call SOAP-RPC is a remote procedure call (RPC) framework defined in the SOAP specification The message body has a single child element: the request document root The request document root carries the name of the remote procedure Each argument of the remote procedure is included as a child tag of the request document root
SOAP RPC request Example <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:q0="http://calculator.ibm.com"> <soapenv:body> <q0:addop> <q0:input1 type="xsd:int">5</q0:input1> <q0:input2 type="xsd:int">3</q0:input2> </q0:addop> </soapenv:body> </soapenv:envelope>
SOAP RPC - Response message Response messages are required when The RPC has a return value by virtue of the operation it performs A procedure with a non-void return type The RPC operations may throw an exception SOAP faults are used to signal the failure of an RPC The SOAP body contains a response document that holds the results The response document root is named for the RPC involved By convention, the word Response is appended to the RPC name For example, calcopresponse The child elements of the response document root hold the result returned from the RPC
SOAP RPC response Example <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:q0="http://calculator.ibm.com"> <soapenv:body> <addopresponse xmlns="http://calculator.ibm.com"> <return>8</return> </addopresponse> </soapenv:body> </soapenv:envelope>
RPC message pattern public int addop(int input1, int input2); Processor 1 Processor 2 addop Time input1 = 5 Input2 = 3 return = 8 addopresponse
SOAP faults Errors that occur during the processing of a SOAP request are signaled to the sender using a special SOAP message called a SOAP fault. The SOAP fault is defined in the SOAP specification as the standard mechanism for reporting errors. When a processing error occurs, a fault element is included in the place of the response element inside a SOAP message. SOAP fault message elements: <faultcode>: machine readable code for error <faultstring>: human readable explanation for fault <faultactor>: identifies the role who caused the error <detail>: application specific error information
The fault detail element The detail element is intended to carry information about errors that occurred while processing the SOAP body. The detail element must be present when the error occurs inside the SOAP body. The detail element must NOT be present when errors occur in the SOAP header. Unrecognized headers, header processing errors, failures to transport a message to the next node in the message chain, should not be reported in the detail element.
The fault code element The SOAP specification provides four values to address most error situations: 1. mustunderstand A value that was marked as mustunderstand inside the SOAP header was not understood by either the target processor or by an intermediary processor. 2. VersionMismatch The SOAP version used to form the message is not supported by either the target processor or by an intermediate processor. 3. Server A problem occurred during message processing that is not client related. 4. Client An error occurred due to erroneous content in the request: bad arguments, failed credit check, and so forth.
Example SOAP fault - SOAP 1.1 Node where fault occurred <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/ xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault xmlns= > <faultcode>soap-env:client</faultcode> <faultstring>client Error</faultstring> <faultactor>some-uri</faultactor> <detail> <e:myfaultdetails xmlns:e="some-uri"> <e:message>stock symbol not found.</e:message> <e:errorcode>404</e:errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Namespace qualified value Human readable explanation Use the detail element only if the fault occurred while processing the body of a SOAP message
SOAP encoding SOAP provides a set of encoding rules from XML to SOAP types Three basic constructs are supported: Simple types Compound types Arrays SOAP encoding can also preserve relationships between values For example, multiple references to the same address can be expressed without requiring the address to be serialized several times The use of SOAP encoding can affect interoperability It should, therefore, be avoided where possible WS-I Basic Profile forbids the use of SOAP encoding
Encoding formats in SOAP For RPC messaging, parameters must be encoded into XML Two common approaches exist: Encoded Serialization rules defined in Section 5 of the SOAP 1.1 specification, which specify how objects, structures, arrays, and object graphs should be serialized. Detailed information is provided in the next slide. Literal Serialization is performed using an XML schema. This provides four possible combinations of messaging type and encoding style for a SOAP message: Document/literal Document/encoded RPC/literal RPC/encoded The rules of the WS-I Basic Profile forbid the use of RPC/encoded This option should therefore be avoided where possible
SOAP binding SOAP binding relates to the protocol used to carry SOAP messages between SOAP nodes. Each pair of nodes in the message path may use a different protocol and hence a different binding. SOAP messages do not contain binding information. SOAP over HTTP is the common binding for SOAP messaging. Binding A Binding B
SOAP over HTTP The HTTP (Hypertext Transport Protocol) request message is split into two sections: Header - Contains addressing information for the recipient of the SOAP message Body - Contains the contents of the SOAP message The HTTP header contains a SOAPAction attribute, which identifies the request to the Web server as SOAP-related.
SOAP HTTP example POST /ServiceWeb/services/OrderProcessor HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: text/xml User-Agent: IBM WebServices/1.0 Host: localhost:9080 Cache-Control: no-cache Pragma: no-cache SOAPAction: "" Content-Length: 473 <?xml version="1.0" encoding="utf-8"?> <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsd="http://www.w3.org/2001/xmlschema" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance">... </soapenv:envelope>
SOAP over HTTP: Request - response The request-response exchange pattern is supported via the use of POST requests POST requests should always return a SOAP response message POST Processor 1 Processor 2 Time symbol, shares Receipt (SOAP) BuyShares BuySharesResponse
Status of SOAP SOAP 1.1 has the status of a W3C note; it is not a formal recommendation Many SOAP 1.1 implementations exist: Apache SOAP Apache Axis IBM WebSphere V5 Web services run time Microsoft.NET SOAP 1.2 has been released and has the status of a W3C recommendation a standard This version supersedes SOAP 1.1 Few SOAP 1.2 implementations exist at present WS-I Basic Profile requires the use of SOAP 1.1
Other resources SOAP information SOAP 1.1 and 1.2 specifications SOAP 1.2 Primer Where you can get it http://www.w3.org/tr/soap/ http://www.w3.org/tr/soap12-part0 Links to SOAP resources General information about Web services http://www.xml.org/xml/resources_focus_soap.shtml http://www.ibm.com/developerworks/webservices/
Unit summary In this module, you have learned: The structure of a SOAP message The two different types of SOAP messaging The two different types of SOAP encoding How SOAP error handling works How SOAP uses network communication to send messages
Checkpoint questions 1. Which elements might be found inside a SOAP message? A. Body B. Detail C. HEADER D. Fault 2. What is the purpose of a namespace? 3. Name the two types of SOAP messaging. A. Encoded B. Document C. Faults D. RPC 4. SOAP faults: A. Should be used to indicate an error while processing the SOAP body B. Will always be returned to the service requester C. Can contain application-specific errors D. Are contained in the SOAP header
Appendix The following topic is included for your reference: SOAP 1.2
Overview of SOAP 1.2 Introduced changes in the syntax of SOAP messages Cannot specify SOAP encoding inside the envelope tag Considerable changes to the way faults are handled Renamed many of the fault elements and codes Redefined the structure of the fault tag The presence of the details element in a fault no longer signals the error occurred in the body Faults may contain a node element which contains the URI of the SOAP processor where the error occurred SOAP HTTP binding changes SOAPAction is no longer a required attribute New HTTP status code used by Web servers for SOAP messages Can use an HTTP GET to send SOAP messages to ensure idempotent requests SOAP RPC Defines a result attribute specifying the return value in a RPC request
SOAP 1.2 example fault <env:body xmlns:rpc="http://www.w3.org/2002/06/soap-rpc" xmlns:e="some-uri"> <env:fault> <Code> <Value>env:Sender</Value> <Subcode> <Value>rpc:BadArguments</Value> <Subcode> <Value>e:NoSuchSymbol</Value> </Subcode> </Subcode> </Code> <Reason xml:lang="en-us">processing Error</Reason> <Node>Some-URI</Node> <Role>Some-URI</Role> <Detail> <e:myfaultdetails> <e:message>stock symbol not found.</e:message> <e:errorcode>404</e:errorcode> </e:myfaultdetails> </Detail> </env:fault> </env:body> The value of the code element must be in the envelope namespace. Subcode values should represent an application specific sub-category of the enclosing levels' value. They must not reside in the envelope namespace. Human readable explanation Node where fault occurred Node's role in the message chain Note: The envelope element has been removed for clarity; the envelope namespace is the default namespace.
SOAP 1.2 example RPC Request <env:envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:body env:encodingstyle="http://www.w3.org/2002/06/soap-encoding"> <GetLastTradePrice xmlns="some-uri"> <symbol>def</symbol> <currency>usd</currency> </GetLastTradePrice> </env:body> </env:envelope> Response <env:envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"> <env:body env:encodingstyle="http://www.w3.org/2002/06/soap-encoding/"> <m:getlasttradepriceresponse xmlns:m="some-uri" <m:price>34.1</m:price> <m:currency>usd</m:currency> <rpc:result xmlns:rpc="http://www.w3.org/2002/06/soap-rpc"> m:price </rpc:result> </m:getlasttradepriceresponse> </env:body> </env:envelope> SOAP-RPC namespace The use of the result element is optional.
Web Services Description Language
Unit objectives After completing this unit, you should be able to: Describe the role of WSDL in Web services Identify the components of a WSDL document Interpret the WSDL description of a SOAP message Create a schema for a WSDL document Apply schema best practices to a WSDL document WSDL message patterns
What is WSDL? Describes the interface of a Web service using an XML standard Expresses binding information and location information for published Web services Contains operations and messages that are: Defined abstractly Bound to a network protocol and message format Uses the W3C XML schema type system for type information Provides a functional description of network services: Interface description Protocol and deployment details Platform independent description Extensible language
Where does WSDL fit in the SOA? Tools use WSDL to generate Web service skeletons and Web service clients Reference or URL Service Broker Service Description (WSDL) Find SOAP SOAP Publish Create description Service Requester SOAP Bind or interact Service Provider Service
Uses for WSDL Allows for the dynamic discovery and binding of services Services can advertise their description in a WSDL file A service registry like UDDI can point to these files to allow for dynamic discovery and use Allows a way for industries to define standard service interfaces Provides a normalized description of heterogeneous applications
WSDL structure porttype Abstract definition of a service Same idea as a Java interface binding How to access the porttype Multiple bindings per porttype HTTP, JMS, SMTP, and so on port Represents an individual endpoint service Something which can be invoked Represents a collection of ports binding (SOAP+HTTP) porttype operation b operation a inmessage outmessage faultmessage binding (SOAP+SMTP) service port port
WSDL elements Services are described using seven major elements. These WSDL elements are contained within a single definitions element. Element type message operation porttype binding port service Description The definition of a data type that is exchanged on the interface to a Web service; typically expressed in XML schema. The execution of an operation may involve zero to three exchanges of information: a request, a response, and a fault. A message defines the information in a single exchange. An operation that is available to the client of the service with references to the messages involved. A logical grouping of operations. Used to identify operations that are intended to be available at the same network location. An association between a porttype and a protocol binding such as SOAP over HTTP. The association of a specific network address with a binding. The declaration of a service and the ports on which it is available.
The relationships between WSDL elements Custom type definitions A porttype involves one or more operations definitions types targetnamespace=mynamespace xmlns:tns=mynamespace message name=in An operation involves one, two or three messages A binding involves one porttype A binding specifies the marshaling specifics for the operations Each port is specific to a given binding message name=out porttype name=myporttype operation input message=tns:in output message=tns:out binding name=mybinding type=tns:myporttype operation operation input (marshaling spec) output (marshaling spec) service port name=myservice name=myport binding=tns:mybinding Abstract Concrete
WSDL sample (1 of 5) <wsdl:definitions targetnamespace=http://stockquote xmlns:impl=http://stockquote Root node is always definitions xmlns:intf=http://stockquote xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ xmlns:wsdlsoap=http://schemas.xmlsoap.org/wsdl/soap/ xmlns:wsi=http://ws-i.org/profiles/basic/1.1/xsd xmlns:xsd="http://www.w3.org/2001/xmlschema"> <wsdl:types> <schema targetnamespace=http://stockquote xmlns=http://www.w3.org/2001/xmlschema xmlns:impl="http://stockquote" xmlns:intf=http://stockquote xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ xmlns:xsd="http://www.w3.org/2001/xmlschema"> <element name="getquote"> <complextype> <sequence> <element name="symbol" nillable="true" type="xsd:string"/> </sequence> </complextype> </element> <!--element declaration for getquoteresponse with child element getquotereturn of type float omitted for readability --> </schema> </wsdl:types>... </wsdl:definitions> Uses XML schema for types definition
WSDL sample (2 of 5) <wsdl:message name="getquoteresponse"> <wsdl:part element="impl:getquoteresponse" name="parameters"/> </wsdl:message> <wsdl:message name="getquoterequest"> <wsdl:part element="impl:getquote" name="parameters"/> </wsdl:message> message declarations
WSDL sample (3 of 5) message direction <wsdl:porttype name="stockquoteservice"> <wsdl:operation name="getquote"> <wsdl:input message="impl:getquoterequest name="getquoterequest"/> <wsdl:output message="impl:getquoteresponse name="getquoteresponse"/> </wsdl:operation> </wsdl:porttype> porttype declaration
WSDL sample (4 of 5) <wsdl:binding name="stockquoteservicesoapbinding" type="impl:stockquoteservice"> <wsdlsoap:binding style="document" porttype reference transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="getquote"> <wsdlsoap:operation soapaction=""/> <wsdl:input name="getquoterequest"> <wsdlsoap:body use="literal"/> </wsdl:input> <wsdl:output name="getquoteresponse"> <wsdlsoap:body use="literal"/> </wsdl:output> </wsdl:operation> </wsdl:binding> messaging style binding specific marshaling information binding definitions
WSDL sample (5 of 5) port declaration <wsdl:service name="stockquoteserviceservice"> <wsdl:port binding="impl:stockquoteservicesoapbinding" name="stockquoteservice"> <wsdlsoap:address location="http://localhost:9080/..."/> </wsdl:port> </wsdl:service> service endpoint service definition
Mapping WSDL to SOAP - Request binding specifies POST /StockQuote/services/StockQuoteService HTTP/1.1 Host: localhost:7248 SOAP over HTTP Content-Type: text/xml; charset=utf-8 from port Content-Length: 354 declaration Accept: application/soap+xml, application/dime, multipart/related, text/* SOAPAction: binding specifies value for SOAPAction <soapenv:envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/ xmlns:soapenc= http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsd= http://www.w3.org/2001/xmlschema xmlns:xsi= http://www.w3.org/2001/xmlschema-instance > <soapenv:header/> <soapenv:body> <p424:getquote xmlns:p424= http://stockquote > <symbol>ibm</symbol> </p424:getquote> </soapenv:body> </soapenv:envelope> <!-- Some HTTP headers removed for readability --> operation name message part name and type
Mapping WSDL to SOAP - Response HTTP/1.1 200 OK Content-Type: text/xml; charset=utf-8 Content-Language: en-us Content-Length: 470 Connection: Close binding specifies SOAP over HTTP <soapenv:envelope xmlns:soapenv= http://schemas.xmlsoap.org/soap/envelope/ xmlns:soapenc= http://schemas.xmlsoap.org/soap/encoding/ xmlns:xsd= http://www.w3.org/2001/xmlschema xmlns:xsi= http://www.w3.org/2001/xmlschema-instance > <soapenv:header/> <soapenv:body> response message name <p424:getquoteresponse xmlns:p424= http://stockquote > <getquotereturn>76.15</getquotereturn> </p424:getquoteresponse> </soapenv:body> </soapenv:envelope>
Specifying information types A types element defines data types used by the service: When non-standard schema types or a type system other than XML schema are used to describe a service The XML schema type system is most commonly used. There are guidelines for the use of XML schema in this context: Avoid the use of attributes in type specifications Use xsd:anytype for items that are untyped For example, java.lang.object Avoid the use of SOAP encoding SOAP encoding makes interoperability more difficult WS-I Basic Profile 1.0 forbids the use of SOAP encoding Use standard types where possible for example, use xsd:string instead of soap-enc:string
Using XML schema in WSDL Keep it simple: Use: Basic primitive types minoccurs and maxoccurs Enumeration Be careful using: Model groups and attribute groups Lists and unions Derived types by restriction Use namespaces: Define a targetnamespace for your schema Use elementformdefault= qualified Avoid overloaded operations: Not allowed by WS-I Basic Profile Use unique request/response wrapper
Specifying WSDL operations WSDL operations are transmission primitives that can be supported by an endpoint. Four transmission primitives are defined: One-way Request-response Solicit-response Notification
Using transmission primitives One-way: <porttype name="stockquote"> <operation name="subscribetostockquotes"> <input message="tns:subscribetostockquotes"/> </operation> </porttype> Request-response: <porttype name="stockquote"> <operation name="gettradeprice"> <input message="tns:gettradepricerequest"/> <output message="tns:gettradepriceresponse"/> </operation> </porttype>
Factoring WSDL files WSDL files contain several sections that are potentially reusable: Reuse is made easier by factoring them into several separate files. Separate files can be useful for reusing: Types Message definitions porttypes WSDL documents can be assembled from several parts using an import element.
WSDL generation WSDL documents can be created manually. This is sometimes necessary when non-typical design choices are made. Rational Application Developer provides a graphical view of a WSDL file. Several mechanisms for automated generation exist. Rational Application Developer provides WSDL generation tooling. The Java community is working on JSR 110. This is an effort to create standard Java APIs for WSDL. The purpose is to dynamically read WSDL files at run time.
WSDL editor
Status of WSDL WSDL 1.1 was a submission to the World Wide Web Consortium (W3C). Produced by IBM, Microsoft and Ariba WSDL 1.1 has the status of a W3C Note, which is a draft specification It is unlikely that WSDL 1.1 will be updated WSDL 2.0 is currently available on W3C in draft form. Port renamed endpoint porttype renamed interface Interface inheritance is now possible Eliminates some of the complexity in 1.1
Other resources (1 of 2) Related Information WSDL 1.1 specification SOAP Links to SOAP resources General information about Web services XML schema JSR 110 - JWSDL Where you can get it http://www.w3.org/tr/wsdl http://www.w3.org/2000/xp/group/ http://www.xml.org/xml/resources_focus_soap.shtml http://www.ibm.com/developerworks/webservices/ http://www.w3.org/xml/schema http://www.jcp.org/jsr/detail/110.jsp
Other resources (2 of 2) WSDL generators Location Apache Axis Web site Microsoft.NET Web service framework http://xml.apache.org/axis/ http://msdn.microsoft.com/netframework/
Checkpoint questions 1. What are the reasons for using WSDL in a Web services architecture? A. A WSDL document serves as a non-platform specific interface definition for the service. B. Client stubs can be automatically generated from WSDL documents. C. WSDL documents for a service can only be found in a public registry. D. The W3C mandates the use of WSDL. 2. Which of the following is NOT an element defined by the WSDL specification? A. types B. soapbinding C. operation D. port 3. Why is the operations element used twice inside a WSDL document?
Unit summary In this module, you have learned: How WSDL describes a Web service using standard XML markup The components of a WSDL document How a SOAP service can use a WSDL document to send messages to a Web service
J2EE support for Web services
Unit objectives After completing this unit, you should be able to: State the support provided for Web services in WebSphere Application Server V6 Describe the purpose of JAX-RPC Identify the components of JAX-RPC Describe the purpose of Web Services for J2EE Identify the components of Web Services for J2EE
Apache Axis Apache Axis 1.0 Web Services runtime: Open source Web services project SAX-based Not recommended for production use in WebSphere Application Server V6
Web services support in WebSphere IBM WebSphere Web Services V6 runtime: Parses using SAX Implements J2EE Web services standards in J2EE 1.4 Focuses on compliance with a standard programming and deployment model Supports JAX-RPC 1.1 Java APIs for XML-based remote procedure calls (previously JSR101) Supports Web Services for J2EE 1.1 (previously JSRs109,921) Provides enhanced Web services support
Web service runtime SOAP/HTTP Service Requester WSDL WSDL Service Provider Application Java Proxy SOAP Client HTTP Client WebSphere Application Server SOAP SOAP Bean EJB Web Services Engine Web Services Servlet Web Container HTTP Server
Web service runtime SOAP/JMS Service Requester WSDL WSDL Service Provider Application Java Proxy SOAP Client WebSphere Application Server EJB MDB and Web Services Engine JMS Client SOAP SOAP EJB Container
Overview of the Web services runtime Here are just a few of the responsibilities of a Web services runtime: Listen for Web services requests Parse the inbound message Map the message to the implementation class and method according to the service deployment data Map SOAP to JAX-RPC Java objects Invoke the service-specific handlers and service instance method Capture the response Create SOAP response from Java response Create the message envelope appropriate for the transport Send the message to the originating Web service client
Defining J2EE The Java 2 Platform, Enterprise Edition (J2EE) consists of: The J2EE platform A standard platform of containers, services, and communications The J2EE Compatibility Test Suite To verify that a J2EE platform product complies with the standard WebSphere Application Server 5.0 is J2EE 1.3 compatible WebSphere Application Server 6.0 is J2EE 1.4 compatible The J2EE Reference Implementation For prototyping J2EE applications and for providing an operational definition of the J2EE platform The J2EE Blueprints Best practices for developing multi-tier, thin-client applications J2EE is developed using the Java Community Process Standards development is a collaboration between major enterprise software vendors IBM actively contributes to the J2EE development process
JAX-RPC features Java API for XML-based remote procedure calls: Defines a standard mapping model from Java artifacts using a WSDL document WSDL porttype maps to a service endpoint interface (SEI) WSDL service maps to a service interface WSDL input, output, fault messages map to method signature WSDL complex elements maps to a custom class Describes a J2EE-based server programming model which assumes WSDL document is available when the service is invoked Introduces a handler model Defines client APIs to access a Web service for clients not running in a server-side container
JAX-RPC: Type mapping Web services runtime exceptions Based on the standard approach to service endpoint interface design and its mapping to wsdl:fault elements These exception types are derived from the java.lang.exception class <wsdl:porttype name="transfer_sei"> <wsdl:operation name="transferfunds parameterorder="fromacctid toacctid amount"> <wsdl:input name="transferfundsrequest message="impl:transferfundsrequest"/> <wsdl:output name="transferfundsresponse message="impl:transferfundsresponse"/> <wsdl:fault name="insufficientfundsexception message="impl:insufficientfundsexception"/> </wsdl:operation> </wsdl:porttype> Faults map to exceptions
JAX-RPC: Server programming model WSDL to Java javax.rmi.remote generates Service Endpoint Interface Service LifeCycle Interface Service Implementation Class
Service endpoint model diagram WSDL Document WSDL/Java Mapping Service Endpoint JAX-RPC Core APIs Server-Side JAX-RPC Runtime Environment Messaging Protocol Transport Protocol
JAX-RPC: Handlers Handlers provide a mechanism for intercepting the SOAP message: SOAP message handlers can intercept SOAP messages in both the request and response phases Typical handler activities include encryption and decryption, logging, and auditing Handlers are service specific and defined in the deployment descriptor
Web services for J2EE Deployment model Defines a deployment model for Web services Server-side Implementations exposed as Web services are declared in a deployment descriptor, webservices.xml. Client-side Web services clients running inside a J2EE server-side container can use Web services references declared in the deployment descriptor of the appropriate module. Server-side programming model How Web services can be implemented and deployed Client-side programming model How J2EE applications can access Web services
Deployment descriptors Web Services for J2EE defines a new deployment descriptor for J2EE: webservices.xml, for the service provider Web Services for J2EE defines an XML file for the mapping metadata: JAX-RPC defines the types to be mapped between WSDL/XML and Java WebSphere adds platform-specific deployment descriptors These cover WebSphere extensions and binding information such as security to Web Services for J2EE Service provider ibm-webservices-bnd.xmi ibm-webservices-ext.xmi J2EE Web Services client ibm-webservicesclient-bnd.xmi ibm-webservicesclient-ext.xmi
Example: webservices.xml (1 of 2) <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE webservices PUBLIC "-//IBM Corporation, Inc.//DTD J2EE Web services 1.0//EN http://www.ibm.com/webservices/dtd/j2ee_web_services_1_0.dtd"> <webservices> <webservice-description> <webservice-description-name> EchoService </webservice-description-name> <wsdl-file>web-inf/wsdl/echo.wsdl</wsdl-file> <jaxrpc-mapping-file> WEB-INF/Echo_mapping.xml </jaxrpc-mapping-file>...
Example: webservices.xml (2 of 2)... <port-component> <port-component-name>echo</port-component-name> <wsdl-port> <namespaceuri>http://javabean.service</namespaceuri> <localpart>echo</localpart> </wsdl-port> <service-endpoint-interface> service.javabean.echo </service-endpoint-interface> <service-impl-bean> <servlet-link> service_javabean_echo </servlet-link> </service-impl-bean> </port-component> </webservice-description> </webservices>
Example: web.xml (1 of 2) <web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" id="webapp_id" version="2.4" xsi:schemalocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd"> <!-- Non-applicable portions of web.xml removed for readability --> <service-ref> <description> WSDL Service EchoService </description> <service-ref-name> service/echoservice </service-ref-name> <service-interface> service.javabean.echoservice </service-interface> <wsdl-file>web-inf/wsdl/echo.wsdl</wsdl-file> <jaxrpc-mapping-file> WEB-INF/Echo_mapping.xml </jaxrpc-mapping-file>...
Example: web.xml (2 of 2)... <service-qname> <namespaceuri>http://javabean.service</namespaceuri> <localpart>echoservice</localpart> </service-qname> <port-component-ref> <service-endpoint-interface> service.javabean.echo </service-endpoint-interface> </port-component-ref> </service-ref> </web-app>
Server-side programming model Web Services for J2EE defines the components which can be made available as Web services Port defines the server view of Web service provider The port component services the operations defined in WSDL The port component has a service endpoint interface and a service implementation The service implementation can be a stateless session EJB or a JavaBean J2EE Container WSDL Port Implementation (JavaBean or Stateless Session EJB) Service Endpoint Interface Listener Web Services Client
Web services clients JAX-RPC (unmanaged) client Stand-alone Java client Defined in the JAX-RPC specification, not in Web Services for J2EE WSDL definition of a Web service provides enough information for a stand-alone client to be built and run Web Services for J2EE (managed) client Runs in a J2EE container and uses J2EE runtime to look up and invoke a Web service Can be: J2EE application client Web component (servlet or JSP) EJB component
JAX-RPC client model diagram WSDL Document WSDL/Java Mapping Service Client Stub JAX-RPC Core APIs Client-Side JAX-RPC Runtime Environment Messaging Protocol Transport Protocol
JAX-RPC unmanaged clients (1 of 2) There are three ways in which a JAX-RPC client might access a Web service: Stub or proxy method access to the ports Service specific client requires WSDL knowledge that has service location included and uses appropriate tooling to create the stub LibraryStub mystub = (LibraryStub)LibraryService.getLibrary(); mystub.getbook( Intro to Java"); Dynamic proxy method Used when a client needs dynamic, non stub-based communication with the Web service LibraryProxy myproxy = (LibraryProxy) LibraryServiceLocator.getPort(new QName( namespace, portname ), LibraryProxy.class); myproxy.getbook( Intro to Java");
JAX-RPC unmanaged clients (2 of 2) Dynamic invocation interface (DII) Allows clients to invoke a Web service operation at run time without using a proxy or stub Uses a java.xml.rpc.call object to store attributes to invoke a Web service without using a WSDL document
Web service managed client example Client needs Web service provider WSDL Uses the Java Naming and Directory Interface service (JNDI) to look up the Web service Gets the service locator From service locator, the client gets a stub ctx = new InitialContext(); EchoService es = (EchoService) ctx.lookup( "java:comp/env/service/echoservice"); Echo echosei = es.getecho(); //port reply = echosei.echo("hello, world!");
Other resources Resource WebSphere InfoCenter Location http://www.ibm.com/software/webservers/appserv/infocenter.html Web Services for J2EE information JAX-RPC specification Web services for J2EE specification Build interoperable Web services with JSR-109 General information about Web services Where you can get it http://java.sun.com/xml/downloads/jaxrpc.html http://jcp.org/aboutjava/communityprocess/final/jsr921/index.html http://www.ibm.com/developerworks/webservices/library/ws-jsrart/ http://www.ibm.com/developerworks/webservices/
Checkpoint questions 1. Which Java artifact does a WSDL porttype map to? A. Service endpoint implementation B. Service interface C. Service endpoint interface D. Service locator 2. According to Web services for J2EE, which Java artifact or artifacts can be exposed as a Web service? A. JavaBean B. Entity bean C. Stateless session bean D. Servlet 3. Which of the following statements regarding JAX-RPC handlers are true? A. Handlers are only defined in the Web deployment descriptor. B. Handlers can be used for logging Web service requests. C. Handlers can only be configured for in-bound requests. D. Handlers can be configured for clients and for services. 4. True or False. A Web service client using a dynamic proxy does not need access to a WSDL document.
Unit summary In this module, you have learned: The relationship between the J2EE Web services technologies: JAX-RPC and Web Services for J2EE The client and server programming model The contents of the deployment descriptor files The mechanisms used by clients to access Web services
Creating Web services using IBM Rational Application Developer V6
Unit objectives After completing this unit, you should be able to: Describe the support provided by IBM Rational Application Developer V6 for Web services development Differentiate between bottom-up and top-down Web services development Generate a Web service from an existing JavaBean using the Web services wizards Generate a Web service from an existing WSDL document using the Web services wizards Test a Web service using the Web Services Explorer Monitor Web services using the TCP/IP monitor
Creating a Web service from a JavaBean Scenario: A JavaBean holds behavior that is needed by a wide range of clients. The clients are implemented in various technologies but all are capable of sending or receiving XML over HTTP. A decision has been made to make the JavaBean available as a Web service. The service is being created using WebSphere Studio Application Developer. JavaBean implementation <service>.java Rational Application Developer webservices.xml Runtime deployment descriptor Service description in WSDL
Creating a Web service from WSDL Scenario: A WSDL service description has been developed by a group of partner companies who are collaborating in an e- business endeavor. Services that conform to the description must now be created by the partners. In this case, Rational Application Developer is used. Common WSDL Rational Application Developer Server stub containing skeleton methods for each operation described in the WSDL and service interface <service>.wsdl <service>.java <service>soapbindingimpl.java
Top-down versus bottom-up development Top-down Web services development: Starts with a WSDL Centers more on business requirements Tools generate Java skeleton? WSDL Bottom-up Web services development: Starts with Java code Is more sensitive to needs of developers Tools generate WSDL?? Web Service?? Java
Example JavaBean package converters; import java.io.serializable; public class Celsius implements Serializable { public Celsius() { } } public float tocelsius(float fahrenheit) { return (fahrenheit - 32) * 5 / 9; } A Web service will be created from this simple JavaBean
Deploy a JavaBean Web service (1 of 5)
Deploy a JavaBean Web service (2 of 5) On the Object Selection Page, verify selection of your JavaBean. Pressing Edit on the Service Deployment Configuration page allows the deployment options to be modified.
Deploy a JavaBean Web service (3 of 5) You can select an existing service endpoint interface A new service endpoint interface will be created, if none exists.
Deploy a JavaBean Web service (4 of 5) The wizard fills in default values based on the Web project and JavaBean class. The URI is based on the settings in the Web project. You can select the methods in the JavaBean that you want to expose. Style and Use allows you to choose the way in which you want your Web service to be used. Custom mapping of packages and namespaces may be needed.
Deploy a JavaBean Web service (5 of 5) The tool maps package names directly to namespaces. Selecting the check box titled Define Custom Mapping for package to namespace allows you to define a different mapping. You can also publish the Web service to a registry at a later point in time.
Files generated by the wizard Service endpoint interface JAX-RPC type mapping for the Web service WSDL service descriptions (identical) Application Developerspecific binding Application Developerspecific extensions Web services deployment descriptor
Other generation options You can generate a Web service from a WSDL or from an Enterprise JavaBean. From WSDL Generates skeleton JavaBean and service endpoint interface JavaBean methods can be tied into the existing application From EJB Additional configuration parameters required in the wizard Some generated assets stored in the EJB project May still need the Web project to provide access to service
Testing Web services IBM Rational Application Developer provides two methods of testing a Web service: Web Services Explorer Lets you configure multiple endpoints Includes a status window which shows SOAP messages Lets you test with WSDL; no other code is necessary Sample proxy code and JavaServer Pages Generated proxy code may be used in a client later JSPs include utility methods to configure endpoints TCP monitor is available to view SOAP messages and HTTP headers
Test: Web Services Explorer (1 of 3) Right-click the generated WSDL file and select Web Services -> Test with Web Services Explorer
Test: Web Services Explorer (2 of 3) Expand the service in the left-hand frame Endpoints can be added to test services on other servers
Test: Web Services Explorer (3 of 3) Select the endpoint you want to test Enter values for the parameters and click Go The results are shown in the bottom frame
Monitoring Web services TCP/IP monitor is configured through Windows-> Preferences->Internet menu Can be enabled to show the view automatically whenever TCP/IP activity is present Can be created manually or by choosing Monitor Web Service in the Web service creation wizard
Checkpoint questions 1. Which artifact do you start with to create a top-down Web service? A. JavaBean B. Stateless session bean C. WSDL D. Service endpoint interface (SEI) 2. Which of the following files can be created by the Rational Application Developer tooling when creating a Web service? A. JAX-RPC mapping file B. Web service implementation class C. Service endpoint interface D. WSDL E. All of the above 3. Which of the following statements are true regarding the Web Services Explorer as a test client? A. To test a Web service, you must generate proxy code for the test client. B. The Web service must be running in your local test environment. C. A WSDL is needed to test the service. D. Multiple endpoints can be configured for the service.
Unit summary In this module, you have learned: How to create a Web service from an existing JavaBean in WebSphere Studio Application Developer How easy it is to take existing code and convert it into a Web service The differences between top-down and bottom-up development How to test a Web service using the Web Services Explorer How to view SOAP messages using the TCP/IP monitor
SW501 exercise overview
Unit objectives After completing this unit, you should be able to: Describe the business scenario behind the lab exercises you will perform in this course Understand the progression that the labs follow
Community of lending libraries The remaining exercises in this course follow the evolution of a Web services network supporting a community of lending libraries. The scenario begins with a single library that starts to experiment with Web services. Upon completion, you will have two libraries that collaborate by sharing their resources for: Searching for publications by author, title, and ISBN Returning Book JavaBeans for located publications
Initial point Separate proprietary systems North Library Each library has an inventory of publications and a system for searching it. The various library systems do not communicate. South Library
Exercise 3 North Web service North Library JavaBeans Use cases supported are: - Search for book (by author, by title, by ISBN) - Retrieve an Item object (publication) from the service wrapped JavaBean
Exercise 4 North-south partnership wrapped JavaBean North Library South Library Interface formalized in WSDL The South Library creates a Web service skeleton from WSDL provided by the North Library and integrates the skeleton with their library system.
Exercise 5 Web services clients North Library Library Community South Library North Library members South Library members
Exercise 6 Registration using UDDI Library Community North Library South Library North Library members UDDI South Library members
Dynamic binding to services Library Community North Library South Library North Library members UDDI South Library members
Unit summary In this module, you have learned: The business scenario behind the lab exercises you will perform in this course The progression that the labs follow
Creating Web service clients using IBM Rational Application Developer V6
Unit objectives After completing this unit, you should be able to: Generate a Web service client from a WSDL file using the Web service wizards Invoke Web services using a Java proxy Create a JAX-RPC client that invokes a Web service running on WebSphere Application Server V6 Monitor message flow between a service client and service using the TCP/IP monitor
Java Web service clients Any application that interacts with a Web service is a Web service client This includes stand-alone applications, Web applications, applets, other Web services, and so forth. Web Service Applet Web Service Application Servlet
Web service client runtime Java Web service clients require client-side runtime support The runtime generates the SOAP messages and sends them to the Web service The IBM Web Services Runtime provides a solution Based on the Java API for XML-based remote procedure calls standard Java Client Logic Client Runtime (for example, JAX-RPC implementation) Internet Internet Web Service SOAP SOAP
Creating a Web service client 1. Obtain the interface description (WSDL) for the service 2. Use Rational Application Developer to generate a client proxy for the Web service from the WSDL 3. Instantiate a client proxy instance in your client application and use it to exchange messages and requests with the Web service Java Client Logic Generated Web Service Proxy IBM WebSphere Web Services Runtime Internet Internet SOAP SOAP Web Service
Detailed development steps 1. Locate the WSDL for the service with which you wish to interact, possibly importing it into Rational Application Developer. 2. Create a project to hold the client program or use an existing project. 3. Generate a JavaBean proxy from the WSDL file. 4. Add the required JAR files to your project build path, if you are not building a Web application. 5. Insert code in your client application to create an instance of the service locator. 6. Use the service locator method to obtain a service proxy. 7. Add code to invoke service operations as required. 8. Run the client application.
Web service client from WSDL Scenario: Developers of an existing Java application wish to add a feature to use a function already provided by an existing Web service. They have already acquired the WSDL for the service from the service provider. WSDL <service>.wsdl Rational Application Developer Client proxy generated from the port, binding and porttype information. Web Service Proxy <service>.java
Create Web service client proxy (1 of 3) Select Web Services -> Generate Client from the context menu of the WSDL file
Create Web service client proxy (2 of 3) Client type options: Web EJB Application client Java The proxy code has to go into an existing Web project
Create Web service client proxy (3 of 3) Define custom mapping, if necessary. Click Finish.
Files generated by wizard Java code representing the client proxy XML file defining type mapping Deployment descriptor files
Client proxy class diagram
Standalone Java client A standalone Java client can also be created using the wizard: Create a Java project Generate the client using the wizard with Client type = java Set _usejndi = false in the serviceproxy code
Using the generated proxy 1. Create an instance of the serviceproxy. 2. Call methods as normal. Code snippet try { CelsiusProxy proxy = new CelsiusProxy(); ctemp = proxy.tocelsius(ftemp); System.out.println ("The temperature in Celsius is: " + ctemp); } catch(remoteexception re) { System.err.println(re.getMessage()); } Result The temperature in Celsius is: 30.555555
Testing the proxy (1 of 2) Use a Scrapbook page to test the proxy
Testing the proxy (2 of 2) 1. Enter your code. 2. Right-click and select Execute from the context menu. converters.celsiusproxy proxy = new converters.celsiusproxy(); System.out.println(proxy.toCelsius(87)); 3. Your results are displayed in the console.
Using the TCP/IP monitor (1 of 2) Rational Application Developer provides a TCP/IP monitor which intercepts and displays TCP/IP communication: It listens on a specified port and relays incoming information to another application The TCP/IP Monitor view displays the message traffic Select Window -> Preferences and then select Internet -> TCP/IP Monitor
Using the TCP/IP monitor (2 of 2) A TCP/IP monitor can be created two ways: Automatically by Web service wizard Manually through Internet -> TCP/IP Monitor Use the TCP/IP Monitor view to observe the SOAP messages passing back and forth between the client and the service.
Changing the service endpoint Generated JSPs include methods to temporarily change the service endpoint. Web Services Explorer allows you to add endpoints for testing. The endpoint used by the proxy code is found in serviceservicelocator.java. celsius_address = "http://localhost:9080/sampleservice/services/celsius";
Checkpoint questions 1. How can a TCP/IP monitor be created? A. The developer creates a special type of test server through the Servers perspective. B. A TCP/IP monitor is configured through the project properties. C. A TCP/IP monitor can be created automatically by the Web Service Wizard D. A TCP/IP monitor can be created through the window preferences menu. 2. In which generated class can the service endpoint address be found? A. serviceservicelocator B. serviceproxy C. service_sei D. servicesoapbindingstub
Unit summary After completing this unit, you should be able to: Create a Web service client from a WSDL file in Rational Application Developer Use a proxy instance to interact with a Web service Use the TCP/IP monitor to observe message flow between the service client and the service
Overview of UDDI
Unit objectives After completing this unit, you should be able to: Describe the UDDI registry model Publish Web services using the Web Services Explorer Find Web services using the Web Services Explorer Describe the relationship between UDDI and WSDL
UDDI overview UDDI = Universal Discovery, Description and Integration UDDI is a Web service discovery platform specification UDDI is: A Web service implementation A categorized Web services metadata database UDDI defines a replication protocol for cooperating servers Some history: UDDI was originally developed by IBM, Microsoft, and Ariba and is now managed by the Organization for the Advancement of Structured Information Standards (OASIS)
Where does UDDI fit in SOA? A registry is needed for finding and publishing Web services. UDDI functions as that registry. Reference or URL Service Broker Service Description (WSDL) Find SOAP SOAP Publish Create description Service Requester SOAP Bind or interact Service Provider Service
UDDI is distributed UDDI servers are replicated to provide redundancy All repository information is available at each replicated node Reg 1 Private Corporate Registry Reg 2 Reg 3.. UDDI Business Registry (generally available) Reg n
What does the registry contain? businessentity discoveryurls name description businesskey contacts operator categorybag identifierbag authorizedname * businessservice name servicekey description categorybag Published services * Service endpoint bindingtemplate description accesspoint hostingredirector servicekey bindingkey The publishing party Each service may have many bindings, for example, HTTP and FTP Each tmodel is a fingerprint for a published interface tmodel * name description overviewdoc identifierbag categorybag tmodelkey operator authorizedname
tmodels: Defining the technical fingerprint <<tmodel A>> <<tmodel B>> <<tmodel C>> ABindingTemplate tmodels are used to capture the details of a service interface and make them available for reuse among compatible services businessservices (via bindingtemplates) reference tmodels to advertise that they implement the related service interface
tmodels: Defining a namespace reference A tmodel is used to classify organizational identity and various other classification schemes. businessentity, businessservice, and tmodel reference tmodels in terms of a namespace while bindingtemplate references tmodels as a service type. A businessservice is classified within a particular geography by referencing a tmodel key that identifies the geographical category. tmodel name description tmodelkey operator authorizedname categorybag keyedreference [0..*] identifierbag keyedreference [0..*] overviewdoc description [0..*] overviewurl[1..*] tmodel references for taxonomy associations tmodel references to identify this tmodel Supporting documents for this tmodel
Methods to search the UDDI registry Human Search Service Registry Automated Search Find business by detail Find service by category White Pages Yellow Pages Find service by interface Green Pages The registry is logically arranged into three sections, each of which is intended for a specific kind of use
Example: Find a business - Request <?xml version="1.0" encoding="utf-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope"> <Body> <find_business generic="2.0" xmlns="urn:uddi-org:api_v2"> <name>ibm Corporation</name> </find_business> </Body> </Envelope> UDDI version 2.0 UDDI version 2.0 namespace Find all registered businesses whose names start with IBM Corporation
Example: Find a business - Response <?xml version="1.0" encoding="utf-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope/"> <Body> <businesslist generic="2.0" xmlns="urn:uddi-org:api_v2" operator="www.ibm.com/services/uddi" truncated="false"> <businessinfos> Services available Unique service key Unique business key <businessinfo businesskey="d2033110-3aaf-11d5-80dc-002035229c64"> <name xml:lang="en">ibm Corporation</name> <description xml:lang="en"> At IBM,... microelectronics. </description> <serviceinfos> <serviceinfo servicekey="894b5100-3aaf-11d5-80dc-002035229c64" businesskey="d2033110-3aaf-11d5-80dc-002035229c64"> <name xml:lang="en">buy from IBM</name> </serviceinfo>... </serviceinfos> </businessinfo> </businessinfos> </businesslist> </Body> </Envelope>
UDDI hosts provide search GUIs
Publishing information in UDDI Updates to a UDDI registry normally require authorization The first argument to all publishing operations is an <authinfo> element that contains an authorization token previously granted by the repository. The structure of the token is implementation-specific, but is commonly a simple character string. <?xml version="1.0" encoding="utf-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope"> <Body> <get_authtoken generic="2.0" xmlns="urn:uddi-org:api_v2" userid="auserid" cred="somevalue"/> </Body> </Envelope> Before any publishing may be done, the publisher must be authenticated by calling get_authtoken
Example: Publish a business - Request <?xml version="1.0" encoding="utf-8"?> <Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope"> <Body> <save_business generic="2.0" xmlns="urn:uddi-org:api_v2"> <authinfo>token</authinfo> <businessentity businesskey=""> <name>sample Business</name> </businessentity> </save_business> </Body> </Envelope> save_business accepts multiple businessentity elements. If any of the key values within the structure are empty, the server assumes that the element in question is a new entity and generates a key for it.
Example: Publish a business - Response Repository operator Generated business key Creating user... <businessdetail generic="2.0" xmlns="urn:uddi-org:api_v2" operator="www.mycompany.com/uddi"> <businessentity businesskey="142426f1-14b9-443b-8a7c-2a3213ff28c6" operator="www.mycompany.com/uddi" authorizedname="uddiuser"> <discoveryurls> <discoveryurl usetype="businessentity"> http:/.../get?businesskey=142426f1-14b9-443b-8a7c-2a3213ff28c6 </discoveryurl> </discoveryurls> <name xml:lang="en-us">sample Business</name> </businessentity> </businessdetail>... The only information provided A URL that can be used to retrieve the businessentity element
Categorizing information in UDDI (1 of 2) Three taxonomy systems are used to categorize services and businesses in UDDI: Industry North American Industry Classification System (NAICS) Products and Services United Nations Standard Products and Services Code (UNSPSC) Location Geographical taxonomy
Categorizing information in UDDI (2 of 2) Taxonomy classifications are referenced in categorybags Companies should register all relevant categories from each system IBM Corporation D2033110-3AAF-11D5-80DC-002035229C64 3342 NAICS: Comms Equip Manufacturing 51121 NAICS: Software Publishers 43.16.25.06.00 UNSPSC: Storage media loading software 43.16.26.01.00 UNSPSC: Platform interconnectivity software WORLD GEO
Identifier information in UDDI Two systems are used by businessservices and tmodels to include common forms of identification in UDDI: D-U-N-S: Unique nine-digit numbers which provide unique identifiers of single business entities and links corporate family structures Thomas Register: Supplier IDs used for finding companies and products manufactured in North America These keys are referenced in identifierbags
UDDI and WSDL UDDI data structures provide a framework for describing services and specifying how to access services. WSDL is an XML language for describing the interface, protocol bindings, and deployment details of Web services. How can these technologies interact? How are the services that conform to a WSDL description located? How is the WSDL file for a service accessed once the service has been found? WSDL complements the UDDI standard, since it provides a uniform way of describing a service.
Relationship between UDDI and WSDL Business Entity Business Service Binding Template Implementation Document Service Port UDDI Registry tmodel references Interface Document WSDL File contains
Associating WSDL with a service (UDDI v2) Service implementing a standard interface Standard service type tmodel Contains WSDL URL WSDL businessservice name servicekey description tmodel name description tmodelkey operator authorizedname Standard Service Type overviewdoc description [0..*] overviewurl[1..*] tmodel bindingtemplate description accesspoint hostingredirector servicekey bindingkey tmodelinstanceinfo categorybag keyedreference [0..*] Standard wsdlspec tmodel name description uuid:c1acf... operator authorizedname Well known key full key shown on next slide
Example: Defining tmodel for WSDL type To create a standard tmodel based on WSDL, a message like the following would be passed as an argument to save_tmodel <tmodel authorizedname="..." operator="..." tmodelkey="..."> <name>webcalc</name> <description xml:lang="en"> WSDL description of a standard web calculator service interface </description> <overviewdoc> <description xml:lang="en">wsdl source document.</description> <overviewurl> http://webcalc.org/wsdl/calc.wsdl </overviewurl> </overviewdoc> <categorybag> WSDL URL Built-in tmodel reference <keyedreference tmodelkey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyname="uddi-org:types" keyvalue="wsdlspec"/> </categorybag> </tmodel>
Example: Using the standard tmodel To associate a service with the standard tmodel, include the tmodel key in the tmodelinstancedetails of the appropriate binding template <businessservice businesskey="some business entity key" servicekey=""> <name>calculatorservice</name> <description>... </description> <bindingtemplates>... <bindingtemplate> <accesspoint urltype="http"> http://services-r-us.com/webcalc </accesspoint> <tmodelnstancedetails> Service endpoint <tmodelnstanceinfo tmodelkey="{webcalc key goes here}"/> <tmodelnstancedetails> </bindingtemplate> </bindingtemplates> </businessservice> Built-in tmodel reference
Example: Locating services You may want to find all the services which implement a specific WSDL service definition. A tmodel key may be passed on an invocation of the find_service operation. If several tmodels are listed, the services returned are those that reference all the tmodels in the list. <find_service generic="2.0" xmlns="urn:uddi-org:api_v2"> <tmodelbag><!-- list of tmodel keys goes here --></tmodelbag> </find_service> tmodel key list
Steps for storing WSDL refs (UDDI v2) The necessary steps are as follows: 1. Create a tmodel for the type Set the overviewurl to point to the WSDL document. Add a reference to the tmodel's categorybag with: tmodelkey="uuid:c1acf26d-9672-4404-9d70-39b756e62ab4" keyname="uddi-org:types" keyvalue="wsdlspec" 2.Reference the tmodel from any bindingtemplate that implements the interface described in the WSDL. Any service that is associated with this service type can be located by searching for references to the custom tmodel
Associating a service with WSDL (UDDI v3) The growing importance of WSDL has led to improvements in the way UDDI supports WSDL. An association can be made without creating a tmodel. <businessservice businesskey="a key value" servicekey=""> <name>calculatorservice</name> <description>...</description> <bindingtemplates> WSDL <bindingtemplate> reference <accesspoint usetype= wsdldeployment > http://webcalc.org/wsdl/calc.wsdl </accesspoint> <categorybag> <keyedreference keyname= uddi-org:types:wsdl keyvalue="wsdldeployment" tmodelkey="uddi:uddi.org:categorization:types /> </categorybag> </bindingtemplate> </bindingtemplates> </businessservice> Categorization to permit a search for a WSDL defined service Hierarchical key format introduced in UDDI v3
Retrieving the WSDL for a service For UDDI registries at version 1 or 2: Registered services implement an interface described in WSDL if they have a bindingtemplate referencing a tmodel: The tmodel references a tmodelkey uuid:c1acf26d-9672-4404- 9D70-39B756E62AB4 The keyvalue of the reference is the string wsdlspec The WSDL file location can be retrieved by accessing the URL contained in the overviewurl element of the tmodel. For UDDI registries at version 3: The registry can store the URL for a WSDL file as the value of the accesspoint in a bindingtemplate. Search for a value of "wsdldeployment" on the usetype attribute of the bindingtemplate and then retrieve the WSDL document referred to in the accesspoint element.
Status of UDDI Unlike SOAP and WSDL, UDDI is not as widely adopted by companies using Web services. Many companies are using alternatives to UDDI. WSIL: Method to inspect a Web site for Web services Private registries: Companies that use Web services internally, often use non-uddi registries for storing service descriptions Problems with UDDI have slowed its acceptance: Companies do not want to put information on public servers. UDDI data structures are difficult to understand and program. Web services implementations have been mainly for internal business processes and trusted business partners. Security issues are not easily addressed in UDDI V2.
UDDI version 3 UDDI V3.0.2 provides significant enhancements and support for: Multi-registry environments Digital signatures Subscription API Policies OASIS standard
Other resources (1 of 2) Related information UDDI specifications, forums, and so on SOAP Where you can get it http://www.uddi.org http://www.w3.org/2000/xp/group/ UDDI development tools UDDI4J - UDDI client toolkit for Java Microsoft UDDI SDK Location http://sourceforge.net/projects/uddi4j http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnanchor/html/anch_uddi.asp
Other resources (2 of 2) Public UDDI search sites IBM UDDI V2 Business Registry Search Microsoft UDDI Business Registry Node SAP UDDI Business Registry Location https://uddi.ibm.com/ubr/registry.html http://uddi.microsoft.com/ http://uddi.sap.com/
Checkpoint questions 1. Which of the following entities are parts of the UDDI data model? A. businessentity B. businessservice C. serviceimplementation D. bindingtemplate 2. Which of the following statements regarding UDDI are true? A. UDDI is a centralized server operated by IBM. B. UDDI is a Web service. C. UDDI is managed by OASIS. D. UDDI stores WSDL documents on its servers. 3. Name two uses of tmodels within UDDI. 4. What are the three taxonomy systems used to classify information inside UDDI?
Unit summary In this module, you have learned: The UDDI registry model data structure How to use UDDI to publish a Web service How to use UDDI to find a Web service The relationship between UDDI and WSDL
Publishing Web services to a UDDI registry
Unit objectives After completing this unit, you should be able to: Configure the Unit Test UDDI registry Publish Web services to the UDDI registry Find Web services in the UDDI registry Configure Web services in the UDDI registry Describe how to programmatically find and publish Web services using UDDI4J
UDDI and Rational Application Developer Included with Rational Application Developer are two powerful tools that simplify UDDI-related development Unit Test UDDI Registry Web Services Explorer Other UDDI Registry
Configuring the Unit Test Registry To configure the Unit Test UDDI Registry, invoke the Unit Test UDDI Wizard by choosing File->New->Other from the menu Then select Web Service -> Unit Test UDDI
Choosing the registry You may choose a Cloudscape or DB2-based backing-store for the registry.
Complete the creation of the registry You can automatically launch the Web Services Explorer if you wish. If you want to install the registry in an existing WebSphere V6 server, select it here.
Open the Web Services Explorer Invoke the Web Services Explorer at any time by clicking this icon on the tool bar in the Web perspective. Select the UDDI Main item and then enter the particulars for the registry. If you are connecting to the Unit Test Registry, change this value to: http://localhost:9080/uddisoap/inquiryapi.
A sample scenario The Unit Test Registry will be used to: 1. Register the business entity, Celsius Service Business, with the following categories: The NAICS category 514191 (On-Line Information Services) The UNSPSC category 80.16.15.07.00 (Audio visual services) Located in NO-03 (Oslo, Norway) 2. Create a service for this business called: Celsius Service
Start the publishing process Click the Publish icon
Register the business Publish a business Use simple format Enter the publishing API URL for the registry Enter authentication information (generally required for publishing operations) Commit the information
Business registration result Generated Business Key Add a Category Generated Discovery URL
Add a NAICS category 1. Click Add, then choose NAICS 2. Browse the category 3. Locate and select category 514191, On-Line Information Services
Add UNSPSC and Geographical categories 1. Click Add, then choose UNSPSC 7.3 or GEO 2. Browse the category 3. Locate and select the appropriate category
The resulting business entity Click this icon to publish a service associated with this business.
Locate the WSDL file for the service 1. Use simple format 2. Browse workspace for services. 3. Choose the correct project from Web projects available in the workspace. The URL is automatically selected. 4. Commit the selection. The Web Services Explorer is integrated with Rational Application Developer and can examine the projects in the workspace.
Complete the service detail Set the name and the description Commit the new service
The published service
Searching the UDDI registry Information is located by running queries in the Web Services Explorer With the registry node selected in the Navigator, click the Find icon
The registry search form The search form supports searches for: businessentities (businesses) businessservices (services) tmodels (service interfaces) To locate the service just published, use a name fragment and a wildcard. Invoke the search.
Query results The service you published has been located
UDDI4J UDDI4J is a client Java API used to interact with a UDDI registry. UDDIProxy is the primary class used to interact with a UDDI registry: Methods map very closely to the UDDI API specification Both the inquiry and publish URLs for the registry must be specified UDDIProxy proxy = new UDDIProxy(); proxy.setinquiryurl("http://localhost:9080/uddisoap/inquiryapi"); proxy.setpublishurl("http://localhost:9080//uddisoap/publishapi"); Messages to the registry are sent via method calls that map closely to the messages sent using the Web Services Explorer. BusinessList bl = proxy.find_business( Echo Services Inc.", null, 0);
Checkpoint questions 1. Which two tools can be used in UDDI? A. Web Services Explorer B. UDDI Explorer C. Unit Test UDDI Registry D. UDDI Test Client 2. Which of the following is not a built-in category? A. Geographic B. EMEA C. NAICS D. UNSPC 3. In UDDI4J, what is the primary class used to interact with the registry?
Unit summary In this module, you have learned: How to configure and run the Unit Test UDDI registry How to publish and find registry entries with the Web Services Explorer
Course summary
Unit objectives After completing this unit, you should be able to: Summarize the course Describe how to get additional help with Web services
Integration benefits of Web services Using XML as the common ground for communication, Web services provide a single solution for integration without creating the need to migrate legacy systems Web service standards coordinate the exchange of XML COBOL XML.NET C Intranet MQueue PL/1 CICS C++ J2EE
Business benefits of Web services Web services provide another way of doing business on the Internet By eliminating the hurdle of system integration, business partners can combine their systems in ways that haven't been cost effective in the past Product Catalog XML Business Communities Sales Internet Outsourcing Auction? Just-in-Time Inventory e-business Partnerships
The service-oriented architecture SOAP, WSDL, and UDDI provide the base on which this architecture operates Service Broker Reference or URL Service Description (WSDL) Find UDDI UDDI Publish Create description Service Requester SOAP Bind or interact Service Provider Service
Web services enable integration Business Community
SOAP resources (1 of 2) SOAP information SOAP 1.1 and 1.2 specifications SOAP 1.2 Primer Links to SOAP resources General information about Web services Where you can get it http://www.w3.org/2000/xp/group/ http://www.w3.org/tr/soap12-part0 http://www.xml.org/xml/resources_focus_soap.shtml http://www.ibm.com/developerworks/webservices/
SOAP resources (2 of 2) SOAP implementation Where you can get it Systinet WASP Server for Java http://www.systinet.com/products NonStop SOAP Apache Axis Microsoft Soap Toolkit http://nonstop.compaq.com/view.asp?io=soapexnw http://xml.apache.org/axis/ http://msdn.microsoft.com/webservices
WSDL resources Related information WSDL 1.1 and 1.2 specifications XML schema JSR 110 - JWSDL Where you can get it http://www.w3.org/2002/ws/desc/ http://www.w3.org/xml/schema http://www.jcp.org/jsr/detail/110.jsp WSDL generators Apache Axis Web site Microsoft.NET Framework Location http://xml.apache.org/axis/ http://msdn.microsoft.com/downloads
Web services for J2EE resources Resource WebSphere InfoCenter Web Services for J2EE information JAX-RPC specification Web services for J2EE specification Build interoperable Web services with JSR-109 General information about Web services Location http://www.ibm.com/software/webservers/appserv/infocenter.html Where you can get it http://java.sun.com/xml/downloads/jaxrpc.html http://jcp.org/aboutjava/communityprocess/final/jsr921/index.html http://www.ibm.com/developerworks/webservices/library/ws-jsrart/ http://www.ibm.com/developerworks/webservices/
UDDI resources (1 of 2) Related information UDDI specifications, forums, and so on Where you can get it http://www.uddi.org UDDI Development Tools UDDI4J - UDDI client toolkit for Java Microsoft UDDI SDK Location http://sourceforge.net/projects/uddi4j http://msdn.microsoft.com/library/default.asp?url=/library/enus/dnanchor/html/anch_uddi.asp
UDDI resources (2 of 2) Public UDDI search sites IBM UDDI v2 Business Registry Search Microsoft UDDI Business Registry Node SAP UDDI Business Registry Location https://uddi.ibm.com/ubr/registry.html http://uddi.microsoft.com/ http://uddi.sap.com/
Unit summary In this module, you have learned: A summary of the course Where to get additional help on Web services