ws serving... quick and dirties? part 1

From the architecture point of view, either in Web APIs or into the interoperability and connectivity parts of the app, there is the web services part. The architecture should be able to address and solve (or conform to) various constrains of the existing environment of applications, or the external resources that should be used by the services.

I will address various cases under the SOA and tools posts labels over the next days.

For now one the issue is the ability to make the quick way an set of web-services. So, after from architecting weve just conclude to the types, number and functionality o the main ws set. There are lots of times (specially in case of existing infrastuctures), that we need to have a

1. fast way to createWebServices and
   
2. we don't want to deal/manage with J2EE containers(packaging/deployment ...)

There were two projects that i was involved in with this and in the second one, I have tried the OpenEJB option.

Apache OpenEJB is an embeddable and lightweight EJB 3.0 implementationthat can be used as a standalone server or embedded into Tomcat, JUnit,TestNG, Eclipse, IntelliJ, Maven, Ant, and any IDE or application.OpenEJB is included in Apache Geronimo, IBM WebSphere ApplicationServer CE, and Apple's WebObjects.

In other words, OpenEJB isa way in which you can have everything that is available in the EJB3container, but 'outside' the container (well, not really but is close to).

Consider the next step by step tutorial for creating a webservice.

• Create a sampleproject
  
• Download openejb-3.0.zip from http://openejb.apache.org/download.html and unpack it
  
• Add to the classpath of your sampleproject every .jar file that's in unpacked/lib
  
• Create a META-INF folder inside your src directory and create afile inside that folder called ejb-jar.xml and just put in it thisstring "" (without quotes)
  
• Create now the interface that defines the contract of your webservice and anotate it with

@WebService(targetNamespace="http://thecompanyname.com/wsdl")

public interface TestWs { ... }

• Create the class that implements your interface and anotate it:

@Stateless

@WebService(portName = "TestPort",

serviceName = "TestWsService",

targetNamespace = "http://thecompanyname.com/wsdl",

endpointInterface = "full.qualified.name.of.your.interface.TestWs")

public class TestImpl { ... }

• To start the Webservice you need to do this:
  

pubilc static void main(String[] args) {

Properties properties = new Properties();

properties.setProperty(Context.INITIAL_CONTEXT_FACTORY,

"org.apache.openejb.client.LocalInitialContextFactory");

properties.setProperty("openejb.embedded.remotable", "true");

new InitialContext(properties); // here the magic starts ....

}

Thats all. After these steps, you have a stateless bean exposed as a webservice in this location: http://localhost:4204/TestImpl?wsdl

You can use a dynamic proxy (or apache axis2) to generate a Java client for it. The dynamic proxy goes like this:


// this code can be placed rigth after InitialContext call, or
// can be in another program or in another thread in the same program
// The program that made the call to InitContext need to be alive,
// in order to expose the EJB3 services

URL serviceUrl = new URL("http://localhost:4204/TestImpl?wsdl");
Service testService = Service.create(serviceUrl, null);
TestWs testWs = testService.getPort(TestWs.class);

// test the methods you've implemented ...


Wondering how does it works ?

While requesting the the initial context, openejbautomatically searchs for clases in your classpath containingejb3-related anotations, it automaticaly exposes them as it founds,more or less as it happens when you deploy an application as a .ear inany aplication server, but simpler and with great flexibility due toits embedable architecture.

The reason (expect for the quickness above) for using openejb is that, after doing the 2nd ad third bullet above you have the following major features of the OpenEJB:

Major features

• Supports EJB 3.0, 2.1, 2.0, 1.1 in all modes; embedded, standalone or otherwise.
• JAX-WS support
• JMS support
• J2EE connector support
• Can be dropped into Tomcat 5 or 6 adding various JavaEE 5 and EJB 3.0 features to a standard Tomcat install.
• CMP support is implemented over JPA allowing to freely mix CMP and JPA usage.
• Complete support for Glassfish descriptors allowing those users to embedded test their applications.
• Incrediblyflexible jndi name support allows you to specify formats at macro andmicro levels and imitate the format of other vendors.
• Allows for easy testing and debugging in IDEs such as Eclipse, Idea Intellij or NetBeans with no plugins required.
• Usable in ordinary JUnit or other style test cases without complicated setup or external processes.
• Validatesapplications entirely and reports all failures at once, with threeselectable levels of detail, avoiding several hours worth of "fix,recompile, redeploy, fail, repeat" cycles.

and therefore you have some... dirtiness above the quickness.
Of coarse, that was the case (for my case) that needed the EJB compliance (ohhh the constrains of the architecture analysis).



In part 2 i'll show you the usage of another tool that helped me lot in another project, just by using xml-xsls but in a very practical (quick & dirty) way...