Web Services Developer s Guide

(1)

Web Services

Developer’s Guide

V E R S I O N 8

Borland

®

(2)

Refer to the file deploy.html located in the redist directory of your JBuilder product for a complete list of files that you can distribute in accordance with the JBuilder License Statement and Limited Warranty.

Borland Software Corporation may have patents and/or pending patent applications covering subject matter in this document. Please refer to the product CD or the About dialog box for the list of applicable patents. The furnishing of this document does not give you any license to these patents.

COPYRIGHT © 2001–2002 Borland Software Corporation. All rights reserved. All Borland brand and product names are trademarks or registered trademarks of Borland Software Corporation in the United States and other countries. All other marks are the property of their respective owners.

(3)

Chapter 1 Introduction

1-1

Documentation conventions . . . 1-3 Developer support and resources . . . 1-5 Contacting Borland Technical Support. . . . 1-5 Online resources . . . 1-5 World Wide Web . . . 1-6 Borland newsgroups . . . 1-6 Usenet newsgroups . . . 1-6 Reporting bugs . . . 1-7

Chapter 2 Introducing web services

2-1

Web services architecture . . . 2-2 Web services standards . . . 2-3 Simple Object Access Protocol (SOAP) . . . 2-3 Web Services Description

Language (WSDL) . . . 2-4 Universal Description, Discovery

and Integration (UDDI) . . . 2-5 Web Services Inspection Language

(WSIL) . . . 2-5 Java APIs for XML-based Remote

Procedure Call (JAX-RPC) . . . 2-6 JBuilder and web services. . . 2-7

Consuming and creating web

services with JBuilder wizards . . . 2-8 Web services samples . . . 2-8 Supported enterprise application servers . . 2-8

Chapter 3 Configuring projects for

web services

3-1

Working with the Web Services

Configuration wizard . . . 3-1 Naming the WebApp . . . 3-3 Selecting an EAR . . . 3-3 Selecting a web services toolkit . . . 3-3 Apache Axis toolkit. . . 3-3 WebLogic toolkit . . . 3-4 Apache SOAP 2 toolkit . . . 3-4 Defining a runtime configuration

for the web services server . . . 3-5

Examining the WebApp node . . . . 3-5 Starting the web services server . . . . 3-5 Setting build options . . . . 3-6

Chapter 4 Monitoring SOAP messages

4-1

Using the TCP Monitor. . . . 4-2 Creating a new TCP/IP Monitor . . . . 4-3 Monitoring a service’s SOAP messages. . . . 4-4 Using the WebLogic Web Services Home Page . 4-5

Chapter 5 Working with WSDL

5-1

WSDL terms . . . . 5-2 WSDL samples . . . . 5-3

Chapter 6 Developing EJBs as web services

6-1

Chapter 7 Using the Apache Axis toolkit

7-1

Exporting a class as a web service. . . . 7-1 Importing a WSDL . . . . 7-5 Exporting EJBs as web services . . . . 7-9 Importing services as EJB applications . . . 7-10

Importing services as EJB applications

in the Web Services Explorer . . . 7-12 Deploying web services . . . 7-13 Understanding WSDD files . . . 7-13 deploy.wsdd . . . 7-13 Editing WSDD files for EJBs . . . 7-14 server-config.wsdd . . . 7-16 Editing server-config.wsdd . . . 7-16

Chapter 8 Using the WebLogic toolkit

8-1

Exporting a class as a web service. . . . 8-2 Exporting multiple classes as

a web service . . . . 8-5 Importing a WSDL or an EAR as

a web service. . . . 8-6 Importing an EAR as a web service . . . . 8-6 Importing a WSDL as a web service . . . . . 8-7

(4)

Testing deployed services . . . 8-8 Writing a test client. . . . 8-10 Exporting EJBs as web services. . . . 8-11 Deploying web services . . . . 8-13 Understanding WLDU files . . . . 8-13 Editing WLDU files for EJBs . . . . 8-14

Modifying the EJB deployment

node properties . . . . 8-14 Editing the WLDU and modifying

the <documentation> element. . . . 8-15 web-services.xml . . . . 8-15

Manually deploying services

with web-services.xml . . . . 8-16 Setting service naming defaults . . . . 8-17

Chapter 9 Using the Apache SOAP 2 toolkit

9-1

Exporting a class as a web service . . . 9-2 Importing a WSDL. . . 9-2

Chapter 10 Modifying enterprise application

server settings for web services

10-1

Borland Enterprise Server 5.0.2-5.1.x . . . . 10-1 WebLogic Server 7.0 (with and without SP1) . . 10-2 WebSphere Application Server 4.0 AE/AES . . 10-2

Chapter 11 Browsing and publishing

web services

11-1

Web Services Explorer overview . . . . 11-1 UDDI overview . . . . 11-3 UDDI terms and definitions. . . . 11-4 Axis overview . . . . 11-5 WSIL overview . . . . 11-5 Adding and deleting nodes in the

Explorer’s tree . . . . 11-6 Searching a UDDI registry . . . . 11-7 Searching for businesses . . . . 11-8 Searching by name . . . . 11-8 Searching by category . . . . 11-9 Searching by identifier . . . 11-11

Searching for services . . . .11-12 Searching for tModels. . . .11-13 Searching by name. . . .11-13 Examining UDDI query results . . . .11-14 UDDI Detail pages . . . .11-14 Details page . . . .11-15 Business Details page . . . .11-15 Service Details page . . . .11-15 Binding Details page . . . .11-15 TModel Instance Details page . . . .11-15 TModel Details page . . . .11-15 Searching an Axis server for web services . . .11-16 Displaying services . . . .11-16 Importing a WSDL and publishing

Axis web services . . . .11-17 Accessing remote Axis servers. . . .11-18 Searching web services with WSIL

documents . . . .11-19 Services node . . . .11-19 Links node . . . .11-20 Executing a search with a WSIL

document . . . .11-21 Publishing web services to a UDDI registry . .11-22

Registering at the UDDI site through

a web browser . . . .11-22 Creating and deploying a service . . . .11-22 Publishing businesses and services . . . . .11-23 Publishing tModels . . . .11-24 Publishing web services from an Axis server .11-24

Creating and deploying web services

hosted on an Axis server . . . .11-24 Displaying Axis-hosted web services . . . .11-25 Publishing from the Axis server . . . .11-25 Monitoring UDDI messages . . . .11-26 Generating Java classes from

WSDL documents . . . .11-26

Chapter 12 Web services tutorials

12-1

Axis web services tutorials. . . 12-1 WebLogic web services tutorials . . . 12-2 General web services tutorials. . . 12-2

(5)

Chapter 13 Tutorial: Creating a simple

web service with Axis

13-1

Step 1: Creating a sample JavaBean . . . . 13-2 Step 2: Exporting the sample bean as

a web service and configuring the

project for web services . . . . 13-2 Step 3: Deploying, running, and

testing the web service. . . . 13-5

Chapter 14 Tutorial: Generating a web service

from a WSDL document

14-1

Step 1: Configuring the project for

web services . . . . 14-2 Step 2: Importing the WSDL document . . . . . 14-3 Step 3: Looking at the deployment descriptors . 14-4 Step 4: Implementing the service. . . . 14-5 Step 5: Creating the Public web application . . 14-6 Step 6: Creating a JSP that invokes the

web service . . . . 14-6 Step 7: Implementing the bean . . . . 14-9 Step 8: Invoking the web service and

monitoring SOAP messages . . . 14-11

Chapter 15 Tutorial: Creating a web service

from an EJB application

with Borland Enterprise Server

15-1

Step 1: Setting up the sample project . . . . 15-2 Step 2: Creating a web services server and

deploying to the application server . . . . 15-2 Step 3: Generating client and server code

from the WSDL . . . . 15-4 Step 4: Testing the service . . . . 15-5 Step 5: Writing the client and consuming

the service . . . . 15-6

Chapter 16 Tutorial: Importing a web service

as an EJB application

16-1

Step 1: Adding a WSDL document to

the project . . . . 16-2 Step 2: Creating an EJB application

from the WSDL . . . . 16-2 Step 3: Testing the EJB application . . . . 16-3

Chapter 17 Tutorial: Creating a simple

web service with WebLogic

17-1

Step 1: Creating a sample JavaBean . . . 17-2 Step 2: Exporting the sample bean as

a web service. . . 17-2 Step 3: Running the server and

deploying the service . . . 17-5 Step 4: Testing the deployed service . . . 17-5 Step 5: Writing a client to test the service. . . . 17-6

Chapter 18 Tutorial: Creating a web service

from an EJB application

with WebLogic Server

18-1

Step 1: Setting up the project. . . 18-2 Step 2: Configuring the project for

web services . . . 18-2 Step 3: Deploying the EJB as a web service . . 18-3 Step 4: Generating client-side code

from the WSDL . . . 18-4 Step 5: Writing the client and consuming

the service locally . . . 18-4

Chapter 19 Tutorial: Browsing UDDI

web services

19-1

Step 1: Browsing web services at the

XMethods site . . . 19-2 Step 2: Browsing tModels . . . 19-4 Step 3: Finding software publishers

at the Microsoft UDDI site . . . 19-5 Step 4: Generating Java classes . . . 19-7

(6)

Creating a simple web service with Axis . . . . 13-1 Generating a web service from a

WSDL document, Axis . . . . 14-1 Creating a web service from

an EJB application, Axis . . . . 15-1 Importing a web service as an

EJB application, Axis. . . . 16-1

Creating a simple web service

with WebLogic. . . 17-1 Creating a web service from

an EJB application with WebLogic Server . . 18-1 Browsing UDDI web services . . . 19-1

(7)

C h a p t e r

1

Chapter1

Introduction

This is a feature of JBuilder Enterprise

The Web Services Developer’s Guide explains how to use the JBuilder web services features to create, browse, consume, and publish web services. The Web Services Developer’s Guide contains the following chapters: • Chapter 2, “Introducing web services”

Provides an overview of web services and the web services features available in JBuilder.

• Chapter 3, “Configuring projects for web services”

Explains how to create a web services server to host a web service using the Web Services Configuration wizard and how to run the web services server in the JBuilder IDE.

• Chapter 4, “Monitoring SOAP messages”

Describes how to monitor SOAP messages using tools provided by the web services toolkits.

• Chapter 5, “Working with WSDL”

Gives an overview of the Web Services Description Language (WSDL) and how it’s used in web services.

• Chapter 6, “Developing EJBs as web services”

Provides an overview of how JBuilder develops Enterprise JavaBeans as web services.

• Chapter 7, “Using the Apache Axis toolkit”

Describes how to use the Apache Axis toolkit to develop web services. Support for the Apache Axis toolkit is not provided with the JBuilder WebLogic Edition.

(8)

I n t r o d u c t i o n

• Chapter 8, “Using the WebLogic toolkit”

Describes how to use the WebLogic toolkit to develop web services. • Chapter 9, “Using the Apache SOAP 2 toolkit”

Describes how to use the Apache SOAP 2 toolkit to develop web services.

• Chapter 10, “Modifying enterprise application server settings for web services”

Describes the enterprise application servers supported by JBuilder for web services and provides information on custom settings for various servers.

• Chapter 11, “Browsing and publishing web services”

Describes how to use the Web Services Explorer to browse and publish web services.

• Web services samples

Web services samples are available in the following JBuilder directories: • samples/webservices/axis • samples/webservices/weblogic • thirdparty/apache-soap/samples • thirdparty/xml-axis/java/samples • Axis tutorials:

Support for the Apache Axis toolkit is not provided with the JBuilder WebLogic Edition

• Chapter 13, “Tutorial: Creating a simple web service with Axis”

Explains how to use the Export As A Web Service wizard to export a JavaBean as a web service with the Axis toolkit, exposing selected methods to the web service consumer.

• Chapter 14, “Tutorial: Generating a web service from a WSDL document”

Explains how to use the Import A Web Service wizard to generate Java classes for a web service with the Axis toolkit, then implement the classes to provide access to AltaVista’s BabelFish translation service. • Chapter 15, “Tutorial: Creating a web service from an EJB

application with Borland Enterprise Server”

Explains how to create a web service from an Enterprise JavaBean application using Borland Enterprise Server.

(9)

I n t r o d u c t i o n

• Chapter 16, “Tutorial: Importing a web service as an EJB application”

Describes how to import a WSDL as an EJB application using the Axis toolkit and Borland Enterprise Server.

• WebLogic tutorials:

• Chapter 17, “Tutorial: Creating a simple web service with WebLogic”

Explains how to use the Export As A Web Service wizard to publish a JavaBean as a web service, exposing selected methods to the web service consumer.

• Chapter 18, “Tutorial: Creating a web service from an EJB application with WebLogic Server”

Explains how to create a web service from an EJB application using WebLogic Server.

• General tutorials:

• Chapter 19, “Tutorial: Browsing UDDI web services”

Explains how to use the Web Services Explorer to browse web services and generate Java classes from a WSDL document.

(10)

D o c u m e n t a t i o n c o n v e n t i o n s

Documentation conventions

The Borland documentation for JBuilder uses the typefaces and symbols described in the following table to indicate special text.

Table 1.1 Typeface and symbol conventions

Typeface Meaning

Monospaced type Monospaced type represents the following: • text as it appears onscreen

• anything you must type, such as “Type Hello World in the Title field of the Application wizard.”

• file names • path names

• directory and folder names • commands, such as SET PATH • Java code

• Java data types, such as boolean, int, and long.

• Java identifiers, such as names of variables, classes, package names, interfaces, components, properties, methods, and events

• argument names • field names

• Java keywords, such as void and static

Bold Bold is used for java tools, bmj (Borland Make for Java), bcj (Borland Compiler for Java), and compiler options. For example:

javac, bmj, -classpath.

Italics Italicized words are used for new terms being defined, for book titles, and occasionally for emphasis.

Keycaps This typeface indicates a key on your keyboard, such as “Press Esc to exit a menu.”

[ ] Square brackets in text or syntax listings enclose optional items. Do not type the brackets.

< > Angle brackets are used to indicate variables in directory paths, command options, and code samples.

For example, <filename> may be used to indicate where you need to supply a file name (including file extension), and <username> typically indicates that you must provide your user name. When replacing variables in directory paths, command options, and code samples, replace the entire variable, including the angle brackets (< >). For example, you would replace <filename> with the name of a file, such as employee.jds, and omit the angle brackets.

(11)

D o c u m e n t a t i o n c o n v e n t i o n s

JBuilder is available on multiple platforms. See the following table for a description of platform conventions used in the documentation.

Italics, serif This formatting is used to indicate variable strings within code samples that are already using angle brackets as delimiters. For example, <url="jdbc:borland:jbuilder\\samples\\guestbook.jds">

... In code examples, an ellipsis (...) indicates code that has been omitted from the example to save space and improve clarity. On a button, an ellipsis indicates that the button links to a selection dialog box.

Table 1.2 Platform conventions

Item Meaning

Paths Directory paths in the documentation are indicated with a forward slash (/).

For Windows platforms, use a backslash (\).

Home directory The location of the standard home directory varies by platform and is indicated with a variable, <home>.

• For UNIX and Linux, the home directory can vary. For example, it could be /user/<username> or /home/<username> • For Windows NT, the home directory is C:\Winnt\Profiles\

• For Windows 2000 and XP, the home directory is C:\Documents and Settings\<username>

Screen shots Screen shots reflect the Metal Look & Feel on various platforms.

Table 1.1 Typeface and symbol conventions (continued)

(12)

D e v e l o p e r s u p p o r t a n d r e s o u r c e s

Developer support and resources

Borland provides a variety of support options and information resources to help developers get the most out of their Borland products. These options include a range of Borland Technical Support programs, as well as free services on the Internet, where you can search our extensive

information base and connect with other users of Borland products.

Contacting Borland Technical Support

Borland offers several support programs for customers and prospective customers. You can choose from several categories of support, ranging from free support on installation of the Borland product to fee-based consultant-level support and extensive assistance.

For more information about Borland’s developer support services, see our web site at http://www.borland.com/devsupport/, call Borland Assist at (800) 523-7070, or contact our Sales Department at (831) 431-1064.

When contacting support, be prepared to provide complete information about your environment, the version of the product you are using, and a detailed description of the problem.

For support on third-party tools or documentation, contact the vendor of the tool.

Online resources

You can get information from any of these online sources:

World Wide Web http://www.borland.com/

FTP ftp://ftp.borland.com/

Technical documents available by anonymous ftp. Listserv To subscribe to electronic newsletters, use the online

form at:

http://info.borland.com/contact/listserv.html or, for Borland’s international listserver, http://info.borland.com/contact/intlist.html

(13)

World Wide Web

Check www.borland.com/jbuilder regularly. This is where the Java Products Development Team posts white papers, competitive analyses, answers to frequently asked questions, sample applications, updated software, updated documentation, and information about new and existing products.

You may want to check these URLs in particular:

• http://www.borland.com/jbuilder/ (updated software and other files) • http://www.borland.com/techpubs/jbuilder/ (updated documentation and

other files)

• http://community.borland.com/ (contains our web-based news magazine for developers)

Borland newsgroups

You can register JBuilder and participate in many threaded discussion groups devoted to JBuilder. The Borland newsgroups provide a means for the global community of Borland customers to exchange tips and

techniques about Borland products and related tools and technologies. You can find user-supported newsgroups for JBuilder and other Borland products at http://www.borland.com/newsgroups/.

Usenet newsgroups

The following Usenet groups are devoted to Java and related programming issues: • news:comp.lang.java.advocacy • news:comp.lang.java.announce • news:comp.lang.java.beans • news:comp.lang.java.databases • news:comp.lang.java.gui • news:comp.lang.java.help • news:comp.lang.java.machine • news:comp.lang.java.programmer • news:comp.lang.java.security • news:comp.lang.java.softwaretools

Note These newsgroups are maintained by users and are not official Borland sites.

(14)

Reporting bugs

If you find what you think may be a bug in the software, please report it in the Support Programs page at http://www.borland.com/devsupport/namerica/. Click the “Reporting Defects” link to bring up the Entry Form.

When you report a bug, please include all the steps needed to reproduce the bug, including any special environmental settings you used and other programs you were using with JBuilder. Please be specific about the expected behavior versus what actually happened.

If you have comments (compliments, suggestions, or issues) for the JBuilder documentation team, you may email [email protected]. This is for documentation issues only. Please note that you must address support issues to developer support.

JBuilder is made by developers for developers. We really value your input.

(15)

C h a p t e r

2

Chapter2

Introducing web services

A web service is a software module performing a discrete task or set of tasks that can be found and invoked over a network including and especially the World Wide Web. The developer can create a client application that invokes a series of web services through remote

procedure calls (RPC) or a messaging service to provide some or most of the application’s logic. A published web service describes itself so that developers can locate the web service and evaluate its suitability for their needs.

As an example, a company could provide a web service to their customers to check inventory on products before they order. Another example is the Federal Express package tracking service that customers can use to track their shipments.

Web services use SOAP (Simple Object Access Protocol) for the XML payload and uses a transport such as HTTP to carry the the SOAP messages back and forth. SOAP messages are actually XML documents that are sent between a web service and the calling application.

Web services can be written in any language and run on any platform. A client of a web service can also be written in any language and run on any platform. So, for example, a client written using Delphi and running on Windows could call a web service written in Java and running on Linux.

(16)

W e b s e r v i c e s a r c h i t e c t u r e

Web services architecture

The web services architecture permits the development of web services that encapsulate all levels of business functionality. In other words, a web service can be very simple, such as one that returns the current

temperature, or it can be a complex application. The architecture also allows multiple web services to be combined to create new functionality. The web services architecture has three distinct roles: a provider, a requestor, and a broker. The provider creates the web service and makes it available to clients who want to use it. A requestor is a client application that consumes the web service. The requested web service can also be a client of other web services. The broker, such as a service registry, provides a way for the provider and the requestor of a web service to interact.

The three roles of provider, requestor, and broker interact with each other through the operations of publish, find, and bind. A provider informs the broker about the existence of the web service by using the broker’s publish interface to make the service accessible to clients. The information

published describes the service and specifies where the service is located. The requestor consults the broker to locate a published web service. With the information it gained from the broker about the web service, the requestor is able to bind, or invoke, the web service.

This diagram summarizes how the provider, requestor, and broker interact with each other:

Figure 2.1 Web service roles and operations

FIND

PUBLISH

Service

Registry

Service

Requestor

Service

Provider

BIND

(17)

W e b s e r v i c e s s t a n d a r d s

Web services standards

The standards on which web service development is based are evolving technologies. The primary players are SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language), UDDI (Universal Description, Discovery and Integration), and WSIL (Web Services

Inspection Language).

Simple Object Access Protocol (SOAP)

SOAP is a transport-independent messaging protocol. Each SOAP message is an XML document. SOAP uses one-way messages, although it’s possible to combine messages into request-and-response sequences. The SOAP specification defines the format of the XML message but not its content and how it’s actually sent. SOAP does, however, specify how SOAP messages are routed over HTTP.

Each SOAP document has a root <Envelope> element. The root element, the first element in an XML document, contains all the other elements in the document. Within the “envelope” are two parts: a header and a body. The header contains routing or context data. It can be empty. The body contains the actual message. It too can be empty.

XML HTTP SOAP

Service

Registry

Service

Requestor

Service

Provider

XML HTTP SOAP XML HTTP SOAP

(18)

Here is an example of a simple SOAP message sent over HTTP that requests the current stock price of Borland:

POST /StockQuote HTTP/1.1 Host: www.stockquoteserver.com

Content-Type: text/xml; charset="utf-8" Content-Length: nnnn SOAPAction: "urn:stock-quote-services" <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <SOAP-ENV:Body> <m:GetLastTradePrice xmlns:m="Some-URI"> <symbol>BORL</symbol> </m:GetLastTradePrice> </SOAP-ENV:Body> </SOAP-ENV:Envelope>

For more information about SOAP, start with the SOAP documents on the World Wide Consortium web site at http://www.w3.org/2002/ws/. Also visit the Apache SOAP site at http://xml.apache.org/soap/.

Web Services Description Language (WSDL)

A web service is useless unless others can find out what it does and how to call it. Developers must know enough information about a web service so they can write a client program that calls it. WSDL is an XML-based language used to define web services and describe how to access them. Specifically, it describes the data and message contracts a web service offers. By examining a web service’s WSDL document, developers know what methods are available and how to call them using the proper parameters.

Service

Requestor

Service

Provider

WSDL

(19)

For in-depth information about WSDL, see the Web Services Description Language 1.1 specification at http://www.w3.org/TR/wsdl on the World Wide Web Consortium web site.

Universal Description, Discovery and Integration (UDDI)

UDDI is an evolving standard for describing, publishing, and discovering the web services that a business provides. It’s a specification for a

distributed registry of information on web services. Once a web service is developed and a WSDL document describing it is created, there needs to be a way to get the WSDL information into the hands of the users who want to use the web service it describes. When a web service is published in a UDDI registry, potential users have a way to look up and learn about the web service’s existence.

The content of a UDDI registry is similar to a telephone directory. In the “white pages” section of the registry is information such as the name, address, and telephone number of the business that offers one or more web services. The “yellow pages” section identifies the business type and categorizes it by industry. The “green pages” section provides the data about the web services the business offers.

To read more about UDDI, see the UDDI.org web site at http://www.uddi.org.

Web Services Inspection Language (WSIL)

WSIL, like UDDI, provides a method of service discovery for web services. Unlike UDDI, WSIL uses a decentralized, distributed model, rather than a centralized model. WSIL documents, which are essentially pointers to lists of services, allow consumers of web services to browse available services on web sites. The WSIL specification provides standards

Service

Registry

Service

Requestor

Service

Provider

WSDL UDDI WSDL UDDI

(20)

of rules for how the information is made available. A WSIL document gathers multiple references to pre-existing service description documents in one document. The WSIL document is then hosted by the provider of the service, so consumers can find out about available services.

For more information on the Web Services Inspection Language (WS-Inspection) 1.0 specification, see http://www-106.ibm.com/ developerworks/webservices/library/ws-wsilspec.html.

Java APIs for XML-based Remote Procedure Call (JAX-RPC)

JAX-RPC defines Java APIs that Java developers can use in their

applications to develop and consume web services. Using JAX-RPC, a Java client can consume a web service on a remote server over the Internet, even if the service is written in another language and running on a different platform. A JAX-RPC service can also be consumed by

non-Java clients.

JAX-RPC uses an XML-messaging protocol, such as SOAP, to transmit a remote procedure call over a network. For example, a web service that returns a stock quote would receive a SOAP HTTP request containing a method call from the client. Using JAX-RPC, the service extracts the method call from the SOAP message, translates it into a method call, and invokes it. Then the service uses JAX-RPC to convert the method response back into SOAP and send the results back to the client. The client receives the SOAP message and uses JAX-RPC to translate it into a response.

Service

Provider

UDDI

Registry

WSIL

Service

Description

Service

Description

(21)

J B u i l d e r a n d w e b s e r v i c e s

as a proxy for the service. A tie, which is on the server side, acts as a proxy on the server.

For more information on JAX-RPC, see http://java.sun.com/xml/jaxrpc/ index.html and the JAX-RPC tutorial at http://java.sun.com/webservices/ docs/1.0/tutorial/doc/JAXRPC.html.

JBuilder and web services

Although it’s useful to learn about the technologies behind web services, you don’t have to do such things as actually create the SOAP messages and WSDL descriptions yourself. JBuilder can do these things for you. JBuilder uses the Apache Axis, WebLogic, or Apache SOAP 2 toolkits for its SOAP support. JBuilder can generate the WSDL document for a web service you’ve created. It can also take an existing WSDL for a web service and create the Java class files or EJBs, so you can create a client that invokes the web service. Another option is to use the generated Java code to implement the web service yourself. JBuilder can also quickly create a web application that hosts a web services server.

JBuilder includes the Web Services Explorer for searching for web services that fit your needs, as well as publishing to a UDDI registry.

To see a sample JavaServer Page client that invokes a web service to translate words from one language to another, open the

BasicWebService.jpx project in the JBuilder samples/webservices/axis directory.

Stubs

Client

JAX-RPC

runtime

Ties

Server

JAX-RPC

runtime

SOAP

request response

HTTP

Application

Service

(22)

J B u i l d e r a n d w e b s e r v i c e s

Consuming and creating web services with

JBuilder wizards

JBuilder provides wizards for consuming and creating web services. The Import A Web Service wizard generates Java classes from an existing WSDL document or EAR. You can then implement these classes to consume the service specified in the WSDL. You can also create server-side classes for a web service or implement a web service as an Enterprise JavaBean (EJB) from the imported WSDL. The Export As A Web Service wizard generates a WSDL document from an existing Java class and exposes selected methods of the class as a web service. Available web services features vary by web services toolkit.

These wizards are available on the Web Services page of the object gallery (File|New). They are also available on the context menu in the project pane for the appropriate nodes.

Web services samples

Web services samples are available in the following JBuilder directories: • samples/webservices/axis

• samples/webservices/weblogic • thirdparty/apache-soap/samples • thirdparty/xml-axis/java/samples

Supported enterprise application servers

The JBuilder web services features are supported on the following enterprise application servers:

• Borland Enterprise Server 5.0.2-5.1.x

• WebLogic Server 7.0 (with and without SP1) • WebSphere Application Server 4.0 AES/AE

Support for Borland Enterprise Server and WebSphere Application Server are not provided with the JBuilder WebLogic Edition.

For information about how to use these servers with the JBuilder web services features, see Chapter 10, “Modifying enterprise application server settings for web services.”

(23)

C h a p t e r

3

Chapter3

Configuring projects for

web services

Before you can work with web services in JBuilder, you need to configure the project for web services. The Web Services Configuration wizard creates a configuration for hosting a web service. This involves creating a WebApp and configuring it with the selected web service toolkit library. On application servers, the wizard also creates an eargrp node and links it to the WebApp. In addition, the wizard creates a custom, server-toolkit specific run configuration reflecting the archive selections. The

configuration is sensitive to the server configuration and allows the choice of toolkits which make a server web service capable.

Working with the Web Services Configuration wizard

JBuilder provides the Web Services Configuration wizard for quickly creating a WebApp to host a web service with the appropriate

deployment files. The Web Services Configuration wizard creates a SOAP implementation for the project based upon the selected toolkit, such as Axis, Apache SOAP, or WebLogic. It also creates a Web Services Server runtime configuration for deploying and running the service or an implementation of the service. Once a web service is deployed to the web services server, the web service can receive and send SOAP messages to and from client applications. For more information on SOAP, see

Chapter 4, “Monitoring SOAP messages.”

The web service must be hosted by a web application. If your project doesn’t have an existing web application, you can create one from the Web Services Configuration wizard. For more information on web

(24)

W o r k i n g w i t h t h e W e b S e r v i c e s C o n f i g u r a t i o n w i z a r d

applications, see “Working with WebApps and WAR files” in the Web Application Developer’s Guide.

The Web Services Configuration wizard generates the following nodes and files and adds them to your WebApp. The contents of the nodes vary according to the toolkit selected.

• Web Service Components node

The name of this node is dependent upon the toolkit selected in the wizard. This node contains two child nodes:

• The EJB-based Services node contains any Enterprise JavaBean (EJB) deployment files. All stateless session beans with business methods in the remote interface are automatically deployed. The deployment information is generated in one deployment file per EJB module. At build time the EJB classes in the deployment files are deployed to the server.

• The Java-based Services node contains any Java class deployment files.

• Deployment Descriptors node

The wizard adds the appropriate SOAP information to the web.xml file that describes the WebApp deployment. If Axis is selected as the toolkit, a final deployment file is also generated in this node. • Root Directory node

The wizard adds contents to this node according to the toolkit selected in the wizard.

To open the Web Services Configuration wizard, 1 Choose File|New to open the object gallery.

2 Click the Web Services tab and double-click the Web Services Configuration icon.

3 Choose an EAR in the project or click New to create an EAR. This is only required if you’re using an enterprise application server which requires an EAR.

4 Choose a WebApp in the project to host the service or click New to create a new WebApp.

5 Select a toolkit for the project.

6 Click Next to see the Web Services Server run configuration created for the project.

(25)

Naming the WebApp

The web context, which is the name of the WebApp and the WebApp’s directory, is important. It’s part of the address for invoking the web service. An example of an address to invoke a web service running on your local server might be http://localhost:8080/<web

context>/<serviceURI>. The web context is used in the SOAP address in the WSDL document. In addition, the Axis toolkit uses it in the address for the service port in <ServiceName>Locator.java.

For more information about WebApps, see “Working with WebApps and WAR files” in the Web Application Developer’s Guide.

Selecting an EAR

If the project is configured to use an application server, the Web Services Configuration wizard requires you to select or create an EAR. The EAR is automatically configured by the wizard to include the WebApp archive and is automatically updated at build time to include any referenced EJB JARs used in the web service.

Selecting a web services toolkit

Support for the Apache

Axis and Apache Soap 2 toolkits is not provided with the JBuilder WebLogic Edition

The Toolkit field in the Web Services Configuration wizard gives you a choice of all registered web services toolkits. There are several web services toolkits which are bundled with JBuilder: Apache Axis, Apache SOAP 2, and WebLogic. The Toolkit field could contain additional toolkit plugins if they are available on your machine.

The Copy Admin/Console To WebApp option copies files into the Root Directory folder so that you can use the toolkits’ UI to administer the web services server. Check this option if you would like these files added to the WebApp. The Copy Admin/Console To WebApp option could

potentially be disabled if you are using a toolkit that doesn’t have an admin/console. Both the Apache Axis toolkit and the Apache SOAP 2 toolkit have an admin/console, so this option is enabled for both of them.

Apache Axis toolkit

Support for the Apache Axis toolkit is not provided with the JBuilder WebLogic Edition

The Apache Axis toolkit is an open source implementation of SOAP, the next generation of Apache SOAP 2.0. Axis is a rewrite of Apache SOAP 2.0 that uses SAX instead of DOM. It’s a more modular, flexible, and a higher performance implementation of SOAP than Apache SOAP 2.0. The Apache Axis toolkit is JAX-RPC (Java APIs for XML-based Remote Procedure Call) compliant and supports WSDL 1.1.

(26)

The Apache Axis toolkit generates files for administering, listing deployed services, and validating. For more information on these files, see the toolkit documentation.

Note The Axis toolkit combines each deployment file (deploy.wsdd) in your project into a server-config.wsdd. Any manual edits to the deployment files are overwritten by the toolkit. If you edit server-config.wsdd, turn off the Regenerate Deployment option on the Web Services tab of the Build page of Project Properties or server-config.wsdd will be overwritten by the toolkit when you build the project. See “Setting build options” on page 3-6

for more information.

WebLogic toolkit

WebLogic Server 7.x has built-in web services capability. This option is available when your project specifies WebLogic Server 7.x as the server. WebLogic supports WSDL 1.1 and is JAX-RPC compliant.

Apache SOAP 2 toolkit

Apache SOAP 2 toolkit is an open-source implementation of SOAP 1.1 developed by the Apache SOAP community. This implementation of SOAP uses DOM.

Caution Note that Apache SOAP 2 is an older version of Axis and does not support JAX-RPC or WSDL. Due to these limitations, it’s recommended that you use Axis instead. If you’re using the Apache SOAP 2 toolkit, you need to make modifications in the JBuilder wizards and do additional hand coding. For more information, see Chapter 9, “Using the Apache SOAP 2 toolkit.”

Defining a runtime configuration for the web services server

On the last page of the Web Services Configuration wizard, you can optionally define a runtime configuration for the web services server. The web services server requires a Server type runtime configuration for the server to run.

If no Server type runtime configuration exists and you don’t choose to define one on this page, a runtime configuration called Web Services Server is automatically added for you. This runtime configuration uses the default Server configuration for the project as defined on the Server page of the Project Properties dialog box.

For more information on runtime configurations, see “Setting runtime configurations” in Building Applications with JBuilder.

Examining the WebApp node

After creating a web services server with the Web Services Configuration wizard, you can expand the WebApp node in the project pane to view the child nodes the wizard added. You’ll see a toolkit node, a Deployment Descriptors node, and a Root Directory node. If you added files to administer the WebApp in the Root Directory, expand that node to see the files.

For more information about WebApps, see “Working with WebApps and WAR files” in the Web Application Developer’s Guide.

Starting the web services server

To run the web services server, you must have a Server runtime configuration which uses an appropriate web server. The Web Services Configuration wizard adds the Web Services Server runtime

configuration to your project automatically. For more information about runtime configurations, see “Setting runtime configurations” in Building Applications with JBuilder.

Once you’ve completed the Web Services Configuration wizard, you can start the web services server by choosing Run|Run Project when Web Services Server runtime configuration is the default runtime configuration or by clicking the small arrow next to the Run icon on the main toolbar and selecting the Web Services Server runtime configuration from the list. You can view the server’s progress in the message pane. If you’re using the Axis toolkit, you can also right-click any servlet, JSP, or HTML file in the project pane and select Web Run Using Web Services Server from the context menu.

(28)

S e t t i n g b u i l d o p t i o n s

If you chose to copy the toolkit’s Admin/console files, if available, to the WebApp node when you created the web services server, you can now expand the Root Directory node, right-click the index.html file and select Web Run from the context menu to reach the admin UI for the Axis toolkit. The file to Web Run for the Apache Soap 2 toolkit is

admin/index.html. With the default IDE settings, Web Run when the web server is already running will cause the file to be accessed off the web server.

Setting build options

The Build page of the Project Properties dialog box has a build option for controlling deployment at build time.

To access the build option:

1 Choose Project|Project Properties to open the Project Properties dialog box.

2 Choose the Build tab and click the Web Services tab.

The Regenerate Deployment option is set by default. If this option is set, deployment files are regenerated whenever the project is built. For more details on this option, choose the Help button on the Web Services tab of the Build page.

(29)

C h a p t e r

4

Chapter4

Monitoring SOAP messages

Web services use the Simple Object Access Protocol (SOAP), which provides a messaging protocol for clients and servers to send messages back and forth. SOAP is a transport-independent messaging protocol that allows access to remote objects. SOAP uses a XML as the messaging protocol and a transport layer such as HTTP. SOAP messages are one-way messages, although it’s possible to combine messages into

request-and-response sequences. The SOAP specification defines the format of the XML message, but not its content and how it’s actually sent. SOAP does, however, specify how SOAP messages are routed over HTTP. Each SOAP message has a root <Envelope> element. Within the “envelope” are two parts: a header and a body. The envelope and body are required elements in SOAP messages, while the header is optional. The header contains routing or context data and can be empty. The body, which contains the actual message, can also be empty.

SOAP messages are sent and received by SOAP clients and web services servers. The SOAP client generates and sends SOAP requests to the SOAP server over HTTP. The SOAP server receives these requests and generates the appropriate response over HTTP to the client.

Figure 4.1 Soap architecture

SOAP

Client

_Server

SOAP

Service

SOAP request

SOAP response

(30)

U s i n g t h e T C P M o n i t o r

Some of the web services toolkits provide tools for monitoring the SOAP messages between the client and the server:

• TCP Monitor, a feature of the Axis toolkit

• WebLogic Web Services Home Page, a feature of the WebLogic toolkit

Using the TCP Monitor

This is a feature of the Axis toolkit. Support for the Apache Axis toolkit is not provided with the JBuilder WebLogic Edition

The TCP Monitor, which is available with the Axis toolkit, allows you to monitor the SOAP envelopes as they’re transported between the client and the server. TCP, Transmission Control Protocol, is the most common Internet transport layer protocol. The TCP Monitor actually sits between the SOAP client and server. The client sends its request to the TCP Monitor, which then forwards it on to the server. Responses from the server are in turn sent to the TCP Monitor and then to the client. You can monitor these messages locally to test the service or listen over a

connection.

Figure 4.2 TCP Monitor

The TCP Monitor supports these features: • Adding multiple listener ports

• Editing SOAP messages • Resending SOAP messages

• Viewing a history of requests and responses • Saving requests and responses to a file

(31)

Creating a new TCP/IP Monitor

By default, the TCP monitor sets the client port to 8082 and the server port to 8080.

To create a new port to listen to, complete these steps:

1 Choose Tools|TCP Monitor to open the TCP Monitor.

2 Choose the Admin tab.

3 Enter a port number to listen on, such as 8082 for localhost. This should be a port that won’t be in use by the service.

4 Choose Act As A Listener.

5 Enter the Target Host Name for the destination server that you want to monitor, such as 127.0.0.1 for localhost. If you enter a name instead of an address, such as services.xmethods.net, be sure to remove the protocol from the address (http://).

6 Enter the Target Port Number for the server, such as 8080. This is the destination port that you want to monitor.

7 Click the Add button to add this new TCP/IP Monitor. A new page is added.

8 Choose the new Port tab to monitor the messages.

9 Modify the client to send its messages to and receive its messages from the TCP Monitor on the listen port. Change the address and port number in your code but don’t remove the context and service target in the address. For example, the context and service target in this address "http://localhost:8082/soap/servlet/rpcrouter" is soap/servlet/rpcrouter and should remain unchanged.

(32)

10Rebuild the client to save the changes. 11Run the application on the web server.

12Interact with the web service and view the SOAP requests and responses in the TCP Monitor. You can also make any necessary edits to requests in the TCP Monitor and resend them, as well as save request and response messages to disk in text or XML format.

Monitoring a service’s SOAP messages

Let’s look at a web services sample and monitor the SOAP messages with the TCP Monitor. In this example, you’ll create a web service, modify the client’s URL to point to the port that the TCP Monitor listens on, rebuild the client, run the service test case, and monitor the messages forwarded between the client and the server by the TCP Monitor .

1 Create a web service as described in Chapter 13, “Tutorial: Creating a simple web service with Axis.”

2 Open Bean1ServiceLocator.java in the <project name>.generated package and change the URL for the service port address from the 8080 to 8082. The TCP Monitor is set up by default to listen to messages on port 8082. You want to redirect the client to send the messages to the listening

(33)

U s i n g t h e W e b L o g i c W e b S e r v i c e s H o m e P a g e

3 Choose Tools|TCP Monitor to open the TCP Monitor. Notice that the listen port is set to 8082 and the destination port to 8080. These are the default TCP Monitor settings.

Note You can change the default settings at any time. Choose the Stop button and edit the Listen Port, Host, and Port fields. You can also create a new TCP Monitor on the Admin page.

4 Expand the axis node’s Root Directory, right-click index.html, and choose Web Run Using “Web Services Server” to run the web services server.

5 Right-click the test case, Bean1ServiceTestCase.java, and choose Run Test Using Defaults.

6 Return to the TCP Monitor to see the request and response sent from the client and server to the Monitor.

Using the WebLogic Web Services Home Page

This is a feature of JBuilder Enterprise and the WebLogic toolkit

Every Web service deployed on WebLogic Server has a Home Page. From the Home page you can view the exposed methods, view the SOAP requests and responses, test each operation, view the WSDL that describes the service, and copy example code that invokes the service.

(34)

To open the Home Page for your web service, use the URL for the web service:

<protocol>://<host:port>/<contextURI>/<serviceURI> where:

For example, if you’re running WebLogic on the default port 7001 locally, the WebApp is web-services, and the ServiceUri is Bean1, the address for the web service would be: http://localhost:7001/web-services/Bean1. If you don’t know the ServiceURI, you can find it in the servicegen.wldu file or right-click the Web Service Components node in the WebApp node in the project pane and choose Properties.

<protocol> The protocol for the service, such as http.

<host> The computer running WebLogic Server, such as localhost. <port> The port number where WebLogic Server is listening,

such as localhost:7001.

<contextURI> The context root of the WebApp or the name of the WebApp archive file., such as web-services.

(35)

To open the WSDL for your web service on the Home Page, choose the Service Description link or enter this URL:

<protocol>://<host:port>/<contextURI>/<serviceURI>?WSDL

C h a p t e r

5

Chapter5

Working with WSDL

To write a client application that invokes a web service, developers need information about where the service is located and how to access it. The Web Services Description Language (WSDL) provides this information. A WSDL document, written in XML, describes a web service and how to call it.

A WSDL document exposes the web service’s method signature, protocol to be used, network address, and data format. With the information available in the WSDL document, a programmer can write an application to interface with a web service. By examining a web service’s WSDL document, developers know what methods are available and how to call them using the proper parameters.

To discover other web services and their corresponding WSDL documents and to publish web services, programmers can use the UDDI Business Registry where businesses register their services. JBuilder provides the Web Services Explorer, available on the Tools menu, for discovering and publishing web services. For more information, see Chapter 11,

(38)

W S D L t e r m s

WSDL terms

To better understand the terms used by WSDL documents, see the following table. For in-depth information about WSDL, see the Web Services Description Language 1.1 specification at

http://www.w3.org/TR/wsdl on the World Wide Web Consortium web site.

<?xml version="1.0" ?> <definitions name="urn:GetQuote" targetNamespace="urn:xmltoday-delayed-quotes" xmlns:tns="urn:xmltoday-delayed-quotes" xmlns:xsd="http://www.w3.org/1999/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">  <message name="GetQuoteRequest">

<part name="symbol" type="xsd:string"/> Table 5.1 WSDL terms

Term WSDL element Definition

Endpoint A port. See port.

Message <message name="GetQuoteRequest"> An abstract, typed definition of the data (parameter).

Type <part name="symbol" type="xsd:string"/>

A container for data type definitions, such as XSD, which is an attribute of the <part> element in a message.

Port Type <portType name="GetQuote"> An abstract set of operations supported by one or more endpoints.

Binding <binding name="GetQuoteBinding" type="tns:GetQuote">

A protocol and data format for a particular port type. This is the binding between the WSDL abstract definition and the implementation. SOAP is an example of a binding type. Operation <operation name="getQuote"> An abstract definition of an action

of the service (method). Port <port name="GetQuote"

binding="tns:GetQuoteBinding"> <soap:address

location="http://localhost: 8080/axis/servlet/AxisServlet"/>

An address for a binding and a communication endpoint defined as a combination of a binding and a network address.

Service <service name="GetQuoteService"> A collection of related endpoints (ports).

(39)

W S D L s a m p l e s

<portType name="GetQuote"> <operation name="getQuote"> <input message="tns:GetQuoteRequest"/> <output message="tns:GetQuoteResponse"/> </operation> </portType>

<soap:address location="http://localhost:8080/axis/servlet/AxisServlet"/> </port>

</service> </definitions>

WSDL samples

For sample WSDL documents, see

<jbuilder>/samples/webservices/axis/wsdl. Additional Apache-SOAP WSDL samples are available in <jbuilder>/thirdparty/apache-soap/samples.

C h a p t e r

6

Chapter6

Developing EJBs as

web services

The JBuilder web services features are designed to assist you in building enterprise class web services applications on the J2EE platform. The solutions are standards-based and are portable across application servers. The J2EE platform has evolved over the years and is currently the

platform of choice for enterprise Java development. Enterprise JavaBean (EJB) containers, which provide a solid platform for business logic and enterprise data, in conjunction with web containers, such as servlets and JSPs, have extended the functionality of applications by leveraging the penetration of browsers and HTML.

Web services extend the functionality of the J2EE platform still further in providing cross-platform and language-independent solutions. In addition, the J2EE platform can itself leverage web services built outside of its domain. Web services are not confined to a browser environment and can be embedded just as easily in other applications and in

application servers.

Typically, as is the case with web containers, coarse-grained business methods are the right candidate and appropriate design for exposing functionality. JBuilder makes this effortless by automatically exposing the appropriate methods in the stateless session beans in the project. You can also override this default behavior and select only the EJB modules, beans, and methods that you want to expose as web services. In addition to creating EJB-based web services, JBuilder provides features for quickly implementing existing web services as EJBs.

(42)

D e v e l o p i n g E J B s a s w e b s e r v i c e s

As described in the sections that discuss toolkits, JBuilder automatically exports your EJBs as web services for you. Simply develop your EJB application as usual, configure the project for web services with the Web Services Configuration wizard, and run the project with the Web Services Server run configuration created by the wizard. All stateless session beans with business methods in the remote interface are automatically deployed to the server as web services without any additional steps. Although some application servers may require an additional step to deploy the EAR to the server.

Developing EJBs as web services varies according to the toolkit selected. For more information on EJBs, see Chapter 7, “Using the Apache Axis toolkit,” and Chapter 8, “Using the WebLogic toolkit.”

Important For configuration issues with application servers, see Chapter 10, “Modifying enterprise application server settings for web services,” and the “Release Notes” (Help|Release Notes).

For a list of enterprise application servers that JBuilder supports for the web services features , see “Supported enterprise application servers” on page 2-8.

(43)

C h a p t e r

7

Chapter7

Using the Apache Axis toolkit

This is a feature of JBuilder Enterprise. Support for the Apache Axis toolkit is not provided with the JBuilder WebLogic Edition

Apache Axis is an open source implementation of Simple Object Access Protocol (SOAP), an XML-based protocol for exchanging information. When you choose Apache Axis as the toolkit in a JBuilder web services wizard, the wizard uses Axis to generate a WSDL, Java classes,

deployment files, administration files, and so on, depending on which wizard you’re using.

For example, when the Axis toolkit is selected in the Import A Web Service wizard, the wizard generates Java classes from an existing WSDL document, as well as deployment files. You can then implement these classes to consume the service specified in the WSDL. You can also create server-side classes for a web service. If the Axis toolkit is use in the Export As A Web Service wizard, the wizard generates a WSDL document from an existing Java class and exposes selected methods of the class as a web service.

For more information on the Apache Axis toolkit, see the documentation available in <jbuilder>/thirdparty/xml-axis/java/docs.

Exporting a class as a web service

The Export As A Web Service wizard is used to export a class as a web service. It has options to choose the methods you want to make available to the service. You can use this wizard to export any Java class as a web service; for example, a JavaBean. However, if the class uses non-bean types as parameters or return values, you need to provide serializers and deserializers. The wizard has options to generate the server-side and client-side implementations of the service. It also generates a WSDL, which describes the service, and deployment information for the Axis

(44)

E x p o r t i n g a c l a s s a s a w e b s e r v i c e

Note Exporting a class is different from exporting an EJB. You must explicitly export a Java class with the Export As A Web Service wizard. EJBs, however, are exported automatically if the project is configured for web services with the Web Services Configuration wizard.

If the project isn’t configured for hosting the web service, the Web Services Configuration wizard displays first before the Export As A Web Service wizard displays.

Depending on the settings you select, the Export As A Web Service wizard generates some or all of the following files from the Java class or interface. If you uncheck the Generate Client Stub option, no Java files are

generated; only the WSDL and WSDD are generated. The examples for the file names in the following table are from the AddressBook.wsdl sample in <jbuilder>/samples/webservices/axis/wsdl/AddressBook.wsdl.

Table 7.1 Files generated by the Export As A Web Service wizard

File name Description WSDL element Example

class name[PortType]. wsdl

The WSDL document which describes the web service. service name.java A service interface which defines a get method for each port listed in the service element of the WSDL. This service interface defines a factory class to get a stub instance.

AddressBookService.java

service nameLocator. java

A locator class which is the client-side server implementation of the service interface. <service name= "AddressBookService"> AddressBookServiceLocator.java service nameTestCase. java

An optional JUnit test case for testing the web service.

AddressBookServiceTestCase. java

portType name.java An interface for each portType in the WSDL. You will use the implementation of this interface to call the remote methods.

AddressBookPortType.java

binding nameImpl.java An implementation class for each portType interface. You modify this file to add your implementation. <binding name= "AddressBookSOAPBinding"> AddressBookSOAPBindingImpl.java binding nameSkeleton. java

An optional skeleton class to encapsulate an implementation for the server.

<binding name=

"AddressBookSOAPBinding">

AddressBookSOAPBindingSkeleton. java

(45)

The wizard generates a package name based on the package name of the class with .generated appended to it.

The Export As A Web Service wizard can optionally generate client stub classes. If the Generate Client Stub option is selected on the first page of the wizard, the wizard has additional steps. The additional steps provide the same functionality as the Import A Web Service wizard and generate a client stub from a WSDL document.

The Export As A Web Service wizard is available on the Web Services tab of the object gallery. You can also right-click any .java file in the project pane and select Export As A Web Service from the context menu.

To export a class as a web service and generate Java classes and a WSDL for the service, follow these basic steps:

1 Create a new project (File|New Project).

2 Create a JavaBean (File|New|General|JavaBean), choose java.lang.Object as the base class, and check the Generate Sample Property option.

3 Compile the project (Project|Make Project).

4 Right-click the bean and choose Export As A Web Service to open the Export As A Web Service wizard.

Because the project isn’t configured for web services yet, the Web Services Configuration wizard displays before the Export As A Web Service wizard.

binding nameStub.java An (optional) client-side stub class which acts as a proxy for a remote web service. This allows you to call the web service as if it were a local object. This class implements the class name[PortType].java interface.

<binding name=

"AddressBookSOAPBinding">

AddressBookSOAPBindingStub.java

data types Java files for all other types and holders needed for the web service.

deploy.wsdd An XML file that provides deployment information to the web services server. server-config.wsdd An XML file that provides

deployment information to the server.

Table 7.1 Files generated by the Export As A Web Service wizard (continued)

(46)

5 Create a SOAP implementation with the Axis toolkit to host the web service as described in “Working with the Web Services Configuration wizard” on page 3-1.

Once the project is configured for web services, the Export As A Web Service wizard displays.

6 Continue through the steps of the wizard and choose the desired options and the methods you want to expose as a service in the wizard. For more information on the Export As A Web Service wizard options, choose the Help button in the wizard.