EMTM 600 Software Development Spring 2007


Published on

  • Be the first to comment

  • Be the first to like this

EMTM 600 Software Development Spring 2007

  1. 1. EMTM 600 Software Development Spring 2007 Lecture Notes 5
  2. 2. Assignments for next time • Recall the Pet Store application shown in class, the two user stories that you outlined in a previous assignment and the interaction that the servlet needs to have with a session façade domain object for these user stories, which you outlined in another previous assignment. Outline informally two web service operations through which you may wish to expose the functionality of your session bean. Should these two operations be grouped as one web service or each one should support its own service? Justify your choices. 1 page. Groups of 3-4 students OK. • Read the article “SOA without Web Services…” by Duan et al., distributed in class. Based on your enterprise experience, describe a case for EAI in which you would choose a similar WS-less but SOA architecture to integrate several applications. Discuss pros and cons, and availability of technology. 1 page. Groups of 3-4 students OK. EMTM 600 2007 Val Tannen 2
  3. 3. Web Services A tool for application integration. Application integration is THE fundamental problem in information technology! Web Service = “A set of operations that are network accessible through standardized XML messaging” Web services need to be described, located and invoked. SOA (Service Oriented Architecture) is a collection of specifications for these three functionalities. The big players are: SOAP = Simple Object Access Protocol (pretty stupid name, no?), an XML messaging protocol WSDL = Web Services Description Language, a language for specifying the “types” of the operations offered by a Web service UDDI = Universal Description Discovery and Integration, a global registry EMTM 600 2007 Val Tannen 3
  4. 4. XML Messaging  XML Messaging means that XML documents are exchanged between applications  How could we define a concept of the end-to-end message path in a transport independent manner? Document Centric Messaging XML Programming XML Programming XML Document Programming API Application Document API Document API A new defined layer SOAP Messaging HTTP SMTP IIOP Transport EMTM 600 2007 Val Tannen 4
  5. 5. SOAP  SOAP provides a simple and lightweight mechanism for exchanging structured and typed information between nodes in a decentralized, distributed environment by using XML  The main use for SOAP is RPC (Remote Procedure Call) which originated in the 1970’s with efforts to expand the functionality of the ARPANet (later became the Internet).  Warning: SOAP does not itself define any application semantics such as a programming model or implementation specific semantics! EMTM 600 2007 Val Tannen 5
  6. 6. SOAP Features Platform independent Language independent It is transport agnostic but most used is its binding to HTTP It is defined by W3C at http://www.w3.org/TR/SOAP/ Extension for carrying attachments (like email) Used for RPC (Remote Procedure Call) but with XML arguments and XML result EMTM 600 2007 Val Tannen 6
  7. 7. SOAP Blocks  Envelope element (required) that identifies the XML document as a SOAP message  Header element (optional) that contains header information  Body element (required) that contains contains mandatory information for the message receiver  Fault element (optional) that provides information about errors that occurred while processing the message EMTM 600 2007 Val Tannen 7
  8. 8. Skeleton SOAP Message <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... ... Header </soap:Header> <soap:Body> Envelope ... ... <soap:Fault> ... Body ... Fault </soap:Fault> </soap:Body> </soap:Envelope> EMTM 600 2007 Val Tannen 8
  9. 9. SOAP HTTP Binding (*)  The client sends an HTTP request message to the server POST /item HTTP/1.1 Host: 189.123.345.239 Content-Type: text/plain Content-Length: 100  The server then processes the request and sends an HTTP response back to the client 200 OK Content-Type: text/plain Content-Length: 100  A SOAP request could be an HTTP POST or an HTTP GET request.  The HTTP POST request specifies at least two HTTP headers: Content-Type and Content-Length POST /item HTTP/1.1 Content-Type: application/soap+xml; charset=utf-8 Content-Length: 250 EMTM 600 2007 Val Tannen 9
  10. 10. Sample Encoding of Call Requests (*) POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "Some-URI" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI"SOAP-ENV:mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>SUNW</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope> EMTM 600 2007 Val Tannen 10
  11. 11. Sample Encoding of Response (*) HTTP/1.1 200 OK Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/> <SOAP-ENV:Header> <t:Transaction xmlns:t="some-URI" xsi:type="xsd:int" mustUnderstand="1"> 5 </t:Transaction> </SOAP-ENV:Header> <SOAP-ENV:Body> <m:GetLastTradePriceResponse xmlns:m="Some-URI"> <Price>3.5</Price> </m:GetLastTradePriceResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> EMTM 600 2007 Val Tannen 11
  12. 12. Sample Server Error Response (*) HTTP/1.1 500 Internal Server Error Content-Type: text/xml; charset="utf-8" Content-Length: nnnn <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>SOAP-ENV:Server</faultcode> <faultstring>Server Error</faultstring> <detail> <e:myfaultdetails xmlns:e="Some-URI"> <message> Application didn't work </message> <errorcode> 1001 </errorcode> </e:myfaultdetails> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> </SOAP-ENV:Envelope> EMTM 600 2007 Val Tannen 12
  13. 13. WSDL WSDL stands for Web Services Description Language WSDL is written in XML (it’s an XML document) WSDL is used to describe Web services WSDL is also used to locate Web services EMTM 600 2007 Val Tannen 13
  14. 14. WSDL Description WSDL defines an XML grammar for describing network services as collections of communication endpoints capable of exchanging messages A WSDL document defines services as collections of network endpoints, or ports Messages are abstract descriptions of the data being exchanged Port types are abstract collections of operations The concrete protocol and data format specifications for a particular port type constitutes a reusable binding A port is defined by associating a network address with a reusable binding. A collection of ports define a service EMTM 600 2007 Val Tannen 14
  15. 15. WSDL Architecture  WSDL is a layered approach to defining a service interface Abstract – logical view of the service Messages: representing data flows to and from the service Port Type: representing a set of operations supported by one or more endpoints Concrete – physical view of the service Binding: defines the specific network protocol and data format used for a given port type Port: defines a single endpoint for a given binding EMTM 600 2007 Val Tannen 15
  16. 16. WSDL – Logical – Physical 1 7 2 6 3 4 5 EMTM 600 2007 Val Tannen 16
  17. 17. Structure of WSDL document <definitions> <types> definition of types........ </types> <message> definition of a message.... </message> <portType> definition of a port....... </portType> <binding> definition of a binding.... </binding> </definitions> EMTM 600 2007 Val Tannen 17
  18. 18. 1 <types> Element EMTM 600 2007 Val Tannen 18
  19. 19. 2 <message> Element EMTM 600 2007 Val Tannen 19
  20. 20. 3 <operation> Element EMTM 600 2007 Val Tannen 20
  21. 21. WSDL Operation patterns <input> One-way Client Service A 1 <input> Request-Response Client Service B <output> 2 1 <output> Solicit-Response Client Service C <input> 2 <output> D Notification Client Service EMTM 600 2007 Val Tannen 21
  22. 22. One-Way Operation (*) A <message name="newGradeValues"> <part name="grade" type="xs:string"/> <part name="value" type="xs:float"/> </message> <portType name="gradeCourse"> <operation name="setGrade"> <input name="student" message="newGradeValues"/> </operation> </portType >  The port "gradeCourse" defines a one-way operation called "setGrade“  The "setGrade" operation allows input of new grade values messages using a "newGradeValues" message with the input parameters "grade" and "value "  No output is defined for the operation EMTM 600 2007 Val Tannen 22
  23. 23. Request-Response Operation (*) B <message name="getGradeRequest"> <part name="grade" type="xs:string"/> </message> <message name="getGradeResponse"> <part name="value" type="xs:float"/> </message> <portType name="courseGrades"> <operation name="getGrade"> <input message="getGradeRequest"/> <output message="getGradeResponse"/> </operation> </portType>  The port "courseGrades" defines a request-response operation called "getGrade“  The "getGrade" operation requires an input message called "getGradeRequest“ with a parameter called "grade", and will return an output message called "getGradeResponse" with a parameter called "value" EMTM 600 2007 Val Tannen 23
  24. 24. C Solicit-response Operation (*) <wsdl:definitions .... > <wsdl:portType .... > * <wsdl:operation name="nmtoken" parameterOrder="nmtokens"> <wsdl:output name="nmtoken"? message="qname"/> <wsdl:input name="nmtoken"? message="qname"/> <wsdl:fault name="nmtoken" message="qname"/>* </wsdl:operation> </wsdl:portType > </wsdl:definitions>  A solicit-response operation is an abstract notion; a particular binding must be consulted to determine how the messages are actually sent  The output and input elements specify the abstract message format for the solicited request and response EMTM 600 2007 Val Tannen 24
  25. 25. D Notification Operation (*) <message name=“TradePriceChange"> <part name="grade" type="xsd1:TradePrice"/> </message> <portType name=“NotifyMe"> <operation name=“NotifyTradePriceChange"> <output message=“tns: TradePriceChange "/> </operation> </portType > The port “NotifyMe" defines a notification operation called “NotifyTradePriceChange“ The " NotifyTradePriceChange " operation allows output message “TradePrice Change” EMTM 600 2007 Val Tannen 25
  26. 26. 4 <portType> Element EMTM 600 2007 Val Tannen 26
  27. 27. WSDL Bindings WSDL bindings defines the message format and protocol details for a web service The binding element provides specific details on how a portType operation will actually be transmitted over the wire The binding element has two attributes: The name attribute which defines the name of the binding The type attribute The type attribute points to the port for the binding EMTM 600 2007 Val Tannen 27
  28. 28. soap:binding Element (*)  The soap:binding element has two attributes  the style attribute  the transport attribute  The style attribute can have the values  "rpc"  "document"  The transport attribute defines the SOAP protocol to use  http://schemas.xmlsoap.org/soap/http indicates the SOAP HTTP transport  http://schemas.xmlsoap.org/soap/smtp indicates the SOAP SMTP transport EMTM 600 2007 Val Tannen 28
  29. 29. 5 <binding> Element EMTM 600 2007 Val Tannen 29
  30. 30. soap:operation Element (*)  This element indicates the binding of a specific operation to a specific SOAP implementation  The soapAction attribute specifies that the soapAction HTTP header should be used for identifying the service <operation> <soap:operation soapAction="http://WSA500/getGrade"/> <input> <soap:body use="literal"/> </input> ... </operation>  soap:body element enables to specify the details of the input and output messages EMTM 600 2007 Val Tannen 30
  31. 31. Binding to SOAP Example (*) <message name="getGradeRequest"> <part name="grad" type="xs:string"/> </message> <message name="getGradeResponse"> <part name="value" type="xs:float"/> </message> <portType name="courseGrades"> <operation name="getGrade"> <input message="getGradeRequest"/> <output message="getGradeResponse"/> </operation> </portType> <binding type="courseGrades" name="b1"> <soap:binding style="document” transport="http://schemas……" /> <operation> <soap:operation soapAction="http://EMTM600/getGrade"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding> EMTM 600 2007 Val Tannen 31
  32. 32. 6 <port> Element EMTM 600 2007 Val Tannen 32
  33. 33. 7 <service> Element EMTM 600 2007 Val Tannen 33
  34. 34. Services A service groups a set of related ports together The name attribute provides a unique name among all services defined within in the enclosing WSDL document None of the ports communicate with each other <wsdl:definitions .... > <wsdl:service name="nmtoken"> * <wsdl:port .... />* </wsdl:service> </wsdl:definitions> EMTM 600 2007 Val Tannen 34
  35. 35. Complete WSDL Document EMTM 600 2007 Val Tannen 35
  36. 36. WSDL Example File – part 1 (*) EMTM 600 2007 Val Tannen 36
  37. 37. WSDL Example File – part 2 (*) EMTM 600 2007 Val Tannen 37
  38. 38. WSDL Example File – part 3 (*) EMTM 600 2007 Val Tannen 38
  39. 39. Best Practices EMTM 600 2007 Val Tannen 39
  40. 40. UDDI  Universal Description, Discovery, and Integration A project to speed interoperability and adoption for web services Standards-based specifications for service description and discovery Shared operation of a Business Registry on the web Partnership among industry and business leaders EMTM 600 2007 Val Tannen 40
  41. 41. UDDI Implementation Manufacturers UDDI Business Registry Programmatic descriptions of web services Programmatic descriptions of businesses and the services they support Flower Shops Programming model, schema, and platform agnostic Uses XML, HTTP, and SOAP Free on the Internet Marketplaces EMTM 600 2007 Val Tannen 41
  42. 42. Service-Oriented Architecture (SOA) 1.0 Web services need to be described, located and invoked. SOA (Service Oriented Architecture) is a collection of specifications for these three functionalities. UDDI Business Registries Service IBM, Microsoft, HP, SAP, etc Registry UDDI Publish Find UDDI WSDL Service Service “contract” Service Bind/Invoke Service “contract” Provider Requester WSDL SOAP EMTM 600 2007 Val Tannen 42
  43. 43. Future Vision: just compose Web services! Service Registry Publish3 Publish1 Find 1,2,3 Service Requester Bind1/ Bind3/ Invoke1 Compose Invoke3 BPEL Bind2/ Service Service Provider3 Invoke2 Service Provider1 Provider2 Business Process Publish2 Execution Language EMTM 600 2007 Val Tannen 43
  44. 44. BPEL  Business Process Execution Language  A language for “orchestrating” the composition of web services  XML-based syntax  BPEL 1.0 was developed jointly by IBM, BEA, SAP, Siebel, and Microsoft  Currently being standardized by OASIS (org “rival” to W3C!) as WS BPEL 2.0  Practically a full-fledged programming language  Control constructs for testing conditions and repetition, etc  Variables in which values can be copied and then retrieved  Basic statements are invocations of existing web services  Bindings to WSDL and SOAP/HTTP have been specified  Needs an execution engine! EMTM 600 2007 Val Tannen 44
  45. 45. BPEL, cont’d  Developing BPEL “programs” is very much like specifying workflows  But writing directly in the XML-based syntax is horrendous  Development tools with visual interfaces: create boxes corresponding to the control structures and the variables, drag and drop service icons to build the composition  Great for SMALL tasks  It’s dangerous to write a BPEL script as complicated as a program in, say, Java (you can, but you shouldn’t!). EMTM 600 2007 Val Tannen 45
  46. 46. The WS Future Vision vs. Today’s Reality JBI (Java Bus. Integr.) • The standards landscape is still confusing, a message-passing plug-in architecture and sometimes confused. based on BPEL • Hope: WS-I (Web Services Interoperability Organization) (http://www.ws-i.org) for guidance, best practices and resources • Today most companies use web services for simple, tactical integration projects (see next) • Developers still grappling with SOA design principles • Human-based discovery working just fine for the moment; local registries are very useful in EAI (Enterprise Application Integration) EMTM 600 2007 Val Tannen 46
  47. 47. Using Web services in Enterprise Application Integration •It’s here now •Pros: •XML is a flexible data exchange format that can deal with complex data types better than CORBA-IDL. •Web services separate not only interfaces from implementations (so does CORBA) but also from the transport protocol. That’s because XML transport is easily supported by all protocols. •All this motivated Microsoft to put out .NET! •The response of the Java world has been interoperability standards between the Java technologies and the Web services standards: •JAXP (Java API for XML Processing •JAX-WS (Java API for XML Web Services) (formerly JAX-RPC) •SAAJ (SOAP with Attachments API for Java) •Con: XML processing (and HTTP transport) is SLOW! EMTM 600 2007 Val Tannen 47
  48. 48. Web Services in the J2EE Architecture The Java-Web Services specs (JAX-RPC for J2EE and JAX-WS for Java (5) EE) say that any Java Bean can be adapted to implement a Web service. Best practice: do it with session EJB! Reason: security! presentation controller domain data mapping data source HTML Servlets App. Server- specific Java Session Entity JSP Beans EJBs EJBs bad security SOAP/ JDBC WSDL Web Server- specific EMTM 600 2007 Val Tannen 48
  49. 49. Adapting a Session EJB to become a Web Service 1. Adapt the session EJB’s remote interface to a JAX-RPC/JAX-WS compliant SEI (Service Endpoint Interface) 2. Compile the SEI to a WSDL file (automated with the Apache open source tool Java2WSDL) 3. Compile the WSDL file into deployment information (automated with tool: WSDL2Java) which is vendor-specific; better standardized in JAX-WS. 4. Make the Web service deployment information compatible with the EJB deployment information (vendor-specific) 5. Add a SOAP HTTP request handler (automated with tool: endptEnabler, appears to be also vendor-specific, but it’s better standardized in JAX-WS) 6. Deploy the Java EE application; it now includes a Web service EMTM 600 2007 Val Tannen 49
  50. 50. From the SEI to a WSDL document with Java2WSDL • One session EJB -> one SEI (normally) • Several SEIs, processed together by Java2WSDL-> one service. • Each SEI -> just one port (endpoint) in the service. • The name of the SEI becomes the name of the port. • The name of the SEI concatenated with “Service” becomes the name of the service. • Each method in the SEI becomes an operation of the unique port. • The name of the method becomes the name of the operation. • The name of the method concatenated with “Request” and “Response” become the names of the input and output messages of the operation. EMTM 600 2007 Val Tannen 50
  51. 51. Request-Response Operation (*) public interface StockQuotes extends java.rmi.Remote { public float getAvgPrice(String symbol, int noDays); } <message name="getAvgPriceRequest"> <part name="getAvgPriceArg1" type="xs:string"/> <part name="getAvgPriceArg2" type="xs:int"/> Java2WSDL </message> <message name="getAvgPriceResponse"> <part name="getAvgPriceReturn" type="xs:float"/> </message> <portType name=”StockQuotes"> <operation name="getAvgPrice"> <input message="getAvgPriceRequest"/> <output message="getAvgPriceResponse"/> </operation> </portType> EMTM 600 2007 Val Tannen 51
  52. 52. More complex architectural ideas • The session EJB transformed into a web service that we just saw is an instance of the Web Service Broker pattern (textbook p.557), combined with the Session Façade pattern (textboook p.341). • However, we often have multiple application services we want to organize and expose as coarse-grain web services. Then we use Web Service Broker in conjunction with Application Service (textbook p.357) and possibly with Service Locator (textbook p.315). EMTM 600 2007 Val Tannen 52
  53. 53. More complex architectural ideas, cont’d • The web server can be bypassed: no need for a proxy in the web server, the web service requests can be sent directly to the EJB container. • In EJB 2.0 they would first have to be adapted to JMS and a message-driven bean would receive them. The MDB follows the pattern Service Activator (textbook p. 496). • However, the EJB 3.0 container supports Web services directly. Just annotate an EJB with @WebService(, its methods with @WebMethod and their arguments with @WebParam. • JAX-WS specifies how to obtain a WSDL file from that, no need for a separate SEI. • In EJB 3.0, the Service Activator components come with the implementation! EMTM 600 2007 Val Tannen 53
  54. 54. Best practices for using WS with Java EE • A Java EE application can be a WS endpoint server but it can also be a client to other Web services! If those are also implemented in Java we can use the same Java <-> WSDL tools in both apps! • Do not use Web services between the logical layers of a Java EE application. Reasons: • Serialization/deserialization overhead • XML parsing overhead • No good transaction support (yet) • No good security support (yet, but see OASIS WSS later) • In general, avoid fine-grain use of Web services, for the same reasons. EMTM 600 2007 Val Tannen 54
  55. 55. More best practices for WS / Java EE • Use Web services for widely distributed fat clients; SOAP over HTTP will work in places where RMI over IIOP won’t, such as integration with .NET apps. • Web services do provide an alternative to using MOM (Message Oriented Middleware). Implementing asynchronous Web services follows the same patterns used for MOMs and messaging-based enterprise application integration (EAI). • We can combine Java EE advantages with asynchronous services using Message-Driven Beans (and therefore JMS). This is sometimes called SOAP over JMS but it’s really SOAP over whatever protocol JMS is built on, with JMS as an adapter. EMTM 600 2007 Val Tannen 55
  56. 56. Efficiency and scalability  XML parsing is slow  HTTP is slower than other protocols, eg., IIOP  We have a tradeoff between Tight coupling = fast but lacks flexibility Loose coupling = slow but flexible  Is the flexibility of SOA possible without the slowdown of XML and HTTP? Perhaps! See article “SOA without Web Services…”, distributed in class EMTM 600 2007 Val Tannen 56
  57. 57. Web Services and Security • SOAP has in essence the same security issues as CORBA, RMI, or MOM. (DCOM is even less secure because of the COM registry): clear need for authentication and authorization. • But SOAP is so simple that it is used without thinking that: • SOAP services are accessible through HTTP on port 80; • Firewalls don't block communications on port 80! • It’s not enough to use SSL (https instead of http), it doesn’t do authentication and authorization! • In contrast, CORBA, MOM, and Java EE programmers include security as a basic concern routinely and have tools that simplify their job • To secure SOAP and therefore web services, the security must be implemented by the application, not by the transport protocol. EMTM 600 2007 Val Tannen 57
  58. 58. Web Services and Security, cont’d • Standards for secure SOAP took a long time to be formulated but now we have: (WSS) Web Services Security 1.1 a.k.a WS-Security 1.1 from OASIS (http//:www.oasis-open.org) • Based on security tokens inserted in the SOAP messages and on digital signatures. “Security tokens assert claims and can be used to assert the binding between authentication secrets or keys and security identities. An authority can vouch for or endorse the claims in a security token by using its key to sign or encrypt (it is recommended to use a keyed encryption) the security token thereby enabling the authentication of the claims in the token. An X.509 certificate, claiming the binding between one’s identity and a public key, is an example of a signed security token endorsed by the certificate authority. “ EMTM 600 2007 Val Tannen 58
  59. 59. More on Web Services and Security • OASIS WSS is a very flexible mechanism; the idea of security token will be probably adopted in the future by other security specification, such as the Java Security API. • Through the Java Web Services Developers Pack 1.6, we can now use in Java EE an implementation of OASIS WSS called XWS- Security which can be used in conjunction with JAX-WS. • OASIS WSS 1.1 is now also implemented by .NET EMTM 600 2007 Val Tannen 59
  60. 60. UDDI Vision and Process 1. Start with existing standards • TCP/IP, HTTP, XML • Industry-specific schemas • Shared vision of open protocols 2. Augment and implement via a Web Service • Common web services “stack” • Shared implementation to avoid confusing customers • Public specs, open service, inclusive process 3. Transition to a Standards Body • Manage design process for 3 revs • License control and IP to a 3rd party EMTM 600 2007 Val Tannen 60
  61. 61. UDDI Terminology  accessPoint  An entry point address for accessing a web service. This could be a URL, email address (?), or phone number (??).  businessKey  A unique identifier for a given business entity.  category  Category information that is similar to an identifier but that uses a predefined taxonomy, such as industry, product, or geographic codes. It also uses name/value pairs. Examples of these codes include: NAICS ( North American Industry Classification System), UNSPSC 3.1 (United Nations Standard Products and Services Code System) SIC (Standard Industrial Classification) codes. EMTM 600 2007 Val Tannen 61
  62. 62. UDDI Terminology, cont’d  identifier  A name/value pair that acts as an identifier for a business. Examples include the D-U-N-S (Dun & Bradstreet's Data Universal Numbering System) ID and Thomas Register ID.  keyName  Commentary that aids in readability but usually isn't required. For example, the D-U-N-S identifier for IBM has a keyName of D-U-N-S, whereas the keyValue is the actual nine-digit D-U-N-S number, 00-136- 8083. However, the keyName does have important meaning in the uddi-org:misc-taxonomy category.  keyValue  Specifies a business classification, such as the nine-digit D-U-N-S number used for businesses worldwide. EMTM 600 2007 Val Tannen 62
  63. 63. UDDI Terminology, cont’d  operator site  Each instance of a UDDI business registry. For example, Microsoft and IBM maintain instances of the UDDI Business Registry (also SAP and HP, and maybe others…)  overview document URL  A pointer to the location of the overview document description.  serviceKey  A unique key for a business service that is generated when the service is registered.  tModel  A reference to a technical specification of a service. TModels are descriptions of web services that define service types. Each TModel has a unique identifier and points to a specification that describes the web service. tModels provide a common point of reference that allow compatible services to be easily identified. EMTM 600 2007 Val Tannen 63
  64. 64. Searching a UDDI registry  There are several ways to search for web services in a UDDI registry  Search for businesses  Search for services  Search for tModels  Searching for businesses  Search by business name  Search by business category  Search by business identifier  Search by tModel EMTM 600 2007 Val Tannen 64
  65. 65. Searching for tModels EMTM 600 2007 Val Tannen 65
  66. 66. How UDDI v1 Works 4. 1. SW companies, standards bodies, and programmers populate the registry with descriptions of different types of services Marketplaces, search engines, and business apps query the registry to 2. discover services at other companies UDDI Business Registry Business Segrvice Type 5. Businesses Registrations Reistrations populate the registry 3. UBR assigns a programmatically unique with Business uses this identifier to each service and business descriptions of data to facilitate registration the services easier integration they support with each other over the Web EMTM 600 2007 Val Tannen 66
  67. 67. Registry Data White Pages Yellow  Businesses register public information Pages about themselves Green Pages  Standards bodies, Programmers, Businesses register information about Service Type their Service Types Registrations EMTM 600 2007 Val Tannen 67
  68. 68. White Pages  Business Name  Text Description  list of multi-language text strings  Contact info  names, phone numbers, fax numbers, web sites…  Known Identifiers  list of identifiers that a business may be known by - DUNS, Thomas, other EMTM 600 2007 Val Tannen 68
  69. 69. Yellow Pages Business categories 3 standard taxonomies in V1 Industry: NAICS (Industry codes - US Govt.) Product/Services: UN/SPSC (ECMA) Location: Geographical taxonomy Implemented as name-value pairs to allow any valid taxonomy identifier to be attached to the business white page EMTM 600 2007 Val Tannen 69
  70. 70. Green Pages  New set of information businesses use to describe how to “do e- commerce” with them  Nested model Business processes Service descriptions Binding information  Programming/platform/implementation agnostic  Services can also be categorized EMTM 600 2007 Val Tannen 70
  71. 71. Service Type Registration  Pointer to the namespace where service type is described What programmers read to understand how to use the service  Identifier for who published the service  Identifier for the service type registration called a tModelKey Used as a signature by web sites that implement those services EMTM 600 2007 Val Tannen 71
  72. 72. Business Registration Contact Contact Phone businessEntity Phone Address Address businessKey Email Email  XML document name  Created by end-user company URL description (or on their behalf) businessService businessService contacts serviceKey  Can have multiple service Key businessServices tModelKey Name listings identifierBag Name Description  Can have multiple taxonomy categoryBag Description BindingTemplates BindingTemplates listings keyedReference keyedReference tModelKey tModelKey keyedReference keyName keyedReference keyName tModelKey keyValue tModelKey keyValue keyName keyName keyValue keyValue EMTM 600 2007 Val Tannen 72
  73. 73. UDDI Elements EMTM 600 2007 Val Tannen 73
  74. 74. businessEntity Structure (XML Schema) <element name="businessEntity" type="uddi:businessEntity" /> <complexType name="businessEntity"> <sequence> <element ref="uddi:discoveryURLs" minOccurs="0" /> <element ref="uddi:name" maxOccurs="unbounded" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" / <element ref="uddi:contacts" minOccurs="0" /> <element ref="uddi:businessServices" minOccurs="0" /> <element ref="uddi:identifierBag" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="businessKey" type="uddi:businessKey" use="required" / <attribute name="operator" type="string" use="optional" /> <attribute name="authorizedName" type="string" use="optional" /> </complexType> EMTM 600 2007 Val Tannen 74
  75. 75. businessService Structure (XML Schema) <element name="businessService" type="uddi:businessService" /> <complexType name="businessService"> <sequence> <element ref="uddi:name" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:description" minOccurs="0“ maxOccurs="unbounded" /> <element ref="uddi:bindingTemplates" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="serviceKey" type="uddi:serviceKey" use="required" /> <attribute name="businessKey" type="uddi:businessKey" use="optional" /> </complexType> EMTM 600 2007 Val Tannen 75
  76. 76. bindingTemplate Structure (XML Schema) <element name="bindingTemplate" type="uddi:bindingTemplate" /> <complexType name="bindingTemplate"> <sequence> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <choice> <element ref="uddi:accessPoint" /> <element ref="uddi:hostingRedirector" /> </choice> <element ref="uddi:tModelInstanceDetails" /> </sequence> <attribute name="serviceKey" type="uddi:serviceKey" use="optional" /> <attribute name="bindingKey" type="uddi:bindingKey" use="required" /> </complexType> EMTM 600 2007 Val Tannen 76
  77. 77. tModel Structure (XML Schema) <element name="tModel" type="uddi:tModel" /> <complexType name="tModel"> <sequence> <element ref="uddi:name" /> <element ref="uddi:description" minOccurs="0" maxOccurs="unbounded" /> <element ref="uddi:overviewDoc" minOccurs="0" /> <element ref="uddi:identifierBag" minOccurs="0" /> <element ref="uddi:categoryBag" minOccurs="0" /> </sequence> <attribute name="tModelKey" type="uddi:tModelKey" use="required" /> <attribute name="operator" type="string" use="optional" /> <attribute name="authorizedName" type="string" use="optional" /> </complexType> EMTM 600 2007 Val Tannen 77
  78. 78. Example of a Registration Peter Smythe businessEntity 872-6891 TB993… 4281 King’s Blvd, Sydney, NSW Harbour Metals Peter@harbourmetals.co.au www.harbourmetals.co.au “Serving Inner Sydney Harbour for … businessService businessService contacts 23T701e54683nf… Key businessServices Name catalog Online identifierBag Descriptionwhere you can … “Website categoryBag BindingTemplates BindingTemplates BindingTemplate keyedReference 5E2D412E5-44EE-… EE123… keyedReference http://www.sydneynet/harbour… tModelInstanceDetails NAICS DFE-2B… 02417 DUNS tModelInstanceInfo 45231 4453D6FC-223C-3ED0… http://www.rosetta.net/catalogPIP tModelKeys EMTM 600 2007 Val Tannen 78
  79. 79. UDDI at Work …who registers 1. SydneyNet.com Harbour Metals with UBR (local provider) Harbour Metals creates UDDI Business Registry online website with 2. local provider… 4. Consumers and 3. businesses discover Harbour Metals and do Marketplaces and search engines business with it query UBR, cache Harbour Metals data, and bind to its services EMTM 600 2007 Val Tannen 79
  80. 80. Registry Operation  Peer nodes (websites) queries  Companies register IBM with any node  Registrations replicated on a daily basis  Complete set of “registered” records available at all nodes  Common set of Ariba SOAP APIs supported other UDDI.org by all nodes  Compliance enforced by business contract other Microsoft EMTM 600 2007 Val Tannen 80
  81. 81. UDDI and SOAP UDDI Registry User Node UDDI SOAP Request HTTP SOAP Server Processor UDDI SOAP Response UDDI Registry Service Create, View, B2B Directory Update, and Delete registrations Implementation- neutral EMTM 600 2007 Val Tannen 81
  82. 82. Registry APIs (SOAP Messages)  Publishers API Save things save_business  Inquiry API save_service  Find things  find_business save_binding  find_service save_tModel  find_binding  find_tModel Delete things delete_business  Get Details about things  get_businessDetail delete_service  get_serviceDetail delete_binding  get_bindingDetail  get_tModelDetail delete_tModel security… get_authToken discard_authToken EMTM 600 2007 Val Tannen 82
  83. 83. UDDI - WSDL  Assuming that we place the WSDL service interface definition at http://example.com/stockquote.wsdl  The corresponding tModel should have an overview element as follows <overviewURL> http://example.com/stockquote.wsdl </overviewURL> EMTM 600 2007 Val Tannen 83
  84. 84. tModel Element <tModel authorizedName="..." operator="..." tModelKey="..."> <name>StockQuote Service</name> <description xml:lang="en"> WSDL description of a standard stock quote service interface </description> <overviewDoc> <description xml:lang="en">WSDL source document.</description> <overviewURL> http://example.com/stockquote.wsdl </overviewURL> </overviewDoc> <categoryBag> <keyedReference tModelKey=" uuid:C1ACF26D-9672-4404-9D70-39B756E62AB4" keyName="uddi-org:types" keyValue="wsdlSpec"/> </categoryBag> </tModel> EMTM 600 2007 Val Tannen 84
  85. 85. businessService Element <businessService businessKey="..." serviceKey="..."> <name>StockQuoteService</name> <description> (...) </description> <bindingTemplates> <bindingTemplate> (...) <accessPoint urlType="http"> http://example.com/stockquote </accessPoint> <tModelnstanceDetails> <tModelnstanceInfo tModelKey="..."> </tModelnstanceInfo> <tModelnstanceDetails> </bindingTemplate> </bindingTemplates> </businessService> EMTM 600 2007 Val Tannen 85