Publish a WebService from a POJA (plain old Java application) – that is: out of the container using EndPoint class

5

 

This very brief article will demonstrate a very useful feature of Java 6 Standard Edition – that means: the Java as it is running in any stand-alone application. It is possible – and even extremely simple as it turns out – to have a Java SE application publish a (SOAP) WebService. That is: without using a Web Server or Application Server, your Java application can receive WebService calls. I had heard about this but could not actually believe that I understood correctly. When I met Gerard Davison this week – a very nice and knowledgeable guy working on web services tools for the JDeveloper IDE – he confirmed and explained it to me. 

Through the EndPoint class – part of the JAX-WS implementation – we can instruct the JVM to start receiving SOAP calls on the URL we tell it to listen to and have those calls forwarded to our Java class. Thus it is very simple all of a sudden to for example provide mock implementations of services our BPEL process or ESB needs to invoke. This mechanism makes interoperability between for example .NET and Java very easy – especially in terms of the infrastructure required. And of course in situation where a Java application running outside any container make a call to an Asynchronous WebService – this is the basis of the answer to the question how the asynchronous response can be handed back to the application. See for example Gerard’s article on this: Calling Asynchronous WebServices from Java application. Let’s see how it actually works.  Create the simplest class in the world:

package nl.amis.ws;

public class UpperCaser {

    public String process(String text) {
        return text!=null?text.toUpperCase():"" ;
    }

    public static void main(String[] args) {
    }
}

Then either add the annotations for exposing the class as a WebService or use your IDE facilities to it for you. I of course did the latter – having JDeveloper publish this class as a WebService for me (that means: adding the required annotations).

package nl.amis.ws;

import javax.jws.WebService;
@WebService(name = "StringService", serviceName = "StringService", portName = "StringServiceSoapHttpPort")

public class UpperCaser {

    public String process(String text) {
        return text!=null?text.toUpperCase():"";
    }

    public static void main(String[] args) {
    }
}

Now we have a WebService that will be exposed when we deploy this application to our container. However, I also want to have the WebService exposed when I just run the main method of the application (well, the class). And that is where the EndPoint class comes in:

package nl.amis.ws;

import javax.jws.WebService;
import javax.xml.ws.Endpoint;

@WebService(name = "StringService", serviceName = "StringService", portName = "StringServiceSoapHttpPort")
public class UpperCaser {

    public String process(String text) {
        return text!=null?text.toUpperCase():"";
    }

    public static void main(String[] args) {
     Endpoint e =  
           Endpoint.publish("http://localhost:7890/endpoint", new UpperCaser());      
     try{
            Thread.sleep(40*1000);
        }
        catch (Exception ex) {
           System.out.println(ex);
        }
    }

}

Using the static publish method on the EndPoint class, we specify the URL on which the WebService should be available and pass the class-with-WebService annotation to handle the calls received at that URL.

When I ask my IDE to run the class UpperCaser, it provides me with two options – one because of the @WebService annotation and one because of the main method:

 

 

I elect to run the application as a stand alone Java application in the JVM without container whatsoever.

When the application is running, I can access it at the URL specified in the call to EndPoint.publish and for example retrieve the WSDL that is dynamically created by the JAX-WS framework – URL is http://localhost:7890/endpoint?wsdl:

Calling the WebService is easily done using for example Soap UI. I create a new project, provide the URL of the WSDL and have SOAP UI prepare a request to call the WebService:

Then I have Soap UI make the call to the WebService and sure enough the response comes in:

So it really was that simple. Create a class, provide @WebService annotation, write a main method to publish an end point and run the application. That are all the steps for publishing a WebService in plain old Java application.

 

 

 

 

And then answers comes back in, internally handled by the ca

Share.

About Author

Lucas Jellema, active in IT (and with Oracle) since 1994. Oracle ACE Director for Fusion Middleware. Consultant, trainer and instructor on diverse areas including Oracle Database (SQL & PLSQL), Service Oriented Architecture, BPM, ADF, Java in various shapes and forms and many other things. Author of the Oracle Press book: Oracle SOA Suite 11g Handbook. Frequent presenter on conferences such as JavaOne, Oracle OpenWorld, ODTUG Kaleidoscope, Devoxx and OBUG. Presenter for Oracle University Celebrity specials.

5 Comments

  1. Hi ALL
    I need to implement above featuer, hosting a webservice through POJO in Java 1.5. can anyone provide me steps to implement if possible.
    Thanks in advance
    PETER

  2. Hi Lucas

    Yeah, it is very cool that this functionality is now *built-in* to JSE.

    I read somewhere that Sun’s reasoning for including it in the standard edition was similar to the provision of RMI in the standard edition.

    Cheers
    Graham

  3. Hi Graham,
    Thanks for your comments and the useful resource link. Of course my article did not so much go into details of exposing Java based functionality as a WebService as such – that topic has been covered at length in many places and is also largely done for us by IDEs such as JDeveloper. The real essence of this brief post was the fact that you can publish a WebService in J2SE – outside of the container – at an EndPoint that is largely user definable.
    Lucas

  4. Hi

    Your post is certainly a nice starting place for exposing a POJO as a web service, but for anything other than trivial Hello World applications developers will need a lot more information regarding the exposure of complex data types, programming to interfaces (JAXB fun), error handling, etc. While none of these topics are really complicated, there are a number of conventions that must be adhered to and … well… known gotchas, if you like.

    I’ve documented my experience of exposing a real-world application and all of the issues it brings here: http://invertedindex.wordpress.com/2009/05/04/java-6-web-services/. The post also provides a selection of the best links on the topic of Java SE 6 / Mustang web services, from the original Sun tutorials (also blog posts).

    Cheers
    Graham

  5. Wow, that’s quite nice and powerful! This will create a lot of other possibilities. How about when running Java on the client, as in a applet, … I can not think of sensible functionality, but I’m sure someone will (peer2peer application communicating with webservices?).