class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {

  List<SimpleRelationship<S,T>> relationshipsToAdd;
  List<SimpleRelationship<S,T>> relationshipsToRemove;
  ...
}

class SimpleRelationship<V extends BaseDto<?>, W extends BaseDto<?>> {

  // BaseDto classes are identified by the parameterized Id
  Id<V> left;
  Id<W> right;

  SimpleRelationship(BaseDto<V> one, BaseDto<W> another) {
    left = one.getId();
    right = another.getId();
  }
}

Having this structure, you can model the relationship between two instances of types A and B by an instance of SimpleRelationship<A>. If you want to communicate the creation of a relationship you would put the latter into the relatioshipToAdd list, if you want to model the deletion, you would put it into the relatioshipToRemove list.

Now I it was time to develop methods for access of the relationship lists inside of the ManyToManyDelta:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T> toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.add(toAdd);
  }
  ...
}

You could think that you have a batch update (e.g. an Array or List) of SimpleRelatioship objects you would like to add them by one invocation instead of a series of invocation. e.G:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T>[] toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.addAll(Arrays.asList(toAdd));
  }
  public void add(SimpleRelationship<S, T> toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.add(toAdd);
  }
  ...
}

Using the varargs feature of Java you could also write equivalent:

class ManyToManyDelta<S extends BaseDto<?>, T extends BaseDto<?>> {
  ...
  public void add(SimpleRelationship<S, T>... toAdd) {
    if (toAdd == null) { /* react */}
    this.relatioshipToAdd.addAll(Arrays.asList(toAdd));
  }
  ...
}

That would be nice, right? By the way, it is a good idea, to write some client code, during the development of API. This discovers potential problems:

  ...
  A entityA = ...;
  B entityB = ...;
  ManyToManyDelta<A, B> delta = new ManyToManyDelta<A,B>();
  delta.add(new SimpleRelationship<A,B>(entityA, entityB));

Coding this result in a type safety warning: A generic array of SimpleRelationship is created for a varargs parameter. Which reveals a problem in a Java language: you can not create an array of parameterized types. And resulting from this fact, you can not use that as varargs argument.

Abstract

Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the  compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

• Domain-specific component framework
• Methods for master data management
• Infrastructure services: authentication, authorization, communication, security, printing, reporting
• Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.

The required plug-ins

Following the general idea of RCP packaging (see rules provided in the RCP Book) and assuming one target platform (in terms of one RCP product), one top-level plug-in and should be defined. In addition, we assume at least one in-house framework plug-in and at least one application-specific plug-in. Usually there will be more of each type, but it will not change the picture much. Important at this point is the fact, that the application-specific code depends on the in-house framework code. In order to simplify the identification of the plug-ins, an example project is introduced. Let’s assume the project is called FooBar. Then, the plug-ins are called:

• de.techjava.foobar: This is the functional plug-in, which contains the application-specific code.
• de.techjava.framework: This is the framework plug-in, which contains framework component code.
• de.techjava.foobar.product.standalone: This is an application and product definition plug-in which contains the definition of the product and application-agnostic code for launching the application.

Managing plug-in dependencies

A difficult issue for the RCP beginners is the management of dependencies between plug-ins. Especially, the transition from the development of a single plug-in to the configuration of features and products seem to be non-trivial. In order to solve this problem, there are simple rules to follow. You can violate these rules in sophisticated scenarios, but for the beginners it is a good idea to follow them.

1. Create dependencies only if you need them. Each plug-in should only list plug-ins (or even better packages) it really depends on. Make sure to check it with the “Find unused dependencies” action available on the right-click in the Dependencies Tab of the Plug-in Manifest Editor.
2. Use versioning information. Plug-ins (or better bundles, or as Chris call them Plundles) provide version information. And it is highly advisable to include them in the import statements of the plug-ins, which simplifies the migration later on…
3. Don’t forget anything. Every Plug-in should appear in at least in one Plug-In section of the Feature definition. Every feature should be included by another feature, higher in the hierarchy.
4. Keep the hierarchy flat. For simple scenarios, it is sufficient to have two levels of features (top-level feature, one per-product and the underlying features include their plug-ins).
5. Don’t re-export dependencies. Every Feature for a group of plug-ins should also include plug-ins required by the members of the group. It does not hurt if a plug-in is included several times, but it does if it is not included at all. You can optimize here if you check which plug-ins are imported by the Eclipse RCP feature (which can be considered as stable), but it does not make assumptions about features developed by third parties.

Following these rules it is simple to create features for the corresponding plug-ins. Several plug-ins which belong together and are handled as a fixed piece can be grouped into Features. Usaging Features is highly advisable, and sometimes simply required (e.G. by RCP in a Java Web Start target deployment strategy). So in addition to the previously mentioned plug-in projects, at least three feature projects are required:

• de.techjava.foobar.feature: This is a functional feature, which includes the de.techjava.foobar plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
• de.techjava.framework.feature: This is a framework feature, which includes the de.techjava.framework plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
• de.techjava.foobar.feature.standalone This is the top level feature, which is used for the product configuration. It includes the two features above and the Eclipse RCP feature (and optional other features used, like e.G. org.eclipse.help). It also includes exactly one plug-in, which is not included anywhere else: de.techjava.foobar.standalone.product

The product definition plug-in

The definition of the product is spread among several files. First of all the plug-in.xml of the de.techjava.foobar.standalone.product plug-in makes uses of two extensions:

• org.eclipse.core.runtime.applications
• org.eclipse.core.runtime.products

The application extension point is used to point to the Java class implementing the interface org.eclipse.equinox.app.IApplication. Along with this implementation, other classes needed to start up the RCP (like Advisors, etc…) are placed into the source directory of the plug-in. The product extension point is used for the association of the application with a product id. The previously-defined top-level feature includes all required features and the product definition plug-in. Finally, the .product file is the place, where all things are bound together: product id, application id, launcher parameters, and the one top level feature: de.techjava.foobar.feature.standalone. Other customization of the RCP is possible from the plugin-customization.ini, which is placed together with the .product file into the plug-in root directory.

As a result the following configuration should be achieved after the packaging is finished. The product references the product-id and the application, defined in the plugin.xml of the plug-in project it is contained in. The product configuration is feature-based and includes one top-level feature. The top-level feature includes all other features (functional, framework, Eclipse RCP, other optional) and the one plugin, in which the product file resides.

The simple example provided in this articles is available as sourcecode for download ( rcp-packaging.zip).

The framework hooks

In the introduced scenario, the packaging is not specific to the in-house framework. It just includes the feature containing the framework plug-in. This approach works fine, if the framework is used in a white-box manner, which means that the framework provides ready-to-use components to be plugged-in to the application (like e.G. a component for the master data management). The other type of frameworks is the so-called black-box framework, which provides components that have to be configured and integrated into the application components. In this case, the framework components can not be plugged-in using some declarative extension points, but need to be called from the application code. In the latter case, the dependencies appear between the plug-in launching the application (de.techjava.foobar.standalone.product) and the framework plug-ins. This requires a modification in the previous setup and the violation of one of the rules posted above. The plug-in has to define the dependency to the framework plug-in, but the top-level feature does not include the required plug-in directly, but imports the whole framework feature.

[wscompile] wscompile ...\env\java\1.4.2_03\jre\bin\classpath-classpath D:\workspaces\general\lib\bla.bo-0.0.1.jar; ... D:\workspaces\general\lib\... jar.0.5.5

In this line, the classpath of wscompile is printed.

The build script uses configured Apache Ant in version 1.6.5. I tried to start it with Java in versions 1.4.2 und 1.6.0.10. Both works in Europa (Eclipse 3.3.x) but don’t work in Ganymede (Eclipse 3.4.x), except for the first run. It seems that Ganymede provides a different handling for Ant scripts. Every first start of an Ant build script produces new “External Tool Configuration” (if not already there). If this configuration already exists, wscompile task doesn’t work!

This means my build script with wscompile task works only once, every first time after deleting the “External Tool Configuration”. I could live with that if I wouldn’t need that configuration. But I need that configuration to use different java version that is the workspace default.

Do anyone know how to fix that?
Here is my task definiton.

<taskdef name="wscompile"
		classname="com.sun.xml.rpc.tools.ant.Wscompile"
		classpathref="class.path.jwsdp"
		/>

and also task usage in the script

<wscompile fork="true" import="true" base="java/class" sourceBase="java/generated" verbose="true" features="documentliteral, wsi, searchschema, serializeinterfaces, explicitcontext" mapping="java/generated/META-INF/jaxrpc-mapping.xml" config="metadata/wsdl-config.xml" xSerializable="true">
	<classpath>
		<path refid="class.path.local" />
		<path refid="class.path.ant" />
		<pathelement path="${java.class.path}" />
	</classpath>
</wscompile>

Comments are welcome.

Harald Wellmann of Innovative Systems GmbH (Harman/Becker Automotive Systems) talked about “Europe on a Disk – Geoprocessing for Car Navigation Systems”. He talked about their usage of Eclipse and OSGi to build the map compiler on top of these and explained different benefits and drawbacks in using this technology. Additionally, he talked about Jump and uDig which is used for displaying maps in the Eclipse Map Processing Toolkit. Apart from the technical point of view, the talk gave an interesting little insight how the maps for our beloved navigational systems are created.

The second talk was given by Gerd Wütherich ( independant consultant) and was about “Spring Dynamic Modules for OSGi Service Platforms”. He demostrated how to use Spring in order to harness the power of OSGis dynamic Java lifecycle in enterprise applications. While presenting he showed some small demos. In his order service example, two persistence services were available and one went “offline”, so the other one jumped in to take over. Once the second service went down too, the application was waiting (with a timeout) until some persistence service was available. As a “a world in a nutshell” this was a great demo of how to use dynamic modules.

After the second talk was a little break with italian food. (Which I did not try, so I will not comment on it, but it looked delicious.)

Miguel Garcia ( TUHH) and Rakesh Prithiviraj were talking about “Rethinking the Architecture of Java ORM in terms of LINQ”. This session basically covered a “what we (Java developers) could learn from .NET” features. As far as I understood, LINQ (Language INtegrated Query) is a query which is translated to a query for a specific natural datasource. Visualö Studio seems to provide good support for these kind of queries including content assist. Java on the other hand seems to struggle to provide as good support. The talk covered ideas of how to get at least close, if not catch up. I honestly do not understand, why such a innovative mechanism as LINQ was not introduced in Java much earlier? ( Slides of the two)

The last talk was given by Stephan Herrmann ( TU Berlin) discussed “Plugin reuse and adaptation with Object Teams: Don’t settle for a compromise!”. This was basically an intruduction to Object Teams, a language extension to Java, which was developed over the past seven-eight years at the TU Berlin. This extension does not only cover the fundamental aspects but supports the complete Eclipse tool support: content assist, debugger and finally, compiler. Object Teams provides something, which Stephan explained as inheritence on object level (instead on on the class level). It provides the ability to modify objects (especially class instances, not classes!) with additional behavior. So, it is possible to adapt classes to change their runtime behavior with so-called Role Classes. On method level, the roles can be applied in a call-in or call-out fashion, depending on when they have to be invoked. From the point of view of software engineering and language design this was a very interesting talk. (For more information refer to ObjectTeams, Slides are online at Slides).

And after the end of this talk, 23:00h had passed (we started at 19:00 o’clock). However, seeing many familiar faces and having a pleasant conversation, together with great presentations made it worth staying up late.

This session will be interactive / openspace like. He will walk through the new EJB 3.1 APIs and explain some interesting stuff as well. It is the logical conduction of the first JUG HH session in May 2008.

Location: Lehmanns Fachbuchhandlung (Hamburg Hauptbahnhof), Kurze Mühren 6, 20095 Hamburg

Date and Time: 16.09.2008, 20:00
Topic: Productive Java EE 6 – Rethinking Best Practices And Bashing On Patterns, Cluster One

Abstract: Java EE 6 is great, but many questions like:

• Are DAOs dead?
• Do JSF really suck?
• Are anemic JPA-entities a best practice?
• Are XML deployment descriptors legacy?
• Are EJBs lightweight?
• How to test EJBs?
• Is layering an antipattern?
• Do we need factories?
• How to integrate with RESTFul services?
• Is it possible to deploy EJBs into a …WAR?
• Are “plain old web containers” dead?
• Services or Objects – what is the way to go?

still remain open. These and many other questions will be discussed interactively with …code.

Speaker: Adam Bien

About the speaker: Java Champion Adam Bien is a self-employed consultant, lecturer, software architect, developer, and author in the enterprise Java sector in Germany who implements Java technology on a large scale. He is also the author of several books and articles on Java and J2EE technology, as well as distributed Java programming. His books include J2EE Patterns, J2EE HotSpots, Java EE 5 Architectures, Enterprise Architectures, Enterprise Java Frameworks, SOA Expert Knowledge, and Struts, all published in German.

As BEA technical director, Bien is also a member of the NetBeans Dream Team; an Expert Group member of the Java Community Process for EJB 3.1, JPA 2.0, and Java EE 6; and involved in embedded Java, Grid, and P2P technology. He currently works as an architect and developer in several J2EE-Java EE Model-Driven Architecture (MDA) and EAI component architecture projects for the Java EE platform and .NET.

We continued the search for the reason of error described in the previous post. After some search in HTTP Specification executed by Prof. Turau: “… Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]…”

For example Accept Header:
Accept = “Accept” “:” #( media-range [ accept-params ] )

But not Content-Type Header:
Content-Type = “Content-Type” “:” media-type

The server-side implementation

Besides Nokia Bug, putting multiple Content-Type headers in one request, there is an additional error server-side. I followed the JBoss call hierarchy which is:

org.jboss.ws.server.StandardEndpointServlet#doPost(HttpServletRequest req, HttpServletResponse res);
org.jboss.ws.server.ServiceEndpointManager#processSOAPRequest();
new org.jboss.ws.server.ServletHeaderSource(HttpServletRequest req, HttpServletResponse res);
org.jboss.ws.server.ServiceEndpoint#handleRequest(HeaderSource headerSource, ServletEndpointContext context, InputStream inputStream);
org.jboss.ws.server.ServletHeaderSource#getMimeHeaders();

During the whole processing, the headers are retrieved from the HttpServletRequest by the ServletHeaderSource which is the only implementation of HeaderSource:

public MimeHeaders getMimeHeaders()
{
    Enumeration e = req.getHeaderNames();
    if(e == null)
        return null;
    MimeHeaders headers = new MimeHeaders();
    String name = null;
    for(; e.hasMoreElements(); headers.addHeader(name, req.getHeader(name)))
        name = (String)e.nextElement();

    return headers;
}

Afterwards, if you call getHeader on the MimeHeaders object the string array is constructed from the existing data and returned:

public String[] getHeader(String name)
{
    ArrayList tmp = new ArrayList();
    for(int n = 0; n < headers.size(); n++)
    {
        MimeHeader mh = (MimeHeader)headers.get(n);
        if(mh.getName().equalsIgnoreCase(name))
            tmp.add(mh.getValue());
    }

    String values[] = null;
    if(tmp.size() > 0)
    {
        values = new String[tmp.size()];
        tmp.toArray(values);
    }
    return values;
}

This means, that the implementation of the HttpServletRequest returns concatinated list of values for the duplicate headers.

Specifications again

Now, I looked in Java Servlet Specifications about the getHeader method:

Servlet 2.1

Returns the value of the requested header. The match between the given name and the request header is case-insensitive. If the header requested does not exist, this method returns null.

Servlet 2.2

The getHeader method allows access to the value of a header given the name of the header. Multiple headers, such as the Cache-Control header, can be present in an HTTP request. If there are multiple headers with the same name in a request, the getHeader method returns the first header contained in the request.

Servlet 2.3 and 2.4

The getHeader method returns a header given the name of the header. There can be multiple headers with the same name, e.g. Cache-Control headers, in an HTTP request. If there are multiple headers with the same name, the getHeader method returns the first head in the request.

Results

So it seems to be a Tomcat Bug, as long as Tomcat provides the implementation for the HttpServletRequest… This bug is integrated in JBoss, because they use Tomcat implementation. Never the less, JBoss use the getHeader method relies on the correct implementation.

During some work executed for the proposal to the NFC Congress 2008, we introduced a scenario for using the NFC-enabled Nokia 6131 in the industrial environment. The selected use case records some NFC data and uses the Internet to transmit it to the cental server. During the prototype construction, we decided to use Google Maps as a framework for location-based display of gathered information. The server has been constructed based on J2EE EJBs and exposes its functionality using SOAP-based document-literal Web Serives, as described in one of the privious posts.

Nokia 6131 NFC

The Nokia 6131 NFC is first NFC-enabled mobile phone. NFC stands for Near-Field-Communication – a new evolving wireless technology to interact with RFID tags. It is strongly supported and pushed by several big players. This results in several conferences around this subject all around the world.
The NFC in Java is specified in JSR 257. In addition to that, 6131 seems to support several other JSRs, also including JSR 172 for Web Services. After having a closer look on the offered API, it cames out, that only the XML-parser part of JSR 172 is supported.

Sending SOAP Requests without JSR 172

In order to set the requests to a Web Service from a mobile phone, that does not supprt Web Service JSR 172, a manual creation of request is needed. This results in something like:

public abstract class SoapHandler extends DefaultHandler {

    public static final String SOAP_BEGIN = "<soapenv:Envelope xmlns:soapenv=\"http://schemas.xmlsoap.org/soap/envelope/\" xmlns:q0=\"http://www.techjava.de/2008/nfc/visualizer/types\" xmlns:xsd=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\"><soapenv:Body>";
    public static final String SOAP_END = "</soapenv:Body></soapenv:Envelope>";

    private StringBuffer reqBuf = new StringBuffer(); // Buffer that holds the request message

    ...
    public SoapHandler(String message) {
        reqBuf.append(message);
    }

    public int doHttpRequest(String url, String soapAction) throws IOException {

        reqBuf.insert(0, SOAP_BEGIN);
        reqBuf.append(SOAP_END);

        HttpConnection httpConn = (HttpConnection) Connector.open(url);
        httpConn.setRequestMethod(HttpConnection.POST);
        httpConn.setRequestProperty("SOAPAction", soapAction);
        httpConn.setRequestProperty("Content-Length", Integer.toString(reqBuf.length()));

        OutputStream os = httpConn.openOutputStream();

        os.write(reqBuf.toString().getBytes());
        os.close(); // Request is sent when output-stream is closed
        return httpConn.getResponseCode();
    }

...
}

If you execute the code above, the 6131 device send a HTTP request using Content-Type plain/text, that is automatically inserted and changes the case of “SOAPAction” to lower. As long as JBoss 4.0.5 GA used in this experiment supports only Content-Types application/soap+xml and text/xml (as it should according to the specification), it throws a SOAP Exception:

javax.xml.soap.SOAPException: Unsupported content type: text/plain
        at org.jboss.ws.soap.MessageFactoryImpl.createMessageInternal(MessageFactoryImpl.java:138)
        at org.jboss.ws.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:87)
        at org.jboss.ws.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:190)
        at org.jboss.ws.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:355)
        at org.jboss.ws.server.StandardEndpointServlet.doPost(StandardEndpointServlet.java:115)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.jboss.ws.server.StandardEndpointServlet.service(StandardEndpointServlet.java:76)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        ...

The MIME Content-Type can easily be set on any HTTP connection:

        httpConn.setRequestProperty("Content-Type", "application/soap+xml");

This works well in the NFC Nokia simulator, part of the Nokia SDK, but breaks down executed from the device. It seems to be a bug in the implementation, or an intended feature of Nokia limiting the usage of the phone for business applications, but the HTTP-Request contains a duplicate Content-Type entry valued by the “application/soap+xml”. Playing around with the implementation, we found that it put any Content-Type header twice into the request. Decompiling and analyzing of simulator code does not helped at all. Since we don’t know how to get and patch sources of J2ME port to Nokia 6131, I decided to apply a workaround.

Server tolerance

JBoss reacts to this fact of a duplicate Content-Type header by throwing a SOAPFaultException.

javax.xml.rpc.soap.SOAPFaultException: Could not parse content type:javax.mail.internet.ParseException: Expected ';', got ","
        at org.jboss.ws.jaxrpc.SOAPFaultExceptionHelper.exceptionToFaultMessage(SOAPFaultExceptionHelper.java:194)
        at org.jboss.ws.server.ServiceEndpoint.handleRequest(ServiceEndpoint.java:223)
        at org.jboss.ws.server.ServiceEndpointManager.processSOAPRequest(ServiceEndpointManager.java:355)
        at org.jboss.ws.server.StandardEndpointServlet.doPost(StandardEndpointServlet.java:115)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
        at org.jboss.ws.server.StandardEndpointServlet.service(StandardEndpointServlet.java:76)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
        ...

We followed the stacktrace, and identified the class that causes the Execption. It is org.jboss.ws.soap.MessageFactoryImpl located in JBOSS_DEPLOY /jbossws14.sar/jbossws14-core.jar. After some source code alanysis, we found several problems in the implementation:

private static ContentType getContentType(MimeHeaders headers) throws SOAPException
{
	ContentType contentType = null;
	try
	{
		String type[] = headers.getHeader("Content-Type");
		if (type != null)
		{
			contentType = new ContentType(type[0]);
		} else
		{
			contentType = new ContentType("text/xml");
		}
		return contentType;
	} catch (ParseException e)
	{
		String message = (new JBossStringBuilder()).append("Could not parse content type:").append(e).toString();
		throw new SOAPException(message);
	}
}

First of all, we would expect that the array length is proven, before the first element is accessed. Secondly, if multiple same headers are present in the request, their values are combined using a comma resulting in:

application/soap+xml; charset=utf-8, application/soap+xml; charset=utf-8

This combination could make sence if you put multiple Content-Lang headers in your request, but not for Content-Type. So we fixed the implementation by following code, taking only the first Content-Type value from the list, if present:

...
String type[] = headers.getHeader("Content-Type");
if (type != null && type.length != 0)
{
	int index = type[0].indexOf(',');
	String correctedType = (index != -1) ? type[0].substring(0, index) : type[0];

	contentType = new ContentType(correctedType);
} else
{
	contentType = new ContentType("text/xml");
}
return contentType;
...

Summary

Even if Nokia 6131 NFC offers some functionality for the developer, it does not provide the best platform for use case try-outs. Especially, the lack of supported standard (like full JSR 172) and a low-end OS (Symbian 40-Series), and some bugs / features in implementation of connectivity will lead to problems in prototype implementations of use cases…

Many frameworks support plugins for increasing flexibility. They need to be loaded during runtime making it possible to change the supported features used in application without recompiling the framework and application themselves. Loading a plug-in means loading java classes, which is done by a class loader. We want to load the plug-ins from jar files, without providing a name for every JAR. Unfortunately, the java standard API does not contain a class loader for loading classes from a list of jar files in a directory. We need to provide it ourselves. In addition, the standard class loading mechanism is designed with following idea in mind: in runtime the application accesses the known classname, that is searched for in class path and loaded if found. In our case, we want to force the framework load it extensions, without setting up the class path before applications starts, which is a little different use case.

Simple JAR class loader

The first step is loading classes from jar files. For this purpose we create a class named JarFileClassLoader which should be able to load a class from a jar file. It inherits from ClassLoader, the Java default implementation for a class loader. Loading a class from a jar file means scanning each jar file entries, decide if it is a class then load it. Because we want to be flexible about the criterion we use to select our classes, we introduce an interface ICriterion, which decides for a given class if the criterion is fulfilled or not. Using this, the JarFileClassLoader can now scan a single jar file and load every class fulfilling the injected criterion. Loading a class means scanning the caches of the parent class loaders, calling the loadClass(String) method of the parents if not found and scanning the jar file afterwards if the class was still not found. This beahviour is described in a previous post, introducing the basics of Java Class Loading.

JarFileClassLoader is capable of loading a class if it does not reference other classes. These references have to be resolved during class loading time. Let consider the example of classes A and B where A references B. If A is loaded by a class loader CL, CL is asked for loading B also. This is done by calling the loadClass(String) method of CL. If B is contained in the jar file CL loads classes from, CL will find it and return it to the JVM. If B is not contained in CL’s jar file, CL’s parents are asked to load it. Thus the class will be loaded if it is contained in the classpath where one of the java class loaders will find it. If the class is contained in another jar file in the list, but not in the class path it will not be found and the loading will end with a ClassNotFoundException.

Plugin class loader

To tackle this problem we introduce another class, the PluginLoader. It contains a collection of JarFileClassLoaders and inherits from ClassLoader, thus is a ClassLoader itself. The PluginLoader acts as a parent for all JarFileClassLoaders and is therefore asked every time a class has to be loaded. It will then iterate over all JarFileClassLoaders calling the loadClass(String) method on all of them to find the class it looks for. This way, classes contained in sibling class loaders are found also without violating the rule that a class loader can only see classes of itself or its parents.

Putting everything together

Now the structure of our plug-in loader component becomes clear. What we additionally need to do, is get rid of all the stack overflows we produce with the above classes. The problem here is that any JarFileClassLoader asks its parent, the PluginLoader, to load a class. This will ask all child JarFileClassLoaders to load the class including the CL which asked the PluginLoader before. The result is an infinite call stack loop – a stack overflow. Therefore we relax the concept of the java class loading. We introduce a method loadClassSimple(String) on the JarFileClassLoaders which looks just in its very own jar file. If it does not find the wanted class it just throws an Exception without asking a parent or cache-lookups. This method is called by the PluginLoader only, therefore the rest of the class loading is not affected.

Last but not least we consider some performance issues. If a class is searched in other jar files, those have to be scanned every time again resulting in poor performance. Therefore we introduce a cache in the JarFileClassLoader containing every class that was loaded before. Every request is served now by trying to find the class in the cache first.

Limitations

Due to the fact, that PluginLoader asks its child JarClassLoaders to load a class in particuliar order, and the first class found will be taken, the order in which JarClassLoaders are asked matters. This issue can cause problems if e.G. different versions of the same library are deployed on location scanned by the PluginLoader and should be handled with care.

References

• [2007,book] bibtex
  G. Krueger and T. Stark, Handbuch der Java-Programmierung, , 2007.
  @book{2007_KRUEGER,
  author = {Guido Krueger and Thomas Stark},
  title = {Handbuch der Java-Programmierung},
  month = Nov, year = {2007},
  url = {http://www.javabuch.de/} publisher = {Addison-Wesley} isbn = {3-8273-2373-8}
}
• [,techreport] bibtex
  "Java Class Loading: The Basics,".
  @techreport{CL_BASICS author = {Brandon E. Taylor},
  title = {Java Class Loading: The Basics},
  url = {http://www.developer.com/java/other/article.php/2248831}

In this article we describe how to implement a simple Web Service using old fashioned Java EE 1.4. The dummy functionality is implemented in Session Beans and exposed via document-literal Web Service following the recommendations of W3C and WS-I.

Introduction

Before we get in to technical details about the implementation a short overview of planned is helpful. The main idea of this article is to show how a web service can be implemented using Java Enterprise Edition. Especially, this article tries to achieve two goals: show how existing EJB functionality can be exposed using Web Service technology and how Web Service technology can be linked to something stable, most of us have experience with. Many people follow the new trend of saying that EJB is ineffective and heavyweight – we don’t want to argue about this thesis. In this article we show a progmatic EJB development approach using “code-by-convention” combined with Generative-Programming techniques. We develop the EJB functionality and Web Service definition independent from each other and link them later together – we are sure that this is the only approach to keep both parts simple, clean and reusable. During the WSDL design we follow a certain style of type and element selection, that results from some experiences of using generators and integration with non-Java environments. Our use case is a little synthetic in order to show the variety of types and seems to introduce structural complexity, which can be avoided. We implement the examples using open source products only.

The article starts with a short introduction which could look a little lyrical for some technicians of you. Then the requirements to the selected software are listed, followed by the practical use case. Then we jumpstart the EJB development cycle, design the Web Service and finally put both implementations together. In the outline, we discuss the testing possibilities…

Requirements

In order to develop, generate, package and finally deploy and run the component, exposing its functionality we need special software. Following selections has been made:

• Sun’s JDK (> 1.4.2)
• Apache Ant (> 1.6.5)
• XDoclet (1.2.3)
• Sun’s Java Web Service Developer Pack (1.6)
• JBoss AS (4.0.5 GA)
• Eclipse IDE (> 3.3), recommended WTP installation

First of all we need to setup our environment. In order to make development under MS Windows convenient, we used to setup the entire environment variables in a single shell script:

@echo off
echo ----------------------------------------
echo Project Environment
echo ----------------------------------------
set DEVEL=c:\environment
set ANT_HOME=%DEVEL%\libraries\ant\1.6.5
set JAVA_HOME=%DEVEL%\compiler\j2sdk1.5.0_01
set JAVAC_EXEC=%DEVEL%\compiler\j2sdk1.5.0_01\bin\javac.exe
set JWSDP_HOME=%DEVEL%\compiler\jwsdp-1.6
set PATH=%JAVA_HOME%\bin;%ANT_HOME%\bin;%PATH%;%DEVEL%\bin;%JWSDP_HOME%\jaxrpc\bin
echo Environment variables:
echo ANT home : %ANT_HOME%
echo JAVA home : %JAVA_HOME%
echo PATH set to : echo %PATH%
echo ----------------------------------------
echo CLASSPATH set to : echo %CLASSPATH%
echo ----------------------------------------
cmd

For usage under Linux/MacOS the script should be adjusted correspondingly.

Eclipse is used as IDE for the whole development. In order to avoid any dependency to certain Eclipse functionalities we use Apache Ant as a build tool. In order to use the build tools these should be configured. In Preferences of Eclipse we set up Apache Ant and XDoclet. In Window -> Preferences -> Ant -> Runtime set up the Ant Home pointing to the Ant installation directory. In Window -> Preferences -> XDoclet set up XDoclet Home to XDoclet installation directory and set the version to 1.2.3.

Project Setup

Even if we don’t want to rely on the build and shortcommings of Eclipse in the area of EJB development, we want to use maximum of support if possible.

Create a new EJB Project and select the following Project Facets: EJB Module 2.1, XDoclet 1.2.3 and Java 1.4. We use the following project structure: all hand-written Java files go to /java/src directory, all Doclet-generated goes to /java/generated, the compiled files go to /java/class and the resulting archives (jars and ears) go to /java/build. The additional /metadata directory contains source and descriptor files needed for the project. To set all this up go to Project Properties -> Java Build Path. As long as we control XDoclet from an Ant script, we deactivate the XDoclet Builder in Project Preferencies -> XDoclet and in Project Preferences -> Builders. Before we begin with the implementation we have to set up the Ant script, that will build and package our project. The script unifies different tools we use to a single toolchain and contains several targets. These are EJB-Doclet generation target, WS-Compile target, Web-Doclet target, target for compilation of the Java classes and, finally, creation of a JAR and EAR files. In order to hold the build file project independent we use properties files that contain project specific settings. In order to access XDoclet and WSCompile from Ant the corresponding task definitions must be included and the libraries must be put to directories in classpath. For this purpose we used to create a library project in the same workspace, containing the libraries (called general).

...
<path id="class.path.local">
  <fileset dir="../general/lib">
    <include name="**/*.jar"></include>
    <include name="**/*.zip"></include>
  </fileset>
</path>
<path id="class.path.jwsdp">
  <path refid="class.path.local"></path>
</path>
<path id="class.path.doclet">
  <path refid="class.path.ant"></path>
</path>
<taskdef name="wscompile" classname="com.sun.xml.rpc.tools.ant.Wscompile" classpathref="class.path.jwsdp"></taskdef>
<taskdef name="xdoclet" classname="xdoclet.DocletTask" classpathref="class.path.doclet"></taskdef>
<taskdef name="ejbdoclet" classname="xdoclet.modules.ejb.EjbDocletTask" classpathref="class.path.doclet"></taskdef>
<taskdef name="wseedoclet" classname="xdoclet.modules.wsee.WseeDocletTask" classpathref="class.path.doclet"></taskdef>
...

In order to demonstrate the implementation we introduce a use case. This is sonstructed for the demonstration purposes and shows the usage of different types.

Use Case

The constructed system is capable of providing the measurements of some sensors. The sensors are identified by numers and can be queried by the user by providing the timespan of measurements. As a result, the systems delivers the set of measurements for the given timespan with one measurement per minute but at most sixty measurements. Every measurement contain the id of sensor from which it has been recorded, the timestamp, the value as a byte array, the measurement unit and finally the flag if the measurement exceeds the expectation and has alarming values.

We start with typical EJB implementation and then adopt the resulting types to those, that should be used in a Web Service.

First Session Bean powered by XDoclet

Following the EJB 2.1 specification the stateless session bean class must implement the javax.ejb.SessionBean interface. We follow the Class Adapter design pattern and create an abstract session bean that serves as a super class of all session beans.

public abstract class AbstractSessionBean implements SessionBean
{
	/** Logging facility */
	protected static Logger LOG = Logger.getLogger(AbstractSessionBean.class);
	/** Session context */
	protected SessionContext	sessionContext;

	/**
	 * @see javax.ejb.SessionBean#ejbActivate()
	 */
	public void ejbActivate() throws EJBException, RemoteException
	{
	}

	/**
	 * @see javax.ejb.SessionBean#ejbPassivate()
	 */
	public void ejbPassivate() throws EJBException, RemoteException
	{
	}

	/**
	 * @see javax.ejb.SessionBean#ejbRemove()
	 */
	public void ejbRemove() throws EJBException, RemoteException
	{
	}

	/**
	 * @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
	 */
	public void setSessionContext(SessionContext sessionContext) throws EJBException, RemoteException
	{
		this.sessionContext = sessionContext;
	}
}

Using such an adapter we can avoid code repetition in functional session beans. It could be also a good idea to put the logging facility into this abstract class. Any functional bean extends AbstractSessionBean and overwrites the ejbCreate() method which is used to setup the working copy of a Bean. Mostly, references to other beans are initialized in this method. Due to the usage of XDoclet, we follow the Factory pattern implemented in the EJB-Util class, which simplifies access to other EJBs.

In our example we flatten the exception handling to the minimum and introduce one exception class for every functional bean, which is thrown by any error during processing. Therefore, any functional methods throw this exception. Usually, exceptions should be topic-related instead of being bean-related.

Information needed for XDoclet generation is stored in the corresponding XDoclet tags inside of the JavaDoc comments. For the full list of XDoclet tag please refer to the XDoclet site. We only explain the tags, we use. The ejb.bean tag indicates that a class is an EJB, providing a name, display-name, description as well as JNDI-Names of LocalHome interface and of the bean itself. The visibility is controlled over the view-type tag, the transactionality over transaction-type tag. Every business method we want to be included to business interfaces (Remote or Local) should be tagged with ejb.interface-method with corresponding view-type. Using this simple rule set we can easily implement business logic layer based on the stateless session beans:

/**
 * ...
 * @ejb.bean name="SensorManager"
 *  description="A Bean responsible for sensor operations"
 *  display-name="SensorManagerBean"
 *  jndi-name="techjava/SensorManagerrBean"
 *  local-jndi-name="techjava/SensorManagerLocalHome"
 *  type="Stateless"
 *  transaction-type="Container"
 *  view-type="both"
 * ...
 */
public class SensorManagerBean extends AbstractSessionBean
{

	/**
	 * Max number of returned values
	 */
	private static final long MAX_DURATION = 60;

	/**
	 * Retrieves data from sensors
	 * @param sensorId id of sensor to query
	 * @param timespanStart start of the time period
	 * @param timespanEnd end of the time period
	 * @return a collection of Measurement POJOs or an empty collection
	 * @throws SensorManagerException if something goes wrong
	 * @ejb.interface-method view-type="both"
	 */
	public Collection getSensorData(Long sensorId, Date timespanStart, Date timespanEnd)
          throws SensorManagerException
	{
		Collection ret = new Vector();
		LOG.debug("Entering getSensorData()");
		if (sensorId == null || timespanStart == null || timespanEnd == null)
		{
			throw new SensorManagerException("Missing a mandatory parameter, that was null (not set)");
		} else if (!timespanStart.before(timespanEnd)) {
			throw new SensorManagerException("The timespan is defined by the start that should be before end");
		}

		for (long i = 0; i < getNumberOfElements(timespanStart, timespanEnd); i++)
		{
			Date date = new Date(timespanStart.getTime() + i*1000*60);
			if (date.after(timespanEnd))
			{
				break;
			}

			Measurement measurement = createMeasurement(sensorId, date, i);
			ret.add(measurement);
		}

		LOG.debug("Leaving getSensorData(). Returning " + ret.size() +" values");
		return ret;
	}

        /**
	 * retrieves the number of measurements in timespan
	 * @param timespanStart
	 * @param timespanEnd
	 * @return
	 */
	public long getNumberOfElements(Date timespanStart, Date timespanEnd) {	... }

	/**
	 * Creates a measurement instance
	 * @param sensorId
	 * @param timestamp
	 * @param number
	 * @return
	 */
	public Measurement createMeasurement(Long sensorId, Date timestamp, long number) { ... }
}

In order to generate the artifacts required by the specification from the written bean, we need to call a corresponding EJBDoclet task. The task itself is configuring only main generation options, during the subtasks are invoked for artifact generation. We used to separate classes of different purpose by packages and massively use the packageSubstitution subtask for this purpose. Remote, local, local home and remote home interfaces, util factory class and both EJB and a vendor-specific descriptors are generated using corresponding tasks.

<ejbdoclet destdir="${ejb.distdir}" verbose="true" ejbspec="2.1">
	<fileset dir="${ejb.srcdir}">
		<include name="${ejb.include}" />
	</fileset>
	<fileset dir="${ejb.distdir}">
		<include name="${ejb.include}" />
	</fileset>
	<packageSubstitution packages="ejb.entity" substituteWith="interfaces.entity" />
	<packageSubstitution packages="ejb.session" substituteWith="interfaces.session" />
	<packageSubstitution packages="ejb.facade" substituteWith="interfaces.facade" />

	<remoteinterface pattern="{0}Remote" />
	<localinterface pattern="{0}Local" />
	<homeinterface pattern="{0}Home" />
	<localhomeinterface pattern="{0}LocalHome" />

	<utilobject kind="physical">
		<packageSubstitution packages="ejb.session" substituteWith="util.session" />
		<packageSubstitution packages="ejb.facade" substituteWith="util.facade" />
	</utilobject>

	<deploymentdescriptor
               destdir="${ejb.descriptor.distdir}"
               displayname="${ejb.modulename}"
               description="EJB Module ${ejb.modulename}"
        />

	<jboss
		destdir="${ejb.descriptor.distdir}"
		version="4.0"
		mergedir="metadata/merge"
	/>
</ejbdoclet>

After generation of the classes and descriptors, which will be executed in a separate directory, it is a good idea to copy the descriptors back to the primary source folder, in order to allow for Eclipse to work with generated descriptors. Now we can compile the hand written code, together with generated code, put the results in a Java archive and assembly it to an enterprise archive, which can be deployed on an application server.

Hands on the Web Service Definition

The design of the interface definition is in general one of the most important steps in the component development life cycle. Depending on the quality of the interface design the component becomes reuseable or remains in usage only in the application it was initially built for. Therefore, we rely on a human engineering instead of generation.

For the definition of our Web Service, we use a standard language for this purpose, the WSDL. A WSDL file has a following structure:

• Types
• Messages
• Operations
• Port Type
• Bindings
• Services

As long as we intend to use document-literal, SOAP-style Web Services, the Binding and the Service parts are straight forward. The only thing we should pay attention is the Fault definition. We start from the Port Type definition, which is the equivalence of the business interface. A Port Type has a name and a collection of operation definitions, containing references to incoming, outgoing and fault messages. The Message part defines how XML Schema Types are used in the operations. This means that the most important parts of the WSDL file are the introduced Types, which are defined using XML Schema and the Port Types, which defines Operations, which use the Types.

The main purpose of a WSDL file is to define an interface. In order to distinguish it from the others, the interface is named. As long as WSDL defines a web-accessible resource, we use full qualified names, similar to XML target namespace.

<wsdl:definitions name="MeasurementProvider"
	targetNamespace="http://www.techjava.de/2008/ws4j2ee14/measurement/"
	xmlns:tns="http://www.techjava.de/2008/ws4j2ee14/measurement/"
	xmlns:types="http://www.techjava.de/2008/ws4j2ee14/measurement/types/"
	xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
	xmlns:xsd="http://www.w3.org/2001/XMLSchema">
	<wsdl:types>
		<xsd:schema
			targetNamespace="http://www.techjava.de/2008/ws4j2ee14/measurement/types/"
			xmlns:types="http://www.techjava.de/2008/ws4j2ee14/measurement/types/"
			elementFormDefault="qualified"
		>
			<!--
				ID element for sensor
			-->
			<xsd:simpleType name="sensor-id">
				<xsd:restriction base="xsd:long" />
			</xsd:simpleType>
			<!--
				Measurement complex type
			 -->
			<xsd:complexType name="Measurement">
				<xsd:sequence>
					<xsd:element name="sensorid" type="types:sensor-id" />
					<xsd:element name="timestamp" type="xsd:dateTime" />
					<xsd:element name="critical" type="xsd:boolean" />
					<xsd:element name="value" type="xsd:base64Binary" />
					<xsd:element name="unit" type="xsd:string" />
				</xsd:sequence>
			</xsd:complexType>

			<!--
				Timespan complex type
			 -->
			<xsd:complexType name="Timespan">
				<xsd:sequence>
					<xsd:element name="start" type="xsd:dateTime"
						minOccurs="1" maxOccurs="1" />
					<xsd:element name="end" type="xsd:dateTime"
						minOccurs="1" maxOccurs="1" />
				</xsd:sequence>
			</xsd:complexType>

			<!--
				Operation Types
			-->
			<xsd:element name="GetSensorData">
				<xsd:complexType>
					<xsd:sequence>
						<xsd:element name="sensorid" type="types:sensor-id"
							minOccurs="1" maxOccurs="1" />
						<xsd:element name="timespan" type="types:Timespan"
							minOccurs="1" maxOccurs="1" />
					</xsd:sequence>
				</xsd:complexType>
			</xsd:element>

			<xsd:element name="GetSensorDataResponse">
				<xsd:complexType>
					<xsd:sequence>
						<xsd:element name="measurements" type="types:Measurement"
							maxOccurs="unbounded" />
					</xsd:sequence>
				</xsd:complexType>
			</xsd:element>
			<xsd:element name="GetSensorDataFault">
				<xsd:complexType>
					<xsd:sequence minOccurs="1" maxOccurs="1">
						<xsd:element name="reason" type="xsd:string"
							minOccurs="0" maxOccurs="1" />
					</xsd:sequence>
				</xsd:complexType>
			</xsd:element>

		</xsd:schema>
	</wsdl:types>
...
	<!--
		Port Type (interface declaration)
	-->
	<wsdl:portType name="MeasurementProviderPortType">
		<wsdl:operation name="GetSensorData">
			<wsdl:input message="tns:GetSensorDataRequest" />
			<wsdl:output message="tns:GetSensorDataResponse" />
			<wsdl:fault message="tns:GetSensorDataFaultMessage"
				name="GetSensorDataFault" />
		</wsdl:operation>
	</wsdl:portType>
...
</wsdl:definitions>

Web Service Implementation

The created WSDL file is used for further Java code generation. For this purpose we use WSCompile, a tool supplied with Sun’s Java Web Service Developer Pack. The tool need a configuration file (wsdl-config.xml) storing the location of the WSDL file and namespace-to-package mappings. As a result of its execution, the tool generate Java classes for every custom type defined in XML Schema and the descriptor for JAX-RPC mapping required by the container for serialization and deserialization. In addition, it creates a Service interface, that is a interface to the factory of generated Port Type interfaces. The tool also generate implementation stubs for every Port Type, which can be ignored.

<configuration xmlns="http://java.sun.com/xml/ns/jax-rpc/ri/config">
	<wsdl
	    location="./metadata/MeasurementProviderService.wsdl"
	    packageName="de.techjava.sensor.interfaces.stubs"
	>
	     <namespaceMappingRegistry>
            <namespaceMapping
            	namespace="http://www.techjava.de/2008/ws4j2ee14/measurement/types/"
            	packageName="de.techjava.sensor.valueobjects"
            />
	     </namespaceMappingRegistry>
	</wsdl>
</configuration>

The WS Compile is usually called from the command line, but we use the Ant Task for this. Important are the features passed to the generator: documentliteral, wsi, searchschema, serializeinterfaces and explicitcontext. The path to the generated JAX-RPC mapping file is provided by the mapping attribute. Pay attention on the tool call, because depending on parameters given it generates Java classes from WSDL or vice versa.

<wscompile fork="true" import="true" base="java/class"
	sourceBase="java/generated" verbose="true"
	features="documentliteral, wsi, searchschema, serializeinterfaces, explicitcontext"
	mapping="java/generated/META-INF/jaxrpc-mapping.xml"
	config="metadata/wsdl-config.xml"
	xSerializable="true"
>
	<classpath>
		<path refid="class.path.local" />
		<path refid="class.path.ant" />
		<pathelement path="${java.class.path}" />
	</classpath>
</wscompile>

After we generated the Java representation of the Web Service interface, we can integrate it with our EJB implementation. In order to do this, we used to create a Facade session bean, that implements the Port Type interface. The methods of the facade bean provide some parameter validation, form the values needed for the calculations, invoke the corresponding EJBs, receive results or exceptions and, finally, form the response object or fault. The XDoclet annotation of the facade bean follows the one discussed above, but differs from it slightly. The view-type attribute of the ejb.bean tag should hold the value remote-service-endpoint. In addition, the ejb.interface tag provide information about the Java Port Type interface and about the special Endpoint interface, that is required for the container. In order to generate the Endpoint interface, we add the service-endpoint subtask to the ejbdoclet task.

...
/**
 * @ejb.interface
 *  service-endpoint-class="de.techjava.sensor.interfaces.session.MeasurementProviderFacadeConnectorEndpoint"
 *  service-endpoint-extends="de.techjava.sensor.interfaces.stubs.MeasurementProviderPortType"
 * @wsee.port-component
 * 	name="MeasurementProviderService"
 * 	local-part="MeasurementProviderService"
 * 	display-name="MeasurementProviderService"
 * 	description="MeasurementProvider Bean exposed as a web service"
 */
public class MeasurementProviderFacadeBean
	extends AbstractSessionBean
	implements MeasurementProviderPortType
{
	private SensorManagerLocal sensorManagerLocal = null;

	/**
	 * Creates a link to SensorManager
	 * @see de.techjava.sensor.ejb.session.AbstractSessionBean#ejbCreate()
	 */
	public void ejbCreate()
		throws EJBException
	{
		try
		{
			sensorManagerLocal = SensorManagerUtil.getLocalHome().create();
		} catch (CreateException e)
		{
			throw new EJBException("Error creating new Session Manager instance");
		} catch (NamingException e)
		{
			throw new EJBException("Session Manager Local Home could not be found in JNDI");
		}
	}

	/**
         * Method called on web service message receipt
	 * @ejb.interface-method view-type="remote-service-endpoint"
	 */
	public GetSensorDataResponse getSensorData(GetSensorData parameters)
		throws GetSensorDataFault
	{
		LOG.debug("Received a web service request getSensorData()");
		if (parameters == null
                  || parameters.getTimespan() == null
                  || parameters.getTimespan().getEnd() == null
                  || parameters.getTimespan().getStart() == null)
		{
			LOG.debug("Leaving getSensorData() with error");
			throw new GetSensorDataFault("Wrong request, check mandatory parameters");
		}
		if (sensorManagerLocal == null)
		{
			LOG.debug("Leaving getSensorData() with error");
			throw new GetSensorDataFault("Sensor Manager is not available");
		}

		Long sensorId = new Long(parameters.getSensorid());
		Date timespanStart = parameters.getTimespan().getStart().getTime();
		Date timespanEnd = parameters.getTimespan().getEnd().getTime();

		try
		{
			Collection simpleMeasurements = sensorManagerLocal.getSensorData(sensorId, timespanStart, timespanEnd);
			Vector measurements = new Vector(simpleMeasurements.size());
			Iterator simpleMeasurementI = simpleMeasurements.iterator();

			// convert types from EJB to generated XSD representations
			while(simpleMeasurementI.hasNext())
			{
				SimpleMeasurement sm = (SimpleMeasurement) simpleMeasurementI.next();
				Measurement measurement = convertMeasurement(sm);
				measurements.add(measurement);
			}

			GetSensorDataResponse response = new GetSensorDataResponse();
			response.setMeasurements((Measurement[]) measurements.toArray(new Measurement[measurements.size()]));
			LOG.debug("Leaving getSensorData().");
			return response;

		} catch (SensorManagerException e)
		{
			LOG.debug("Leaving getSensorData() with error");
			throw new GetSensorDataFault(e.getMessage());
		}
	}

}

In addition, the special J2EE Web Service descriptor webservices.xml needs to be created. For this purpose we use WSEE-Doclet, that introduces its own tags. The wsee-port-component provides display-name, web-service-description-name and port-component-name in the attributes name, local-part and display-name. The WSEE-Doclet is started from an Ant task and has one subtask wsee-deploymentdescriptor which is used to generate the required webservice.xml file.

...
<wseedoclet destDir="${ejb.descriptor.distdir}" jaxrpcMappingFile="jaxrpc-mapping.xml" wseeSpec="1.1" force="true" verbose="true">
	<fileset dir="${ejb.srcdir}">
		<include name="**/*.java" />
	</fileset>
	<wsee-deploymentdescriptor />
</wseedoclet>
...

Outline

For testing of Web Services is an important step of development. Especially, the resulting SOAP messages should be reviewed at least once, to ensure that the description is completed correctly, and no malformed XML structures are used. In order to play around with fresh-deployed Web Service open a browser of you choice and enter the URL of the web service overview of your application server. If JBoss (>4.0.5) runs locally, this will be http://localhost:8080/jbossws/. You should see a list of deployed web services. By clicking on a wsdl-button you can retrieve the version of WSDL after deployment (containing the target URL of the endpoint interface). Using this WSDL you can run tests of your web service. We use Eclipse’s Web Service Explorer to run developer tests (WTP installation needed). You can access it under Run -> Launch the Web Service Explorer. Switsch to WSDL-Page by clicking on the second button from right, in the upper right corner, enter the URL and hit Go. Fill the form generated for each method, send the request and analsye the response. If you want to create more advanced tests (and test suites) please refer to SOAP-UI Project.

Resources

You can download the zip file ( de.techjava.ws4j2ee14.sensor_20080219_src.zip) containing the example above.

References

• [2004,techreport] bibtex
  S. Microsystems, "The Java Web Services Tutorial," 2004.
  @techreport{SUN_2004_JWSTUTORIAL,
  author = {Sun Microsystems},
  title = {The Java Web Services Tutorial},
  month = Jun, year = {2004},
  url = {http://java.sun.com/webservices/docs/1.4/tutorial/doc/index.html}
}
• [2003,book] bibtex
  O. Ihns, S. M. Heldt, R. Wirdemann, and H. Zuzmann, Enterprise JavaBeans komplett, publisher Oldenburg, , 2003.
  @Book{IHNS_2003,
  author = {Oliver Ihns and Stefan M. Heldt and Ralf Wirdemann and Henning Zuzmann},
  title = {Enterprise JavaBeans komplett},
  publisher {Oldenburg},
  year = {2003},
  month = {Oct},
  url = {http://www.ejbkomplett.de/}
}
• [2000,book] bibtex
  K. Czarnecki and U. W. Eisenecker, Generative Programming, publisher Addison-Wesley, , 2000.
  @Book{CZARNECKI_2003,
  author = {Krzysztof Czarnecki and Ulrich W. Eisenecker},
  title = {Generative Programming},
  publisher {Addison-Wesley},
  year = {2000},
  month = {May},
  }
• [1994,book] bibtex
  E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software, , 1994.
  @Book{GAMMA_1994,
  author = {Erich Gamma and Richard Helm and Ralph Johnson and John Vlissides},
  title = {Design Patterns: Elements of Reusable Object-Oriented Software},
  year = {1994}
}
• [,techreport] bibtex
  "XDoclet Project,".
  @techreport{XDOCLET,
  author = {},
  title = {XDoclet Project},
  url = {http://xdoclet.sourceforge.net/xdoclet/index.html}
}