Chapter-1

Web Service Overview (Continued…)

BY-

RUBEENA BANU

Under The Guidance Of

DR.N.SHANKRAIAH

( I.I.Sc)

The topics we have already gone through :

What Are Web Services ?

History

Other Concerns

Java And Web Services

Application Scenarios

Business To Business

Enterprise Application Integration

Contents

Implementation Scenarios

1. Simple Services

2. Composite Services

3. Middleware Service

4. Service Bus

Benefits Of Web Services

A Word About Standards

Summary

1.IMPLEMENTATION

SCENARIOS Since a Web service can be developed on many different types of platforms, it can follow

many different implementation models.

The implementation model it uses depends on the problem it needs to solve and the

platforms available to create it.

The model for Web service implementations can be grouped into four types:

1. simple service,

2. composite service,

3. middleware service,

4. and service bus.

• Extensions within a UDDI registry are usually associated with one or

more tModels that hold reference to the extension.

• The tModel in this scenario indicates that it represents an extension

to one or more UDDI APIs. By using tModels, clients can discover

extensions to the core UDDI API. An example is shown below:

<keyedReference keyName="uddi-org:derivedFrom:v2_inquiry"

keyValue="uddi:uddi.org:v2_inquiry"

tModelKey="uddi:uddi.org:categorization:derivedFrom"/>

Flute Bank has decided to take advantage of the extension

capabilities of UDDI to add supporting documentation as

part of the UDDI publisher Assertion data structure.

The bank has added a discovery URL element to the

publisher Assertion structure that will contain a URL to the

business agreements and licensing terms agreed upon

between Flute Bank and its partners.

1.Extending the publisherAssertion structure

<xsd:schema

targetNamespace="http://flutebank.com/uddi_extension"

xmlns:egExt="http://flutebank.com/uddi_extension"

xmlns:xsd="http://www.w3.org/2001/XMLSchema"

xmlns:uddi="urn:uddi-org:api_v3"

elementFormDefault="qualified"

attributeFormDefault="unqualified">

 

<xsd:import namespace="urn:uddi-org:api_v3"

schemaLocation="http://www.uddi.org/schema/uddi_v3.xsd" />

<xsd:element name="publisherAssertionExt"

type="egExt:publisherAssertionExt"

substitutionGroup="uddi:publisherAssertion"/>

<xsd:complexType name=publisherAssertionExt">

<xsd:annotation>

<xsd:documentation>Extension of

publisherAssertion</xsd:documentation>

</xsd:annotation>

<xsd:complexContent>

<xsd:extension base="uddi:publisherAssertion">

<xsd:sequence>

<xsd:element ref="uddi:discoveryURLs" minOccurs="0" />

</xsd:sequence>

</xsd:extension>

</xsd:complexContent>

</xsd:complexType>

</xsd:schema>

UDDI4J

UDDI4J is a Java client API used to access a UDDI registry.

UDDI4J objects and methods are used to build a request message in SOAP format that is sent to the registry.

UDDI4J was originally developed by IBM as an open source undertaking and has the endorsement of HP, SAP, and others.

UDDI4J contains APIs that allows you to publish, find, and bind to a Web service.

Because UDDI4J is open source, it comes with source code, JavaDoc, and several sample applications. It contains multiple APIs but the one most frequently used is the UDDIProxy class.

How UDDI Proxy class interacts with a registry:

UDDIProxy proxy = new UDDIProxy();

 

proxy.setInquiryURL("http://www.flutebank.com/uddi/test/inquiryapi");

 

proxy.setPublishURL("https://www.flutebank.com/uddi/test/publishapi");

The code for changing providers

The publish URL can use protocols other than SSL for publication as long as it is supported by a valid Java security provider (JSSE). As you may be aware, security providers are configured in the java.security configuration file or, alternatively, can be done at runtime. The code for changing providers is simple:

System.setProperty("java.protocol.handler.pkgs"," com.sun.net.ssl.internal.www

.protocol");

Java.security.Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider());

System Properties Supported by UDDI4J

System Properties Supported by UDDI4J

Property Description

http.proxyHost The hostname of the network proxy server.

http.proxyPort The port number used by the network proxy server. This defaults to port 80.

https.proxyHost he hostname of the network proxy server that supports SSL. This is usually the same server as HTTP.

https.proxyPort The port number used by the network proxy server for SSL. This defaults to port 443.

socksProxy.Host The hostname of the network proxy server that supports Socks-based proxies.

socksProxy.Port The port number used by the network proxy server.

A user who wanted to find all businesses that meet a specified criterion, such as

companies that start with the name "Flute," would use the find_business method

of the proxy similar to this:

BusinessList bl = proxy.find_business("Flute", null, 0);

The find_business method has three parameters:

The first contains the search string, the second points to an instance of a

FindQualifiers object, for which we are specifying null, and the third is the

number of matches to return.

Zero specifies that we should return all matches. For advanced searching, you

can use the FindQualifiers object to include searching on business categories,

identifiers, and tModels.

The BusinessList object is a collection that contains all businesses that match

the search criteria.

Let us look at a simple example that specifies the name of the business and the

operator:

AuthToken token = proxy.get_authToken("uid"," pass");

 

Vector entityVector = new Vector();

BusinessEntity be = new BusinessEntity("");

 

be.setName("Flute Bank");

be.setOperator("Administrator");

 

entityVector.addElement(be);

BusinessDetail bd = proxy.save_business(token.getAuthInfoString(),

entityVector);

2.Creating a new business assertion

// Create a vector of names

Vector names = new Vector();

names.add(new Name("Flute Bank Biche")));

 

// Let's make search case sensitive

FindQualifiers findQualifiers = new FindQualifiers

Vector qualifier = new Vector();

qualifier.add(new FindQualifier("caseSensitiveMatch"));

findQualifiers.setFindQualifierVector(qualifier);

 

// Search for specified business and limit result to 10BusinessList businessList = proxy.find_business(names, null, null, null, null, findQualifiers, 10);Vector businessInfoVector = businessList.getBusinessInfos().getBusinessInfoVector(); // Delete any businesses returned from the searchfor (int ii = 0; ii < businessInfoVector.size(); ii++) { BusinessInfo bi = (BusinessInfo)businessInfoVector.elementAt(ii); DispositionReport dr = proxy.delete_business(token.getAuthInfoString(), bi.getBusinessKey()); if (dr.success()) { System.out.println("Business Deleted"); } else System.out.println("Error Number: "+ dr.getErrno() + "\n Error Code: "+ dr.getErrCode() + "\n Error Text: "+ dr.getErrInfoText()); }} 

3.Creating a new publisher assertion

Vector descriptionVector = businessInfo.getDescriptionVector();

String businessDescription = "";

String defaultDescription = "";

 

for (int ii = 0; ii < descriptionVector.size(); ii++) {

Description description = (Description)descriptionVector.elementAt(ii);

 

if (description.getLang().compareToIgnoreCase("en-zh") == 0) {

businessDescription = description.getText();

break;

}

// More than likely a business will have an English description.

// Use this as default

 

if (description.getLang().compareToIgnoreCase("en-us") == 0) {

defaultDescription = description.getText();

}

 

// If none in Chinese, then use default

if (businessDescription == "") {

businessDescription = defaultDescription;

}

 

// Convert to appropriate character set

businessDescription = new String(businessDescription.getBytes("ISO-

8859-1")," UTF-8);

Private UDDI Registries

Many organizations may not use external Web services for years to come.

Instead, they will use Web services for providing integration between legacy systems, customer relationship management applications, and other internal systems.

In this scenario, it makes sense for an enterprise to consider implementing its own private UDDI registry.

Having your own private registry brings many other benefits.

Sometimes it is advisable to restrict who is allowed to view service description information, especially for sensitive services.

The organization can not only control who publishes information but can also require authentication.

Private UDDI registry implementations are available from BEA, IONA, Microsoft, Systinet, and the Mind Electric.

A private UDDI registry can be further extended to support the following business scenarios :

a) Marketplace registries

b) Portal registries

c) Enterprise application integration

registries

a. Marketplace registries

Marketplace registries are hosted by industry consortiums that collaborate and compete in a

particular industry vertical.

Many businesses are cooperating and forming consortiums that allow them to conduct

business more easily.

Several examples in the market exist today where a marketplace registry would be useful.

The Big Three automakers—Ford, General Motors, and Daimler/Chrysler—might want to

unify their purchasing power on commodity parts.

b. Portal Registries

Flute Bank currently maintains a presence on the World Wide Web at

www.flutebank.com.

The bank has also decided to maintain a presence on the semantic web by exposing

its private UDDI registry at www.flutebank.com/services/uddi. It uses the portal

metaphor.

Flute Bank has registered itself in multiple public registries. It also populated the

discoveryURL element in its businessEntity registration with the location of its private

UDDI registry.

A partial businessEntity registration example is shown below:

<businessEntity authorizedName="...“

businessKey="BAB3C425-A2C3-22E1-FA23-AB2324D3BC8" ... >

<discoveryURLs>

<discoveryURL useType="businessEntity">

http://www.publicuddi.com/uddiget?businessKey=BC234221 ...

</discoveryURL>

<discoveryURL useType="urn:uddi-inquiry-api">

http://www.flutebank.com/services/uddi

</discoveryURL>

</discoveryURLs>

<name>Flute Bank</name>

...

</businessEntity>

c. Enterprise Application Integration Registries

Enterprise Application Integration registries are used in the same manner as partner registries, except

that they contain services available from other departments or divisions within an organization.

Considerations

Here are some of the recommendations and considerations an architect of a Web services initiative

should consider before implementing an in-house registry:

1. The vast majority of Web services applications will not use a public registry.

2. A private registry makes sense for large organizations, such as the Fortune 500, where the number of

services created are used across the enterprise and/ or divisional boundaries.

3. A private registry makes little sense for a small IT shop, where the number of services will be small

and/or used by a few applications.

UDDI Futures

UDDI Version 3.0 was released in July 2002. Future versions of UDDI will be built on the

foundation of prior versions and incorporate many enhancement requests, including additional

security functionality, advanced WSDL support, multiregistry topologies, and a new

subscription API.

i. Digital Signatures

ii. Human-Friendly Keys

iii. Subscriptions, etc;

Summary In this chapter, we looked at different UDDI considerations for implementing Web services,

including

Discovering Web services

Categorizing services

Business entity relationships

Using UDDI SOAP interfaces

UDDI and SOAP/WSDL relationships

Publishing WSDL service interfaces in UDDI

Extending a UDDI registry

UDDI4J

Private UDDI registries

“

”THANK YOU…!!!