WebLogic Platform 7.0 supports the following Web service standards:

Again, this chapter assumes you are already familiar with these standards, their formats, and intended use. However, the format diagram shown in Figure 29.3 and Figure 29.4 serve to clarify the parts of a SOAP message and WSDL document, respectively, and also help define the vocabulary for these chapters. Embedded boxes represent XML subelements of the enclosing XML element. Listing 29.1 shows an actual SOAP message. You can also refer to Listing 29.2 later in this chapter for a fleshed-out WSDL file.

Figure 29.3. The parts of a SOAP message.

Figure 29.4. The parts of a WSDL document. Listing 29.2 later in this chapter shows a fleshed-out WSDL file.

<env:Envelope  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <env:Header>
 </env:Header>
 <env:Body>
  <m:calculateTax    xmlns:m="http://www.bea.com/statelessSession"
    env:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
   <productCategory xsi:type="xsd:int">1959</productCategory>
   <zipCode xsi:type="xsd:string">80516</zipCode>
  </m:calculateTax>
 </env:Body>
</env:Envelope>

For more information on these standards, see the following links:

Web services are no more than windows to applications, be it large or small, simple or complex. It is therefore still critical, and more critical in some ways, for such applications to be scalable, efficient, reliable, and maintainable. Web services are all about real-time, instant, and round-the-clock access to information and applications. WebLogic Server, being a time-tested application server and market leader, is well positioned for the challenge.

Just as important, however, is the fact that the WebLogic Web service technology stack is all based on industry standards, which means Web service clients and servers built on the WebLogic Platform can interoperate with other standard Web service implementations in any programming language or programming model. In addition, version 7.0 now implements JAX-RPC, a standard implementation and deployment model for Java Web services, making your Web service code portable to other JAX-RPC–compliant servers.

Lastly, WebLogic Web services build on industry-standard J2EE components and are packaged as standard J2EE enterprise applications. You can therefore leverage your existing J2EE experience and investment in building world-class Web service offerings. For the non-J2EE developer, WebLogic Workshop provides one of the most advanced, intuitive, and powerful graphical IDEs (Integrated Development Environments) for quickly developing Web services without any server-side programming.

WebLogic Platform 7.0 provides two ways of developing your own locally hosted Web service: through WebLogic Server and through the WebLogic Workshop.

When a Web service executes, it presumes the availability of certain services that it uniquely needs. A Web service runtime environment provides a library of services, both client and server side, such as support for a fixed set of data types, APIs for type mappings (to XML) and extensibility mechanisms, processing of standard service descriptions, and deployment APIs. This concept of a Web service runtime is akin to a standard J2EE container that provides a uniform environment for application components such as Enterprise JavaBeans (EJB) to run, thus enabling portability of EJBs across any J2EE-compliant application server. The JAX-RPC initiative claims to do just that. It aims to replace many proprietary Web service implementations that exist today with an industry standard Web service deployment and execution model, thereby protecting your development investment.

There are two distinct Web service runtime environments in WebLogic Platform: one is for the WebLogic Server (JAX-RPC–based Web service container), and the other is for WebLogic Workshop (KNEX runtime). A Workshop-created Web service can run only in a KNEX runtime, and a WLS-created Web service can run only in a JAX-RPC container. However, both types of Web services can interoperate with each other, as well as be published in the same UDDI registry. No special client code is necessary to invoke WLW Web services; that is, a client is oblivious to what runtime environment the service provider is using. In WebLogic Platform 7.0, the appropriate Web service runtimes will be invoked automatically for you when you start either the WebLogic Workshop or WebLogic Server.

WebLogic Server 7.0 provides new support for hosting your own Web Service Registry, based on the worldwide standard UDDI 2.0. It also features a UDDI browser for both looking up and publishing a service and an implementation of the UDDI API. Publishing your Web service, however, either internally within your enterprise or otherwise, is not required for you to be able to create, deploy, and invoke the Web service. This topic is fully discussed in Chapter 31.

WebLogic Platform 7.0 includes a portal framework called the WebLogic Portal. A portal is a feature-rich Web site. It provides a single point of access to enterprise data and applications, presenting a unified and personalized view of that information to employees, customers, and business partners.

A portal allows you to have multiple Web applications within a single Web interface. In addition to regular Web content that appears in a portal, a portal provides the ability to display portlets in a single Web interface. A portlet is a self-contained application or content that resides within the WebLogic portal framework. WebLogic Portal provides a wizard for configuring a portlet to invoke and consume Web services.

The Portlet Wizard is accessible from inside the E-Business Control Center (EBCC) application of the WebLogic Portal component in WebLogic Platform 7.0. Invoke the EBCC in Windows by choosing Start, Programs, BEA WebLogic Platform 7.0, WebLogic Portal 7.0, E-Business Control Center.

You then must open a project in the EBCC. An example project file is available at

<WL_HOME>weblogic700samplesportalwlcsDomaineaAppswlcsApp-project wlcsApp-project.eaprj

If you don’t already have one, you must first define a portal to which your portlet will be associated. While creating your portlet, specify Web service(s) for the content type, as shown in Figure 29.6.

Figure 29.6. Create a Web service portlet using the EBCC Portlet Wizard.

A convenient wizard feature is the capability to specify the WSDL URL of the Web service to be presented in the portlet, as shown in Figure 29.7.

Figure 29.7. The Portlet Wizard allows you to select the Web service to be included in the portlet, via a WSDL URL.

For more information on the Portlet Wizard, consult the WebLogic Portal EBCC documentation.

The WebLogic Portal component of WebLogic Platform 7.0 includes a sample commerce application representing an online hardware store, complete with an online catalog and shopping cart. During checkout, the sales taxes must be calculated and displayed, and before checkout can be completed, the user’s credit card must be authorized for the purchase amount. These two services, tax and payment, are deployed as Web services. Their Web service home pages, shown in Figure 29.8 and 29.9, were generated automatically by WebLogic Server when its tools were used to generate the Web service.

First, you need to launch the WebLogic Commerce Server, which hosts these two Web services. To do this in Windows, choose Start, Programs, BEA WebLogic Platform 7.0, WebLogic Portal 7.0, Portal Examples, Commerce Templates, Launch Commerce Server.

When the Commerce Server is up and running, you can reach the tax and payment home pages at the following URLs (by default), respectively:

http://localhost:7501/taxws/TaxService

http://localhost:7501/payws/PaymentService

The sample tax Web service that comes deployed with the WebLogic Portal Commerce sample (see Figure 29.8) illustrates how a local or remote Web service can be integrated with an online store. However, because it is a sample, its business logic is inadequate for commercial use. You must customize or integrate with a tax service bureau for production use.

Figure 29.8. The Commerce sample tax Web service home page.

Similar customization and integration requirements also apply to the sample payment Web service shown in Figure 29.9. The WebLogic Server generated both of these Web services automatically.

Figure 29.9. The Commerce sample payment Web service home page.

For now, observe that the generated Web service home page tells you what the service is all about, its publicly available operations or methods, access to its WSDL, and some Web service testing mechanisms. We will discuss Web service home pages in greater detail in the next chapter.

Another sample application called End-to-End highlights how the portal framework can be used to build business-to-business and business-to-consumer portlets. It implements and uses the same sales tax Web service as in the Commerce application. In addition, it implements and uses a unique payment Web service that was built with WebLogic Workshop. The End-to-End sample application can be invoked via

<WL_HOME>/weblogic700/samples/platform/e2eDomain/starteE2E.bat

WebLogic Platform includes a wealth of working sample code that further illustrates the Web service concepts described in these chapters. All Web service samples can be found in

<WL_HOME>weblogic700samplesserversrcexampleswebservices

where <WL_HOME> is the base install directory for WebLogic Platform. Each sample comes equipped with a build.xml file, so invoking ant builds and deploys the sample for you into the examples server, and invoking ant run runs the sample. You can find detailed instructions on how to run the examples at

<WL_HOME>weblogic700samplesserversrcexampleswebservicespackage-summary.html

The following samples are provided (specific sample locations shown in parentheses are relative to the preceding samples home folder):

In addition, two new examples can be found on the Sams Web site, www.samspublishing.com.

The types of Web services essentially differ in the mode of communication employed: synchronous or asynchronous.

Synchronous Web Services

Also known as simple Web services, synchronous Web services implement a call-and-response Remote Procedure Call (RPC) mode of interaction. In this mode, the caller invokes the Web service, and the business logic behind the Web service executes its behavior while the caller waits for the business logic to complete its operation and return a response or result before proceeding. Hence, this is a synchronous mode of communication. When the business logic is complete, the Web service will return the results to the calling program or the Web service’s consumer. During the time that the Web service’s business logic is executing, the Web service’s consumer thread is blocked and cannot do any other work.

For a simple coarse-grained business process, like the tax rate calculation, this type of service may be acceptable. However, for complex business processes like inventory management, EDI processes, or a long-running transaction that may access multiple back-end legacy systems, the blocking time for the Web service’s consumer could be unacceptable. Releasing threads is very important when the consumer is running within a concurrent system where processing threads must be freed quickly to enable high throughput. Figure 29.10 depicts a simple RPC service invocation.

Figure 29.10. A simple RPC Web service invocation.

Asynchronous Web Services

Complex processes require an asynchronous communications mechanism rather than the simple synchronous RPC mechanism currently implemented by most Web service producers. An asynchronous process hands the Web service request to the Web service producer, allowing the Web service client or consumer to continue processing while the Web service producer does its work. The client in this case does not need the result of the service call, not even an error response, to continue. After an appropriate amount of time has passed, the Web service consumer checks back with the Web service producer to see whether the Web service’s response has been completed. If the response is completed, the consumer can retrieve the response and go on with its work. Alternatively, the Web service client can configure itself as a listener or provide callbacks for the service producer to inform the client in real-time when results become available.

Asynchronous Web services, also known as “complex” Web services, are useful in cases where a service, by nature, will take an inordinate amount of time or resources to fulfill. Examples of such services are

• Settling payments

• Obtaining a credit score or rating

• Performing intensive computing tasks

• Responding to data mining requests

Figure 29.11 illustrates an asynchronous Web service using a message-driven bean for executing business logic and JMS (Java Messaging Service) to effect acceptance and delivery of client arguments or data.

Figure 29.11. Asynchronous Web service using a message-driven bean for business logic.

Asynchronous communications provide key advantages that are essential for enterprise-class Web services, including providing higher scalability, utilizing threads more efficiently, and providing users with faster feedback response.

Tip

In WebLogic Platform 7.0, a Web service no longer needs to be exclusively RPC or message-style. For your convenience, a single Web service can now contain both RPC and message-style methods.

A Java class or an EJB can perform the business logic that needs to be executed to fulfill a Web service request. The only EJB types acceptable as Web service back-end components in WebLogic Server are stateless session beans and message-driven beans.

You can secure your Web service in WebLogic Server using the following methods:

Refer to Chapter 30 to see exactly how these security measures are configured into a Web service.

JAX-RPC (Java APIs for XML-based RPC) is a finalized Java specification from Sun Microsystems for standardized Web service invocation, processing, and deployment. JAX-RPC is actually generalized to handle Remote Procedure Call mechanisms employing any protocol or transport, but in the context of this WebLogic Server discussion, we are binding JAX-RPC to the SOAP protocol and the HTTP transport of Web services. The WebLogic Platform Web services implementation is faithfully based on the JAX-RPC 1.0 specification. Therefore, understanding JAX-RPC is essential for the comprehension and effective use of the WebLogic Server Web services features.

Some of the more important elements specified by JAX-RPC are

The specification also imposes rules on XML encodings for SOAP messages, protocol bindings, and transport. Note that JAX-RPC does not alter nor enhance the definition and semantics of WSDL or UDDI.

WebLogic Server 7.0 offers all these JAX-RPC features and more, and has fully passed the JAX-RPC 1.0 Technology Compatibility Kit (TCK) test suite for both Servlet and J2EE Container requirements. Consequently, any client- or server-side Web services code you develop with WebLogic Server can be deployed and run on any JAX-RPC–compliant Web service container, thereby protecting your investment.

When you invoke a Web service using a Java method call, its arguments, which are Java primitives or objects, must be translated into XML constructs for inclusion into a SOAP message. The process of converting a Java object to XML representation is called serialization. Conversely, before a Web service response can be returned to the caller, the SOAP return message containing results in XML format must be translated back to the appropriate Java primitives or objects. This conversion is known as deserialization. These conversions are implemented in the serializer and deserializer Java classes. Figure 29.12 shows where these conversions occur in a Web service use case.

Figure 29.12. The place where Java to XML conversions, and vice versa, occur.

Client proxies provide a higher level abstraction layer that shields the client from underlying tasks such as building the SOAP message, parsing a SOAP response, and performing HTTP protocol activities. We will discuss client proxies in more depth later. As you can see, both the client proxy and the SOAP servlet use serializers and deserializers. The following statements explain Figure 29.12 (the numbers in parentheses correspond to those in the figure):

In essence, call data needs to be in XML (SOAP) format before transporting via HTTP (serialize), and call data needs to be in Java format before it can be used by a client or back-end service (deserialize).

As mentioned earlier, JAX-RPC prescribes rules on Java-to-XML mapping and vice versa, on a definite set of data types, listed in the following section. The WebLogic Server has coded these rules into default serializer and deserializer classes that are automatically and appropriately invoked when any built-in type is used in a Web service method call. However, if your Web service methods use user-defined Java types (UDT or non–built-in types) for parameters and return values, custom serializers and deserializers must be written or generated, and configured via type mappings into your Web service. This effectively extends the WebLogic/JAX-RPC built-in type mapping system. The next chapter explains how to define UDTs and mappings.

Table 29.1 lists the Java types that are supported by WebLogic Server and their mappings to XML.

Use of any of these types in your Web service methods requires no additional consideration or programming to ensure proper translation, interpretation, and delivery via SOAP and WSDL. They are translated between Java and XML automatically.

Because JAX-RPC and WebLogic Server provide such a convenient abstraction for performing all facets of Web services, you normally do not need to nor get to build the SOAP message yourself. Sometimes this feature could become a limitation. If you must influence the SOAP message in some way, JAX-RPC provides the concept of handlers for intercepting SOAP messages (both requests and responses) before they reach their destination. Handlers are Java classes that can be configured for invocation by the Web service container at appropriate junctures. You can do almost anything inside a handler, maybe even fulfill simple Web service requests without invoking a back-end component. Figure 29.13 clarifies where in a Web service call such handlers come into play.

Figure 29.13. How handlers intercept SOAP messages.

Have you noticed that handlers always work with the SOAP message, that is, the XML representation of the request or response as opposed to the Java representation? You develop the Handler class code and then configure it as part of defining a Web service. Details are reserved for the next chapter. For now, you can scrutinize the make-up of a WebLogic Web service in the next section.

Figure 29.14 shows the components that make up an End-to-End synchronous Web service call and fulfillment. Details on how to develop or generate these components will be discussed in the next chapter.

Figure 29.14. The components that make up an End-to-End synchronous Web service call and fulfillment.

Each component plays the following role in the game:

To see what transpires in the WebLogic Web service container, you can expand the server components as shown in Figure 29.15.

Figure 29.15. A look inside the Web service container.

Each of the numbered steps in Figure 29.15 is explained here:

WebLogic Web services even support building a Web service provider that is solely composed of handlers and no back-end component (class or EJB). In this case, the handler alone fulfills the service request. A more realistic scenario is for a handler to cache results of certain popular service requests, with a TTL (Time to Live) on the cache. If the cache is up to date, the handler can just return its contents without invoking the back-end component. When the cache expires or is empty, the back-end component is invoked first, and the results are cached and then returned. This could significantly increase performance and scalability of a Web service.

The client internals are similar to what was described previously for the server. Handlers can be installed on outgoing SOAP requests as well as incoming SOAP results. Client-side handlers can also perform caching, which also will save network overhead.

As you recall from Figure 29.11, an asynchronous service utilizes JMS destinations and message-driven beans to deliver complex business logic to service clients. Such a service provides at least two operations:

Figure 29.16 depicts the component architecture for such a service.

Figure 29.16. The component architecture for an asynchronous Web service.

Processing steps for an asynchronous Web service are as follows:

In practice, for reliability and for avoiding timing issues, another listener needs to be added, and JMS Destination 2 must subscribe to it. The new listener’s sole function is to cache or persist the result. The requestData service can then check this persistent store for results.

You might ask if the JMS destinations should be queues or topics. The rule of thumb is to use a JMS queue if there is only one kind of MDB that can process the request data because the WebLogic EJB container can instantiate as many MDB instances as necessary to handle the load. However, if there are multiple kinds of MDBs, a JMS topic would allow them all to subscribe to it and process data concurrently.

You also might observe that this implementation, as is, does not scale to multiple users. Because the Web service may serve many clients, how does the requestData operation ensure that one client’s result will not inadvertently be delivered to another client? One simple solution is to include with each submitData request some unique client ID, which is also to be included with each requestData call.

A more elegant design would allow this asynchronous Web service to alert the client immediately when his result becomes available, thereby obviating the need for any polling. The WebLogic Workshop Web service IDE can do just that, and is discussed in Chapter 32. For this discussion, it behooves you to contemplate how the client might implement a callback mechanism.

JAX-RPC defines three programmatic client interaction models, which WebLogic Server supports. They are described in the following sections.

Static

The most simple among the client modes, static invocation is best suited for use in situations in which the Web service is known and can be bound at development time. The implication is that there is no requirement to switch to another, albeit similar, Web service at runtime.

JAX-RPC prescribes a pattern for generating service-specific client stubs (which collectively act as the smart proxy shown in Figure 29.12) that are bound into the client at build time. These stubs are essentially abstractions to the service and port elements of the WSDL file:

• ServiceNamePort—. Specifies a client stub representing the WSDL port element, where all operations advertised for that port can be invoked

• ServiceName_Impl—. Represents the WSDL service but also acts as a cabinet for retrieving the above port object

In the static client model, the Smart Proxy box is specifically composed of these stubs, as shown in Figure 29.17. The stubs shown here are for a specific Web service named TaxService.

Figure 29.17. Service-specific stubs in a static client.

WebLogic Server follows this JAX-RPC prescription by providing tools that can take a known Web service description, either described by a provider EJB or an existing WSDL, and generate these stubs. These tools are discussed in detail in Chapter 30. Listing 29.2 shows the service description (WSDL) for an over-simplified sales tax Web service called TaxService. It supports one operation called calculateTax, which takes two string arguments, the Product Category of the item to be taxed and Postal/ZIP Code of the tax jurisdiction, and finally returns the sales tax percentage.

Example 29.2. Tax Web Service WSDL File

<?xml version="1.0" encoding="utf-8"?>

<definitions xmlns:s="http://www.w3.org/2001/XMLSchema"
   xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
   xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
   xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"
   xmlns:tns="http://www.bea.com/servers/samples/examples/webservices/basic"
   xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
   targetNamespace="http://www.bea.com/servers/samples/examples/webservices/basic"
   xmlns="http://schemas.xmlsoap.org/wsdl/">

  <message name="calculateTax">
    <part name="category" xmlns:partns="http://www.w3.org/2001/XMLSchema"
                                type="partns:string" />
    <part name="zip" xmlns:partns="http://www.w3.org/2001/XMLSchema"
                           type="partns:string" />
  </message>

  <message name="calculateTaxResponse" >
    <part name="result" xmlns:partns="http://www.w3.org/2001/XMLSchema"
                              type="partns:string" />
  </message>

  <portType name="TaxServicePort" >
    <operation name="calculateTax"  >
      <input message="tns:calculateTax" />
      <output message="tns:calculateTaxResponse" />
    </operation>
  </portType>

  <binding name="TaxServicePortSoapBinding" type="tns:TaxServicePort" >
    <soap:binding style="rpc"
           transport="http://schemas.xmlsoap.org/soap/http" />
    <operation name="calculateTax" >
      <soap:operation soapAction="" style="rpc" />
      <input>
         <soap:body use="encoded" namespace="http://www.bea.com/servers/
samples/examples/webservices/basic"
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
      </input>
      <output>
         <soap:body use="encoded" namespace="http://www.bea.com/servers/
samples/examples/webservices/basic"
            encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" />
      </output>
    </operation>
  </binding>

  <service name="TaxService" >
    <documentation>todo: add your documentation here</documentation>
    <port name="TaxServicePort"
        binding="tns:TaxServicePortSoapBinding">
      <soap:address location="http://localhost:7001/taxws/TaxService?WSDL"/>
    </port>
  </service>

</definitions>

The client code snippet looks like this:

TaxService_Impl ws = new
    TaxService Impl("http://localhost:7001/taxws/TaxService");

TaxServicePort port = ws.get TaxServicePort();

port.calculateTax("4A", "80302");

Both the TaxService_Impl and TaxServicePort classes can be generated by WebLogic Server. These stubs cannot be used to represent any other Web service except the one whose service description was used to generate them. In other words, the service cannot be changed at execution time; hence, it is considered static.

Dynamic (with WSDL)

The Dynamic client model, also known as the Dynamic Invocation Interface (DII), allows you to invoke a service whose interface types may not be known until runtime. Examples of this situation might be

• If you’re using UDDI to discover and integrate a Web service at runtime

• If static stubs are not available at build time

Although this mode is much more flexible, it is also more complex and likely more difficult to develop, debug, and test. It is recommended that you use this invocation style with caution and only if absolutely necessary.

Figure 29.18 shows the client stack for dynamic service invocation. Here the smart proxy is composed of three more-generic client proxies.

Figure 29.18. Generic stubs in a dynamic client.

In the DII mode, the client proxies are no longer service specific as they are in the static client scenario. Here, you use JAX-RPC–prescribed generic classes for invoking a Web service, which include (all in package javax.xml.rpc):

• Service—. Acts as a generic stub for a Web service and declares the operations or methods that a client may invoke on the service

• ServiceFactory—. Acts as a factory class for creating Service instances

• Call—. Represents a specific operation advertised by a service and is used as a handle for invoking the operation

Again, these classes can be used to invoke any Web service, not just this tax service example.

The steps for dynamic invocation are as follows:

1. Establish a service factory in the Web service runtime.

2. Instantiate a service factory.

3. Indicate which specific port, service, and operation you are trying to invoke. You do so by using references into the WSDL file via the XML qualified name construct, mapped to Java as the QName class.

4. Given the service WSDL and port QName, obtain a Service instance from the service factory.

5. Given the port and operation, obtain a Call instance for the operation to be invoked, from the Service instance.

6. Invoke the operation. You pass in an array whose elements are of type Object. Each object instance represents an argument to the service operation, in the same order as defined in its WSDL. For Web service operations that take primitive Java types, you can still pass in its equivalent wrapper classes in the object array argument. The built-in serializers and deserializers are smart enough, by way of reflection, to divine the appropriate conversions.

The code snippet shown in Listing 29.3 realizes the preceding steps (where appropriate the step number is mentioned in commentary).

Example 29.3. Code Representing the Steps for Dynamic Invocation

// STEP 1: Setup the global JAX-RPC service factory
System.setProperty( "javax.xml.rpc.ServiceFactory",
  "weblogic.webservice.core.rpc.ServiceFactoryImpl");

// STEP 2: create service factory
ServiceFactory factory = ServiceFactory.newInstance();

// STEP 3: define qnames
String targetNamespace = "http://localhost:7001/...";
QName serviceName = new QName(targetNamespace, "TaxService");

QName portName = new QName(targetNamespace, "TaxServicePort");

QName operationName = new QName(targetNamespace,
                                "calculateTax");
URL wsdlLocation =
    new URL("http://localhost:7001/taxws/TaxService?WSDL");

// STEP 4: create service
Service service = factory.createService(wsdlLocation, serviceName);

// STEP 5: create call
Call call = service.createCall(portName, operationName);

// Build args or custom types, if any

// STEP 6: invoke the operation
result = call.invoke( new Object[] {"4A", "80302"} ) ;

// STEP 1: Setup the global JAX-RPC service factory
System.setProperty( "javax.xml.rpc.ServiceFactory",
  "Weblogic.Webservice.core.rpc.ServiceFactoryImpl");

// STEP 2: create service factory
ServiceFactory factory = ServiceFactory.newInstance();

// STEP 3: define qnames
String targetNamespace = "http://localhost:7001/...";
QName serviceName = new QName(targetNamespace, "TaxService");

QName portName = new QName(targetNamespace, "TaxServicePort");

QName operationName = new QName(targetNamespace,
                                "calculateTax");

// STEP 4: create service
Service service = factory.createService(serviceName);

// STEP 5: create call
Call call = service.createCall();

// Build args or custom types, if any

// STEP 6: set port and operation name
call.setPortTypeName( portName );
call.setOperationName( operationName );

// STEP 7: add parameters
call.addParameter( "category", new QName(  "http://www.w3.org/2001/XMLSchema",
                  "string" ), ParameterMode.IN );
call.addParameter( "zip", new QName(  "http://www.w3.org/2001/XMLSchema",
                  "string" ), ParameterMode.IN );
call.setReturnType( new QName("http://www.w3.org/2001/XMLSchema", "string"),
                    String );

// STEP 8: set end point address
call.setTargetEndpointAddress("http://localhost:7501/taxws/TaxService" );

// STEP 9: call service
result = call.invoke( new Object[] {"4A", "80302"} ) ;

Buy (in ticker, inout numOfShares, out sharePrice)

import javax.xml.rpc.holders.*;

public class Main{
  public static void main( String[] args ) throws Exception {

    // Get the Web service
    StockTrader_Impl trader = new StockTrader_Impl(WSDLuri);
    StockTraderPort traderPort = trader.getStockTraderPort();

    // Define the Holder objects for inout and out parameters
    IntHolder numShares = new IntHolder(100);
    FloatHolder sharePrice = new FloatHolder();

    // Invoke the Web service
    traderPort.buy( "BEAS", numShares, sharePrice );

    // Print out values of inout & out parameters
    System.out.println( "I ordered to buy 100 shares of BEAS " +
          "and actually got " + numShares.value + " shares at " +
          sharePrice.value " dollars per share.");
  }
}