Introduction

Java Micro Edition (Java ME) is a platform for running applications on smaller devices such as mobile phones, PDAs etc. These devices have restrictions in terms of Memory and Processing power. Java ME defines various configurations and profiles. Midlets are java applications that operate on Mobile Information Device Profile (MIDP) which is targeted on Mobile phones that has limited memory and processing power. If you are new to Java ME please refer to the articles Introduction to J2ME and J2ME User Interface in Java Beat.

Due to the limitations on the mobile phones, the midlets can’t be exposed as a web service. But the midlets can consume web services. Java ME provides a subset of JAX-RPC APIs to work with web services. This article will provide a step by step procedure to access web services from a midlet.

Invoking web services from a Midlet

To access web services, the Midlet has to make remote calls on the web services. But the Midlets won’t do this directly. A stub has to be created and calls are made via the stub instance. Using wireless toolkit it is made very simple to create stub code. Invocation on web service method is a synchrous process. The parameters for the methods are passes by value instead of pass by references. Similarly the values are returned by web services as pass by value. On the stubs midlets can set some properties like USERNAME_PROPERTY, PASSWORD_PROPERTY (User name and password for authentication), ENDPOINT_ADDRESS_PROPERTY(Address of the endpoint) and SESSION_MAINTAIN_PROPERTY(if true:session will be maintained between endpoint and midlet) using _setProperty method.

1
2

stub._setProperty(Stub.ENDPOINT_ADDRESS_PROPERTY,serviceUrl);
	stub._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, new Boolean(true));

The generated stub code and the supportive classes have to be bundled in the jar file along with the midlet. While accessing web services the best practice is to write the sub invocation code in a seperate thread. This will avoid your application hanging as your thread will be blocked during web service invocation.

Example

This example will help you in understanding how to access web service from a midlet. Netbeans IDE, Glassfish application server and Wireless tool kit 2.5.2 are used.

Create the web service and deploy it in the application server

Web service:

1
2
3
4
5
6
7
8
9
10
11
12

package mypack;
	import javax.jws.WebMethod;
	import javax.jws.WebParam;
	import javax.jws.WebService;
	@WebService()
	public class HelloService {
		@WebMethod(operationName = "getMessage")
		public String getMessage(@WebParam(name = "name")
		String name) {
			return "Hi "+name+"! Welcome to JME Programming";
		}
	}

WSDL URL:

http://localhost:17754/HelloWebService/HelloServiceService?WSDL

Create a Midlet with a form with a text field and command buttons.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

public class Midlet extends MIDlet implements CommandListener{
		private Form myform;
		private TextField field;
		private Command exit,getMessage;
		private Display d;
		public void startApp() {
			d=Display.getDisplay(this);
			myform=new Form("Access Webservice");
			field=new TextField("Name", "", 20, TextField.PLAIN);
			exit=new Command("Exit", Command.EXIT, 0);
			getMessage=new Command("GetMsg", Command.SCREEN, 1);
			myform.append(field);
			myform.addCommand(exit);
			myform.addCommand(getMessage);
			myform.setCommandListener(this);
			d.setCurrent(myform);
		}
		public void pauseApp() {
		}
		public void destroyApp(boolean unconditional) {
		}
		public void commandAction(Command c, Displayable d) {
			if(c==exit){
				notifyDestroyed();
			}else if(c==getMessage){
				//Code to Access Webservice
			}
		}
	}

Use Wireless tool kit tool to create the stub

a) Open Wireless Toolkit

(b) Select File -> Utilities

Access Web service

For accessing web service,

1. Create a new thread.
2. In the new thread, Instantiate the stub
3. Set properties on the stub if required
4. Invoke the web service methods on the stub

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

//Extend the code written earlier
	import mypack.HelloService_Stub;
	public class Midlet extends MIDlet implements CommandListener{
		private Form myform;
		private TextField field;
		private Command exit,getMessage;
		private Display d;
		public TextField getField() {
			return field;
		}
		public Form getMyform() {
			return myform;
		}
		....
		public void commandAction(Command c, Displayable d) {
			if(c==exit){
				notifyDestroyed();
			}else if(c==getMessage){
				Thread t=new Thread(new NewThread(this));
				t.start();
			}
		}
	}	
	class NewThread implements Runnable{
		Midlet m;
		NewThread(Midlet m){
			this.m=m;
		}
		public void run() {
			Form frm=m.getMyform();
			TextField txt=m.getField();
			HelloService_Stub stub=new HelloService_Stub();
			String msg="";
			try {
				msg = stub.getMessage(txt.getString());
				frm.append(msg);
			} catch (RemoteException ex) {
				frm.append(ex.getMessage());
			}
		}
	}

Run the Midlet

Run the midlet. Provide the Name and select the command button GetMsg. The following output will be displayed.

Conclusion

Java ME Midlets can act only as the consumer for web services. It can’t be exposed as a web service. Wireless Tool Kit helps in creating stubs for web services. Midlets by invoking methods on the stub invokes methods on web services. Both simple types and complex types can be passed as parameters to the web services.

1
2
3
4
5
6
7
8
9
10

It should be noted here that we have hot deployment and hot update
	support for the service; in other words, you can add a service when the
	system is up and running. However, unfortunately, we cannot deploy
	new modules when the system is running. You can still deploy modules,
	but Axis2 will not make the changes to the runtime system (we can drop
	them into the directory but Axis2 will not recognize that), so we will
	not use hot deployment or hot update. The main reason behind this is
	that unlike services, modules tend to change the system configurations,
	so performing system changes at the runtime to an enterprise-level
	application cannot be considered a good thing at all.

1
2
3
4
5

As mentioned earlier, changing the handler chain or any global
	configuration at the runtime cannot be considered a good habit. This is
	because in a production environment, changing runtime data may affect
	the whole system. However, at the deployment and testing time this
	comes in handy.

Module configuration file (module.xml)

As we have already discussed, the module archive file is a self-contained and
self-described file. In other words, it has to have all the configuration required to
be a valid and useful module. Needless to say, that is the beauty of a self-contained
package. The Module configuration file or module.xml file is the configuration file
that Axis2 can understand to do the necessary work.

A simple module.xml file has one or more handlers. In contrast, when it comes to
complex modules, we can have some other configurations (for example, WS policies,
phase rules) in a module.xml. First, let’s look at the available types of configurations
in a module.xml. For our analysis, we will use a module.xml of a module that counts
all the incoming and outgoing messages. We will be discussing all the important
items in detail and provide a brief description for the other items:

• Handlers alone with phase rules
• Parameters
• Description about module
• Module implementation class
• WS-Policy
• End points

Handlers and phase rules

As we discussed, a module is a collection of handlers, so a module could have one
or more handlers. Irrespective of the number of handlers in a module, module.
xml provides a convenient way to specify handlers. Most importantly, module.
xml can be used to provide enough configuration options to add a handler into the
system and specify the exact location where the module author would like to see the
handler running. In Chapter 4, Execution Chain, we learnt more about phase rules as
a mechanism to tell Axis2 to put handlers into a particular location in the execution
chain, so now it is time to look at them with an example.

Before learning how to write phase rules and specifying handlers in a module.xml,
let’s look at how to write a handler. There are two ways to write a handler in Axis2:

• Implement the org.apache.axis2.engine.Handler interface
• Extend the org.apache.axis2.handlers.AbstractHandler abstract class

In this chapter, we are going to write a simple application to provide a better
understanding of the module. Furthermore, to make the sample application easier,
we are going to ignore some of the difficulties of the Handler API. In our approach,
we will extend the AbstractHandler. When we extend the abstract class, we only
need to implement one method called invoke. So the following sample code will
illustrate how to implement the invoke method:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class IncomingCounterHandler extends AbstractHandler implements
	CounterConstants {
		public InvocationResponse invoke(MessageContext messageContext) throws
		AxisFault {
			//get the counter property from the configuration context
			ConfigurationContext configurationContext = messageContext.
				getConfigurationContext();
			Integer count =
				(Integer) configurationContext.getProperty(INCOMING_
				MESSAGE_COUNT_KEY);
			//increment the counter
			count = Integer.valueOf(count.intValue() + 1 + «»);
			//set the new count back to the configuration context
			configurationContext.setProperty(INCOMING_MESSAGE_COUNT_KEY,
				count);
			//print it out
			System.out.println(«The incoming message count is now « +
				count);
			return InvocationResponse.CONTINUE;
		}
	}

As we can see, the method takes MessageContext as a method parameter and returns InvocationResponse as the response. You can implement the method as follows:

1. First get the configurationContext from the messageContext.
2. Get the property value specified by the property name.
3. Then increase the value by one.
4. Next set it back to configurationContext.
5. In general, inside the invoke method, as a module author, you have to do
   all the logic processing, and depending on the result you get, we can decide
   whether you let AxisEngine continue, suspend, or abort. Depending on your
   decision, you can return to one of the three following allowed return types:
• InvocationResponse.CONTINUEGive the signal to continue the message
• InvocationResponse.SUSPENDThe message cannot continue as some of the conditions are not
  satisfied yet, so you need to pause the execution and wait.
• InvocationResponse.ABORTSomething has gone wrong, therefore you need to drop the message
  and let the initiator know about it
6. The message cannot continue as some of the conditions are not satisfied yet,
   so you need to pause the execution and wait.
7. InvocationResponse.ABORT.
8. Something has gone wrong, therefore you need to drop the message and let
   the initiator know about it.

The corresponding CounterConstants class a just a collection of constants and will
look as follows:

1
2
3
4
5

public interface CounterConstants {
		String INCOMING_MESSAGE_COUNT_KEY = "incoming-message-count";
		String OUTGOING_MESSAGE_COUNT_KEY = "outgoing-message-count";
		String COUNT_FILE_NAME_PREFIX = "count_record";
	}

As we already mentioned, the sample module we are going to implement is for counting the number of request coming into the system and the number of messages
going out from the system. So far, we have only written the incoming message counter and we need to write the outgoing message counter as well, and the implementation of the out message count hander will look like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

public class OutgoingCounterHandler extends AbstractHandler implements
	CounterConstants {
		public InvocationResponse invoke(MessageContext messageContext)
		throws AxisFault {
			//get the counter property from the configuration context
			ConfigurationContext configurationContext = messageContext.
				getConfigurationContext();
			Integer count =
				(Integer) configurationContext.getProperty(OUTGOING_
				MESSAGE_COUNT_KEY);
			//increment the counter
			count = Integer.valueOf(count.intValue() + 1 + «»);
			//set it back to the configuration
			configurationContext.setProperty(OUTGOING_MESSAGE_COUNT_KEY,
				count);
			//print it out
			System.out.println(«The outgoing message count is now « +
				count);
			return InvocationResponse.CONTINUE;
		}
	}

The implementation logic will be exactly the same as the incoming handler processing, except for the property name used in two places.

Module implementation class

When we work with enterprise-level applications, it is obvious that we have to initialize various settings such as database connections, thread pools, reading property, and so on. Therefore, you should have a place to put that logic in your module. We know that handlers run only when a request comes into the system but not at the system initialization time. The module implementation class provides a way to achieve system initialization logic as well as system shutdown time processing. As we mentioned earlier, module implementation class is optional. A
very good example of a module that does not have a module implementation class is the Axis2 addressing module. However, to understand the concept clearly in our example application, we will implement a module implementation class, as shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65

public class CounterModule implements Module, CounterConstants {
		private static final String COUNTS_COMMENT = "Counts";
		private static final String TIMESTAMP_FORMAT = "yyMMddHHmmss";
		private static final String FILE_SUFFIX = ".properties";
		public void init(ConfigurationContext configurationContext,
		AxisModule axisModule) throws AxisFault {
			//initialize our counters
			System.out.println("inside the init : module");
			initCounter(configurationContext, INCOMING_MESSAGE_COUNT_KEY);
			initCounter(configurationContext, OUTGOING_MESSAGE_COUNT_KEY);
		}
		private void initCounter(ConfigurationContext
			configurationContext,
			String key) {
			Integer count = (Integer) configurationContext.
				getProperty(key);
			if (count == null) {
				configurationContext.setProperty(key, Integer.
					valueOf("0"));
			}
		}
		public void engageNotify(AxisDescription axisDescription) throws
			AxisFault {
			System.out.println("inside the engageNotify " +
				axisDescription);
		}
		public boolean canSupportAssertion(Assertion assertion) {
			//returns whether policy assertions can be supported
			return false;
		}
		public void applyPolicy(Policy policy,
			AxisDescription axisDescription) throws
			AxisFault {
			// Configuure using the passed in policy!
		}
		public void shutdown(ConfigurationContext configurationContext)
			throws AxisFault {
			//do cleanup - in this case we'll write the values of the
			counters to a file
			try {
				SimpleDateFormat format = new SimpleDateFormat(TIMESTAMP_
					FORMAT);
				File countFile = new File(COUNT_FILE_NAME_PREFIX + format.
					format(new Date()) + FILE_SUFFIX);
				if (!countFile.exists()) {
					countFile.createNewFile();
				}
				Properties props = new Properties();
				props.setProperty(INCOMING_MESSAGE_COUNT_KEY,
					configurationContext.getProperty(INCOMING_MESSAGE_
					COUNT_KEY).toString());
				props.setProperty(OUTGOING_MESSAGE_COUNT_KEY,
					configurationContext.getProperty(OUTGOING_MESSAGE_
				COUNT_KEY).toString());
				//write to a file
				props.store(new FileOutputStream(countFile), COUNTS_
					COMMENT);
			} catch (IOException e) {
				//if we have exceptions we'll just print a message and let
				it go
				System.out.println("Saving counts failed! Error is " +
					e.getMessage());
			}
		}
	}

As we can see, there are a number of methods in the previous module implementation class. However, notably not all of them are in the module interface.
The module interface has only the following methods, but here we have some other
methods for supporting our counter module-related stuff:

• init
• engageNotify
• applyPolicy
• shutdown

At the system startup time, the init method will be called, and at that time, the module can perform various initialization tasks. In our sample module, we have initialized both in-counter and out-counter.

When we engage this particular module to the whole system, to a service, or to an
operation, the engagNotify method will be called. At that time, a module can decide whether the module can allow this engagement or not; say for an example, we try to engage the security module to a service, and at that time, the module finds out that there is a confl ict in the encryption algorithm. In this case, the module will not be able to engage and the module throws an exception and Axis2 will not engage the module. In this example, we will do nothing inside the engageNotify method.

As you might already know, WS-policy is one of the key standards and plays a major
role in the web service configuration. When you engage a particular module to a service, the module policy should be applied to the service and should be visible when we view the WSDL of that service. So the applyPolicy method sets the module policy to corresponding services or operations when we engage the module.
In this particular example, we do not have any policy associated with the module, so
we do not need to worry about this method as well.

As we discussed in the init method, the method shutdown will be called when the system has to shut down. So if we want to do any kind of processing at that time, we can add this logic into that particular method. In our example, for demonstration
purposes, we have added code to store the counter values in a file.

Webservices Articles & Books

• Webservices Articles
• Webservices Books
• Accessing Web Services from JSF applications
• Creating Webservice using JBoss and Eclipse Europa
• jUDDI and Configuration in jBoss and MySQL database

2. In Server and Settings select the server that you want to use. Here we are going to use GlassFish.

3. Click Next and Finish.

Now its time to create web service form Java class

Creating Web Service project in NetBeans 6.1

• Select the project you created and right click on the project node.
• Choose New > Web Service.

• A New Web service dialog window will open. Give the web service name as “Adder”, give the package name as “ws”. Make sure Create web service from scrach option is selected. Click on finish.

• Web Services node will get created in projects window. Web Services node will contain a Adder node indicating the new web service we created just now. In the editor window area visual designer will open up as shown below.

• Click Add Operation in the visual designer. A dialog box appears where you can define the new operation. In the dialog box enter the name of the service as “Add2Numbers” set the return type to “int”, then add two parameters. name the parameters as “number1″ and “number2″ select the type of both the parameters as “int”. Then click on OK

• The designer now displays the following:

• Now see the source genarated by the IDE by clicking on source tab in the visual designer. The IDE will generate the following source for you.

package ws;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;

/**
*
* @author Sri hari
*/
@WebService()
public class Adder {

/**
 * Web service operation
 */
@WebMethod(operationName = "Add2Numbers")
public int Add2Numbers(@WebParam(name = "number1")
int number1, @WebParam(name = "number2")
int number2) {
	//TODO write your implementation code here:
	return 0;
}

}

• Now change the Add2Numbers method like the following, So that our operation will simply add two numbers and return the result.

/**
 * Web service operation
 */
@WebMethod(operationName = "Add2Numbers")
public int Add2Numbers(@WebParam(name = "number1")
int number1, @WebParam(name = "number2")
int number2) {
	return number1 + number2;
}

• Now we successfully developed a web service wich will add two numbers.

Web Service Deployment in NetBeans 6.1

Now we will deploy the web service like below:

• Right click the project node and select Undeploy and Deploy.
• Once you do that IDE will start the server (GlassFish) and deploys the application to the server.

Web Service Testing in NetBeans 6.1

Now its time to test the web service.

In the IDE’s Projects tab, expand the Web Services node of the project. Right-click the services node, and choose Test Web Service. (Applicable only when deployed using GlassFish). AdderService Web Service Tester page shown below will open in the browser.

Enter the integer values in the textbox of the test page and click on add2Numbers button. This will lead to the result page as shown below.

Summary

In this article you have learnt how to develop a web service using Netbeans 6.1 and deploy the service in GlassFish application server. This article doesnot cover the creation of stubs using Netbeans 6.1 IDE. There are many ways to create stubs to test the web service. So keep learning. This is not the end, Still miles to go.

In this technical article, let us see how it is possible to access Web Services from JSF Applications. JSF Application resides in the Web Tier of a typical Enterprise Application, whereas Web Services are External Services that reside in the Application Tier. We make use of Java EE 5 for developing the Sample Application in the final section of this article. It is assumed that readers have sufficient knowledge of JSF and Web Services before continuing this article. They also can have a glance over the introductory JavaBeat article on Java Server Faces before proceeding with this.

2) Web Services

2.1) Introduction

Web Services have been there in the software market over a decade of years and they are gaining more popularity in the recent years. Web Services provide an integration layer between two heterogeneous Applications. With Web Services, it is now possible to access a Java Application that is running in some remote machine with the client being any of the compliant languages like C, C++ or C#. This ensures that Web Services promote language interoperability. It is not necessary that both the Server and Client Application must be running in the same platform, thereby making it platform independent. Web Services alone is not a standard, instead it is a combination of several standards like SOAP, WSDL etc.

also read:

• Introduction to Java Server Faces
• Request Processing Lifecycle phases in JSF
• Accessing Web Services from JSF applications
• Navigation model in JSF

2.2) SOAP

SOAP stands for Simple Object Access Protocol and this is used in Web Services for transmitting messages between the Client and the Server. Technically, a SOAP message is in Xml format that conforms to a well defined schema. It means that a Client Application will construct its request in a SOAP message and send the message to the Server. The Server after unpacking the SOAP message will analyze the type of request and will return a suitable response in the form of a SOAP message.

Given below is a sample illustrating the structure of a Sample SOAP message,

soap.xml

<Soap:Envelope
xmlns:Soap="http://schemas.xmlsoap.org/soap/envelope/">

    <Soap:Header>
        ...
    </Soap:Header>

    <Soap:Header>
        ...
    </Soap:Header>

    <Soap:Body xmlns:MyData="http://mydata.com">
    </Soap:Body>

</Soap:Envelope>

The SOAP message has an outer core called the SOAP Envelope followed by optional SOAP Headers. Following the SOAP Headers is the SOAP Body which will contain the Application that needs to be processed.

2.3) WSDL

WSDL stands for Web Service Description Language and this is the Client facing interface for accessing the Web Service. A typical WSDL file, which is also in Xml format, will list down all the possible Web Service that can be accessed over the Internet. Not only it will list down all the Web Services, but also the various supported operations that a particular Web Service will support.

3) Using Web Services in JSF Application

3.1) Introduction

In this section, let us develop a Simple Hello Web Service that can be accessed by a JSF Application. As we are aware that in a JSF Application, the business processing is usually done by the Managed Beans. It is also possible that a Managed Bean can delegate its functionality to an External Service like an Enterprise Bean or a Web Service.

3.2) Coding the Hello Web Service

HelloWebService.java

package hello;

import javax.jws.HandlerChain;
import javax.jws.WebMethod;
import javax.jws.WebService;

@WebService()
@HandlerChain(file = "HelloWebService_handler.xml")
public class HelloWebService
{
    @WebMethod
    public String sayHello()
    {
        return "Hello";
    }
}

The above code defines a Hello Web Service by name 'HelloWebService'. Since the Application is developed using J2EE 5.0 standard, we have taken the full utilization of Annotation for annotating our declarations. Let us get into the details now. To qualify an implementation class as a Web Service we have simply used the Annotation 'WebService'. That is all which is needed for the Application Server to treat this class as a Web Service. Let us look into the Handler Chain in the next section. To qualify an operation as a Web Service operation, we have to use the Annotation 'WebMethod'.

3.2) Handler Chains

It is possible to attach any number of Handler Chains for a Web Service. To say in simple words, a Handler Chain defines the sequence of steps that used to happen when the request from the Client (in the form of SOAP message), after passing through the various nodes, goes to the ultimate Server for getting processed. Since a Handler Chain is not dependent of the type of the protocol used, we can define a handler Chain for any protocol. Just to make use of the Handler Chain in this Application, we have defined Custom Handler Chain and have referenced the same in the Hello Web Service with the help of HandlerChain Annotation.

Given below is the declaration of a Simple Standard Chain,

HelloMH.java

package hello;

import java.util.Collections;
import java.util.Set;
import javax.xml.namespace.QName;
import javax.xml.soap.SOAPMessage;
import javax.xml.ws.handler.MessageContext;
import javax.xml.ws.handler.soap.SOAPHandler;
import javax.xml.ws.handler.soap.SOAPMessageContext;

public class HelloMH implements SOAPHandler<SOAPMessageContext>
{
    public boolean handleMessage(SOAPMessageContext messageContext)
    {
        SOAPMessage msg = messageContext.getMessage();
        return true;
    }

    public Set<QName> getHeaders()
    {
        return Collections.EMPTY_SET;
    }

    public boolean handleFault(SOAPMessageContext messageContext)
    {
        return true;
    }

    public void close(MessageContext context)
    {
    }
}

The definition of the Handler Chain is defined in the following Xml file and this Xml file is referenced in the HandlerChain Annotation while defining the Web Service.

HelloWebService_handler.xml

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

    <handler-chains xmlns="http://java.sun.com/xml/ns/javaee">
        <handler-chain>
            <handler>
            <handler-name>hello.HelloMH</handler-name>
            <handler-class>hello.HelloMH</handler-class>
        </handler>
    </handler-chain>

</handler-chains>

3.3) Hello WSDL File

As mentioned earlier, a WSDL contains the definitions for various Web Services along with its supported operation. Precisely, all the request and the response data from the Client and the Server will be modeled as messages in the WSDL file. A port type is a WSDL file which defines a set of operations along with the input and the output messages that they will take. Having defined about the various operations along with its messages, how they are bound with a specific protocol is defined by the 'binding' element. Finally the 'service' element along with its 'port' and the 'address' elements will define the ports that are accessible by the clients and the URL through which these Web Services can be invoked.

The following code snippet is the definition of the Hello WSDL file,

HelloWebServiceService.wsdl

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

<definitions xmlns="http://schemas.xmlsoap.org/wsdl/"
        xmlns:tns="http://hello/"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
        targetNamespace="http://hello/" name="HelloWebServiceService">

<types>
    <xsd:schema>
    <xsd:import namespace="http://hello/"
           schemaLocation="HelloWebServiceService_schema.xsd"
           xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
           xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"/>
    </xsd:schema>
</types>

<message name="sayHello">
    <part name="parameters" element="tns:sayHello"/>
</message>
<message name="sayHelloResponse">
    <part name="parameters" element="tns:sayHelloResponse"/>
</message>

<portType name="HelloWebService">
    <operation name="sayHello">
        <input message="tns:sayHello"/>
        <output message="tns:sayHelloResponse"/>
    </operation>
</portType>

<binding name="HelloWebServicePortBinding" type="tns:HelloWebService">
    <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document"/>
        <operation name="sayHello">
            <soap:operation soapAction=""/>
            <input>
                <soap:body use="literal"/>
            </input>
            <output>
                <soap:body use="literal"/>
            </output>
        </operation>
</binding>

<service name="HelloWebServiceService">
    <port name="HelloWebServicePort"
          binding="tns:HelloWebServicePortBinding">
        <soap:address
          location="http://indpd218:8080/HelloWS/HelloWebServiceService"
       xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
        xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"/>
    </port>
</service>

</definitions>

3.4) JSF Managed Bean

HelloManagedBean.java

package hello;
public class HelloManagedBean {

    public HelloManagedBean()
    {
    }

    public void callWebService()
    {
        try
        {
            hello.client.HelloWebServiceService service =
                new hello.client.HelloWebServiceService();
            hello.client.HelloWebService port =
                service.getHelloWebServicePort();

            java.lang.String result = port.sayHello();
            System.out.println("Result = "+result);
        }
        catch (Exception e)
        {
            e.printStackTrace();
        }
    }
}

A JSF Managed Bean will be triggered whenever an Event happens in the Client side like the Click of a Button, or hyperlink etc. So, invoking the business logic defined for the Web Service in this place will be more ideal. In the above Managed Bean, we have defined a method called callWebService() within which we have coded the logic for accessing the Web Service. Note the usage of the classes HelloWebServiceService and HelloWebService. The classes (or Web Service skeletons) will be generated by a standard IDE (like NetBeans) when given with a WSDL file.

3.5) JSF Configuration File

The following is the definition of the HelloManagedBean that we saw just now. We have given an identifier called 'helloManagedBean' through the attribute 'managed-bean-name' element. Note that the 'managed-bean-class' element should point to the fully qualified name of the Managed Bean.

faces-config.xml

<?xml version='1.0' encoding='UTF-8'?>

<faces-config version="1.2"
xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee

http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">

<managed-bean>
    <managed-bean-name>helloManagedBean</managed-bean-name>
    <managed-bean-class>hello.HelloManagedBean</managed-bean-class>
    <managed-bean-scope>request</managed-bean-scope>
</managed-bean>

</faces-config>

3.6) Accessing the Web Service

index.jsp

<%@page contentType="text/html"%>
<%@page pageEncoding="UTF-8"%>

<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">

<html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Accessing Web Services from JavaServer Faces</title>
</head>

	<body>
	<f:view>
	<h1>
	<h:outputText
        value="Accessing Web Services from JavaServer Faces" />
	</h1>

	<h:commandButton value = "Invoke Web Service"
		action = "#{helloManagedBean.callWebService}">
	</h:commandButton>

	</f:view>
	</body>

</html>

Since we have wrapped the Hello Web Service within the Managed Bean declaration, invoking the Web Service becomes as easy as defining the JSF Method Expression. In the above code snippet, we have defined a Command Button and the value of the ‘action’ attribute is pointing to ‘#{helloManagedBean.callWebService}’

4) Conclusion

This article had guided in using External Services like Web Services from JSF Applications. It initially went through Web Services explaining the various standards related to Web Services like SOAP and WSDL. Then the later half of the article showed the steps involved in integration Web Services in a JSF Application.

• JBoss Application Server 4.0.5.GA. == http://labs.jboss.com/
• Eclipse Europa (WTP all in one pack)== http://eclipse.org
• JDK 1.5.x == http://java.sun.com

Defining JBoss server in Eclipse

First thing what you have to do is to define JBoss server in Eclipse. The steps below will explain how to define JBoss server in Eclipse.

• Step 1 : Open Eclipse WTP all in one pack in a new work space.
• Step 2 : Change the perspective to J2EE Perspective if it is not currently in J2EE Perspective.
• Step 3 : Once the Perspective is changed to J2EE, you can see a tab called Servers in the bottom right panel along with Problems, Tasks, Properties.
• Step 4 : If the Servers tab is not found. Go to Eclipse menu : Windows > Show view and click on Servers, so that Server tab will be displayed.
• Step 5 : Go to Servers tab window and right click the mouse. You will get a pop up menu called “New”.
• Step 6 : Clicking on the New menu you will get one more pop up called “Server”. Click on it.
• Step 7 : Now you will get Define New Server Wizard.
• Step 8 : In the wizard there are options to define many servers. One among them is JBoss. Click on JBoss and Expand the tree.
• Step 9 : Select JBoss v 4.0 and click next.
• Step 10 : Now give the JDK directory and JBoss home directory. Click Next.
• Step 11 : Now the wizard will show you the default Address, port, etc., Leave it as it is and click on Next.
• Step 12 : Click on finish.
• Step 13 : Now you can see the JBoss server listed in the Servers window and the status is Stopped.
• Step 14 : JBoss server is now defined in Eclipse now and its ready to use from with in Eclipse IDE.

Creating a Dynamic Web Application Project

Now it is time to create a web application in order to Expose a method as a Web service.

Create a Dynamic Web Application Project in eclipse by selecting the JBoss server what we have defined in the Eclipse IDE as the default server for the project. (We assume that who ever is reading this article knows how to create a dynamic web application in Eclipse, So that part is not detailed out here).

Once the JBoss server is selected as the server for the web applications. All the libraries existing in JBoss will be selected and used by eclipse in the Build Path. So no need to add any extra jar files for our work.

Now we will start with a Java code:

This is a simple Java code and does not have any thing to do with Webservices.

JBossWs Code sample without annotations: (TestWs.java)

Our Java code will have a single method called “greet”. Its functionality will be just to accept a string and return the same prefixed with “Hello”.

package com.test.dhanago;

public class TestWs
{
   /**
    * This method will accept a string and prefix with Hello.
    *
    * @param name
    * @return
    */
   public String greet( String name )
   {
      return "Hello" + name;
   }
}

We will add annotations to the above code and modify the code like below:

JBossWs Code sample with annotations: (TestWs.java)

package com.test.dhanago;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;

/**
 * This is a webservice class exposing a method called greet which takes a
 * input parameter and greets the parameter with hello.
 *
 * @author dhanago
 */

/*
 * @WebService indicates that this is webservice interface and the name
 * indicates the webservice name.
 */
@WebService(name = "TestWs")
/*
 * @SOAPBinding indicates binding information of soap messages. Here we have
 * document-literal style of webservice and the parameter style is wrapped.
 */
@SOAPBinding
   (
         style = SOAPBinding.Style.DOCUMENT,
         use = SOAPBinding.Use.LITERAL,
         parameterStyle = SOAPBinding.ParameterStyle.WRAPPED
    )
public class TestWs
{
   /**
    * This method takes a input parameter and appends "Hello" to it and
    * returns the same.
    *
    * @param name
    * @return
    */
   @WebMethod
   public String greet( @WebParam(name = "name")
   String name )
   {
      return "Hello" + name;
   }

}

JBossWs annotations Walk Through

@WebService(name = "TestWs")

Here, @WebService Indicates that this is a webservice class. name = “TestWs” Indicates the webservice name.

@SOAPBinding
   (
         style = SOAPBinding.Style.DOCUMENT,
         use = SOAPBinding.Use.LITERAL,
         parameterStyle = SOAPBinding.ParameterStyle.WRAPPED
    )

Here, @SOAPBinding Indicates binding information of soap messages. The properties below them indicates the style of web service, Here it is document-literal style. And parameter style is Wrapped.

Here, @WebMethod Indicates this is a method exposed as web service. @WebParam Indicates the parameter name to be used in soap message.

JBossWs Deployment Descriptor

Once the code is ready and compiled. You have modify the web.xml file located in WEB-INF folder.

Modify the web.xml file like below. (web.xml)

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
    id="WebApp_ID" version="2.5">
    <display-name>TestWS</display-name>
    <servlet>
        <servlet-name>TestWs</servlet-name>
        <servlet-class>com.test.dhanago.TestWs</servlet-class>
        <load-on-startup>1</load-on-startup>
    </servlet>
    <servlet-mapping>
        <servlet-name>TestWs</servlet-name>
        <url-pattern>/TestWs</url-pattern>
    </servlet-mapping>
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
    <welcome-file-list>
        <welcome-file>index.html</welcome-file>
        <welcome-file>index.htm</welcome-file>
        <welcome-file>index.jsp</welcome-file>
        <welcome-file>default.html</welcome-file>
        <welcome-file>default.htm</welcome-file>
        <welcome-file>default.jsp</welcome-file>
    </welcome-file-list>
</web-app>

Deploying the JBoss web service application

Once this is done, its time to build and deploy the application in JBoss Application server.
Once every thing is compiled with out any errors. And if you have enabled the Auto build unctionality of the Eclipse IDE, You have already done with building the application. If the auto build functionality of eclipse is not enabled, then right click on the project and build the project using build option.

Go to Servers window and right click on the JBoss server listed over there and select Run.
Wait for server to start. Once it starts, right click on the server listing. You can find a option called “Add and Remove Project”. Click on the option. You will get a wizard where you can select your projects to move to right and configure with server. Once you moved your project. Click on finish.

Once it is done, you can find that the project is again build and moved to server default deployment folder automatically.

Console will display you like below.

Buildfile: D:\ec2\eclipse\plugins\org.eclipse.jst.server.generic.jboss_1.5.102.v20070608\buildfiles\jboss323.xml
deploy.j2ee.web:
      [jar] Building jar: D:\validation\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\Tws.war
     [move] Moving 1 file to D:\MyBoss\jboss-4.0.5.GA_ws121\server\default\deploy
BUILD SUCCESSFUL
Total time: 10 seconds

The dynamic web application i created is with the name “Tws”. So the build has created Tws.war and moved it to the default deploy folder of the JBoss server.

To make sure web service is started once it is deployed in the JBoss console you can find the log like below.

13:57:52,306 INFO  [ServiceEndpointManager] WebService started: http://:8080/Tws/TestWs

To view the WSDL follow the link http://<machine name>:8080/Tws/TestWs?wsdl

To see the list of webservices deployed in your JBoss Application server follow the link http://localhost:8080/jbossws. This browser console will have link to see your deployed webservices and their WSDL files.

JBossWs Browser Console.

Clicking on View a list of deployed services will list you the deployed web services. In our case we will get the following screen where we can see the registered service endpoints.

Here in this screen you can see the ServiceEndpointAddress link which will take you to the WSDL file.

You can also find the WSDL file in the following path:
<jboss_path>\server\default\data\wsdl\<project_name>.war\<filename>.wsdl

You can generate the client stubs using this file and access the web service. Creating the client stubs to access the web service is out of scope of this article.

The WSDL file generated using JBossWs is shown below:

<?xml version="1.0" encoding="UTF-8"?>
<definitions name="TestWsService" targetNamespace="http://dhanago.test.com/" xmlns:tns="http://dhanago.test.com/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">
  <types>
    <xs:schema targetNamespace="http://dhanago.test.com/" version="1.0" xmlns:tns="http://dhanago.test.com/" xmlns:xs="http://www.w3.org/2001/XMLSchema">
   <xs:element name="greet" type="tns:greet"/>
   <xs:element name="greetResponse" type="tns:greetResponse"/>
   <xs:complexType name="greet">
    <xs:sequence>
     <xs:element minOccurs="0" name="name" type="xs:string"/>
    </xs:sequence>
   </xs:complexType>
   <xs:complexType name="greetResponse">
    <xs:sequence>
     <xs:element minOccurs="0" name="return" type="xs:string"/>
    </xs:sequence>
   </xs:complexType>
  </xs:schema>
  </types>
  <message name="TestWs_greet">
    <part name="greet" element="tns:greet"/>
  </message>
  <message name="TestWs_greetResponse">
    <part name="greetResponse" element="tns:greetResponse"/>
  </message>
  <portType name="TestWs">
    <operation name="greet" parameterOrder="greet">
      <input message="tns:TestWs_greet"/>
      <output message="tns:TestWs_greetResponse"/>
    </operation>
  </portType>
  <binding name="TestWsBinding" type="tns:TestWs">
    <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
    <operation name="greet">
      <soap:operation soapAction=""/>
      <input>
        <soap:body use="literal"/>
      </input>
      <output>
        <soap:body use="literal"/>
      </output>
    </operation>
  </binding>
  <service name="TestWsService">
    <port name="TestWsPort" binding="tns:TestWsBinding">
      <soap:address location="http://EC3-NOR-124251:8080/Tws/TestWs"/>
    </port>
  </service>
</definitions>

Summary

This article is just a quick start to start with for developers who want to quickly proceed with JBoss web services. It is up to the developers interest to leverage on this and proceed further. This is not the only procedure to expose a web service in JBoss. There might be lot of ways to do that and this is one of the way. So don’t stop here and continue Exploring.