EMTM 600 Software Development Spring 2007

EMTM 600Software Development

Spring 2007

Lecture Notes 5

EMTM 600 2007 Val Tannen 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.


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


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?

XML

DocumentProgramming

API

Document Centric Messaging

XML

DocumentXML

Document

Programming

APIProgramming

API

SOAPSOAP

Application

Messaging

TransportHTTP SMTP IIOP

A new defined layer


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!


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

http://www.w3.org/TR/SOAP/


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


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>

...

...

</soap:Header>

<soap:Body>

...

...

<soap:Fault>

...

...

</soap:Fault>

</soap:Body>

</soap:Envelope>

Header

FaultBody

Envelope


SOAP HTTP Binding (*) The client sends an HTTP request message to the server

The server then processes the request and sends an HTTP response back to the client

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

Host: 189.123.345.239

Content-Type: text/plain

Content-Length: 100

200 OK

Content-Type: text/plain

Content-Length: 100

POST /item HTTP/1.1

Content-Type: application/soap+xml; charset=utf-8

Content-Length: 250


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>


Sample Encoding of Response (*)HTTP/1.1 200 OK



<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>



Sample Server Error Response (*)HTTP/1.1 500 Internal Server Error



<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>



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


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


WSDL Architecture

WSDL is a layered approach to defining a service interface

Abstract – logical view of the serviceMessages: representing data flows to and from the

servicePort Type: representing a set of operations supported by

one or more endpoints

Concrete – physical view of the serviceBinding: defines the specific network protocol and data

format used for a given port typePort: defines a single endpoint for a given binding


WSDL – Logical – Physical

1

2

3

4 5

6

7


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>


<types> Element1


<message> Element2


<operation> Element3


WSDL Operation patterns

ClientClient ServiceService<input>

One-way

ClientClient ServiceService

<output>

<input>1

2

Request-Response

ClientClient ServiceService

<output>

<input>

1

2

Solicit-Response

ServiceServiceClientClient<output>

Notification

A

B

C

D


One-Way Operation (*)

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

<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 >

A


Request-Response Operation (*)

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"

<message name="getGradeRequest">

<part name="grade" type="xs:string"/>

</message>

<message name="getGradeResponse">


</message>

<portType name="courseGrades">

<operation name="getGrade">

<input message="getGradeRequest"/>

<output message="getGradeResponse"/>

</operation>

</portType>

B


Solicit-response Operation (*)

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

<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>

C


Notification Operation (*)

The port “NotifyMe" defines a notification operation called “NotifyTradePriceChange“

The " NotifyTradePriceChange " operation allows output message “TradePrice Change”

<message name=“TradePriceChange">

<part name="grade" type="xsd1:TradePrice"/>

</message>

<portType name=“NotifyMe">

<operation name=“NotifyTradePriceChange">

<output message=“tns: TradePriceChange "/>

</operation>

</portType >

D


<portType> Element4


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 attributeThe type attribute points to the port for the binding


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


<binding> Element5


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

soap:body element enables to specify the details of the input and output messages

<operation>

<soap:operation soapAction="http://WSA500/getGrade"/>

<input> <soap:body use="literal"/> </input>

...

</operation>


Binding to SOAP Example (*)

<message name="getGradeRequest">

<part name="grad" type="xs:string"/>

</message>

<message name="getGradeResponse">


</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>


<port> Element6


<service> Element7


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>


Complete WSDL Document


WSDL Example File – part 1 (*)


Best Practices


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


UDDI Implementation

UDDI Business RegistryProgrammatic descriptions of web servicesProgrammatic descriptions of businesses and the services they support Programming model, schema, and platform agnosticUses XML, HTTP, and SOAPFree on the Internet

Manufacturers

Flower Shops

Marketplaces


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.

ServiceRegistry

ServiceProvider

ServiceRequester

FindPublish

UDDI Business RegistriesIBM, Microsoft, HP, SAP, etc

WSDL

SOAP

UDDI

UDDI

Service “contract” Bind/Invoke

WSDL

Service “contract”


Future Vision: just compose Web services!

ServiceRegistry

ServiceProvider1

ServiceRequester

Find 1,2,3Publish1

Bind1/Invoke1

ServiceProvider2

ServiceProvider3

Bind2/Invoke2

Bind3/Invoke3Compose

Publish2

Publish3

BPEL

Business ProcessExecution Language


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!


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!).


The WS Future Vision vs. Today’s Reality

• The standards landscape is still confusing,

and sometimes confused.

• 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)

JBI (Java Bus. Integr.)a message-passing plug-in architecture

based on BPEL


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!


Web Services in the J2EE ArchitectureThe 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!

HTML

JSP

Servlets

JDBC

Session EJBs

EntityEJBs

presentation controller domain data mapping data source

App. Server-specific

SOAP/WSDL

JavaBeans

Web Server-specific

bad security


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


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.


Request-Response Operation (*)

<message name="getAvgPriceRequest">

<part name="getAvgPriceArg1" type="xs:string"/>

<part name="getAvgPriceArg2" type="xs:int"/>

</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>

public interface StockQuotes extends java.rmi.Remote {

public float getAvgPrice(String symbol, int noDays);

}

Java2WSDL


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).


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!


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.


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.


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


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.


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. “


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


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


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.


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.


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.


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


Searching for tModels


How UDDI v1 Works

UDDI Business Registry

3. UBR assigns a programmatically unique identifier to each service and business registration

Marketplaces, search engines, and business apps query the registry to discover services at other companies

4.

Segrvice TypeReistrations

SW companies, standards bodies, and programmers populate the registry withdescriptions of different types of services

1.

BusinessRegistrationsBusinesses

populate the registry withdescriptions of the services they support

2.

Business uses this data to facilitate easier integration with each other over the Web

5.


Registry Data

Businesses register public informationabout themselves

Standards bodies, Programmers, Businesses register information about their Service Types

WhitePages

YellowPages

GreenPages

Service TypeRegistrations


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


Yellow Pages

Business categories

3 standard taxonomies in V1Industry: 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


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


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


businessEntitybusinessKeynameURLdescriptioncontactsbusinessServicesidentifierBagcategoryBag

PhoneAddressEmail

Contact

businessServiceKeyNameDescriptionBindingTemplates

PhoneAddressEmail

Contact

businessServiceserviceKeytModelKeyNameDescriptionBindingTemplates

keyedReferencetModelKeykeyNamekeyValue




Business Registration

XML document Created by end-user

company (or on their behalf)

Can have multiple service listings

Can have multiple taxonomy listings


UDDI Elements


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>


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" />


</sequence>

<attribute name="serviceKey" type="uddi:serviceKey"

use="required" />

<attribute name="businessKey" type="uddi:businessKey"

use="optional" />

</complexType>


bindingTemplate Structure (XML Schema)

<element name="bindingTemplate" type="uddi:bindingTemplate" />

<complexType name="bindingTemplate">

<sequence>

<element ref="uddi:description" minOccurs="0"


<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>


tModel Structure (XML Schema)

<element name="tModel" type="uddi:tModel" />

<complexType name="tModel">

<sequence>

<element ref="uddi:name" />

<element ref="uddi:description" minOccurs="0"


<element ref="uddi:overviewDoc" minOccurs="0" />

<element ref="uddi:identifierBag" 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>


Example of a Registration

businessEntityTB993… Harbour Metalswww.harbourmetals.co.au“Serving Inner Sydney Harbour for …contactsbusinessServicesidentifierBagcategoryBag

872-68914281 King’s Blvd, Sydney, [email protected]

Peter Smythe

businessServiceKeyNameDescriptionBindingTemplates

businessService

23T701e54683nf…Online catalog“Website where you can …BindingTemplates

BindingTemplate5E2D412E5-44EE-…http://www.sydneynet/harbour…tModelInstanceDetails

tModelInstanceInfo

4453D6FC-223C-3ED0…

http://www.rosetta.net/catalogPIP

keyedReference

DFE-2B…DUNS45231

keyedReference

EE123…NAICS02417

tModelKeys


UDDI at Work

Harbour Metals createsonline website with local provider…

1.SydneyNet.com(local provider)

Marketplaces and search enginesquery UBR, cache Harbour Metals data, and bind to its services

3. Consumers and businesses discover Harbour Metals and do business with it

4.

2.

…who registersHarbour Metals with UBR

UDDI Business Registry


IBM

Ariba

Microsoftother

other

Registry Operation

Peer nodes (websites) Companies register

with any node Registrations replicated

on a daily basis Complete set of

“registered” recordsavailable at all nodes

Common set ofSOAP APIs supportedby all nodes

Compliance enforced bybusiness contract

UDDI.org

queries


UDDI and SOAP

User UDDI

SOAP Request

UDDISOAP Response

UDDI RegistryNode

HTTPServer

SOAPProcessor

UDDIRegistry Service

B2B DirectoryCreate, View, Update, and Deleteregistrations Implementation-

neutral


Registry APIs (SOAP Messages)

Inquiry API Find things

find_business find_service find_binding find_tModel

Get Details about things get_businessDetail get_serviceDetail get_bindingDetail get_tModelDetail

Publishers API Save things

save_business save_service save_binding save_tModel

Delete things delete_business delete_service delete_binding delete_tModel

security… get_authToken discard_authToken


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>

http://example.com/stockquote.wsdl


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>


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 Software Development Spring 2007

Documents

Transcript of EMTM 600 Software Development Spring 2007