Not to be confused with the topic of this book, a newly proposed standard called the Java web service ( JWS) standard is currently in development. It is spearheaded by BEA Systems, which also has a reference implementation.

The JWS is a format designed to integrate non-Java developers with J2EE. Sounds ambitious, doesn’t it? BEA has actually designed a technology that might work. At the core of the JWS specification is the idea that developers don’t create J2EE components. Rather, developers create a web service, and a single Java class represents web service implementation. The Java class then has a number of simple, predefined JavaDoc tags that indicate different behavioral implementations of the web service. Based on the values of the JavaDoc tags inserted into the Java class, a behind-the-scenes code generator then creates all necessary J2EE components required to implement the web service.

The JWS JavaDoc system has tags representing a full range of web service behaviors, including stateless methods, stateful methods, and asynchronous invocations. The challenge left to JWS implementations is to take the definition of the JavaDoc tags and generate J2EE components that implement this behavior in a reliable and available manner.

The JWS proposal is appealing because tool vendors can support BEA’s prototype implementation quickly. It comes with a nice IDE that ties together design, coding, and testing. The concept of deployment is completely hidden from the developer. The goal is to have a framework for developing web services with J2EE that is similar to working in Visual Basic.

Let’s look at an example. The following listing, HelloWorld.jws , shows all of the code necessary to create a complete web service:

import com.bea.jws.*; 
import com.bea.jws.control.*; 
  
/**
 * A simple web service that returns a string.
 */
public class HelloWorld extends Service 
{ 
    /**
     * @operation
     * @conversation stateless
     */
    public String getHellowWorld(  )
    {
        return "Hello World";
    }
}

That’s it. A JWS file is simply a Java class that implements the Service interface. The methods of the class implement the web service; the JavaDoc extensions tell the behind-the-scenes code generator what type of web service to produce. The methods in the Java class may not be exposed as part of the WSDL of the web service. If the method you create should be part of the external WSDL, then the @operation tag should be placed in the JavaDoc before the method. This tag causes the code generator to create necessary definitions in the WSDL file.

The @conversation tag defines the behavior of this method as part of the web service. The @conversation tag takes a single parameter that can be stateless, start, continue, or finish. The stateless parameter means that this method supports only the request/response paradigm. If the @conversation parameter is start, continue, or finish, then the underlying generated infrastructure is responsible for associating incoming messages with a conversation handler for each client. If the start parameter is used, the infrastructure needs to create a new session when the method is invoked. If the continue parameter is used, the infrastructure needs to determine which existing session this client belongs to and make sure the method invocation occurs in that context. Finally, if the finish parameter is used, the infrastructure executes the method in the appropriate session context and ends the session afterwards.

JWS can be slightly more complicated. JWS has JavaDoc tags for defining different aspects of parameters, methods, and the class itself. These parameters include:

The simplicity of the JWS standard enables a large body of developers to use J2EE, including many who do not have enough experience with Java or J2EE to be successful on their own terms. The number of companies that choose to adopt the standard will certainly factor into the success of JWS. However, this standard doesn’t necessarily have to be adopted by an application server vendor. A JWS code engine must create J2EE-compliant code, so the generated web service can operate in any J2EE-certified application server. Adoption of JWS will probably occur at the tool level and will be driven by whether other tool vendors support the standard or add extensions to it.