IT-eye

Working for almost one and half year in SOA projects for several customers, I can now conclude that almost every component is made fully reusable by means of a service. One service for database communication, one service for communication with the CRM module etc. One implementation that can be reused in every corner of the SOA environment.

However, each time I evaluate a SOA project I have done or working on I conclude that there is one component we can’t write once and use everywhere: the front-end application. Suppose you have a fully reusable customer service to retrieve customer information from the database. Each time you want to integrate a front-end functionality to query the customer information in a specific front-end application in you SOA article you have to write the view layer again for most parts. You are not able to completely reuse the view implementation to query the database. Therefore, in my opinion the front-end components for user interaction in a SOA envirnoment are not really in the SOA scope.

With the Web service for Remote Portlets (WSRP 2.0 OASIS specification) standard, a specification which defines how to leverage SOAP-based Web services that generate mark-up fragments within a portal application, you are able to fully reuse front-end applications in SOA environment. WSRP is based on WS standards like the WSDL, therefore it can also be registred with an UDDI. Note that WSRP can be used on top of the JSR-168 specification for building standard portlets.

Recently, Oracle released the Webcenter Suite that contains a fully compliant WSRP portlet container. I think this will augment the Oracle SOA Suite with capabilities to make reusable front-end components.

Recently, I have installed the Oracle SOA Suite 10.1.3.1 on my Win XP laptop. Amazingly, the installation went well and the whole suite was installed in less then 15 minutes…so far so good. I have chosen for an advanced installation on my Oracle Express installation, so the suite is installed in a separate OC4J container named oc4j_soa.

I also installed JDeveloper 10.1.3.2 on my laptop to build and deploy bpel processes with. JDeveloper uses Ant to deploy bpel processes. You can right-click your bpel project and choose the deploy option to deploy the process to your BPEL Process Manager (BPM) installation or you can use the build.xml file in project directly.

JDeveloper uses standard property settings (e.g oc4j instance and port settings) for deployement. The standard settings assume for example that the BPM is installed in the home oc4j instance. These settings plays an important role in deploying the jsp task forms generated in JDeveloper for a human task. Because I have a different SOA suite environment, I needed to change these default settings to successfully deploy my process including the jsp task forms. The reason why I wrap this fact in a posting is because I have to find out myself which files are responsible for the bpel Ant settings. There are two places where you can change the default bpel ant properties:

• build.properties file in your project. This file is used when you want to override the default settings on project scope
• ant-orabpel.properties file located in \bpel\utilities. The default settings are stored in this file. So make changes here when you want to change settings globally

Please make sure that you use the deploy target from the build.xml to use the changed settings in the build.properties file. When you use the deploy actions from the project options menu (rigth-click on project root node) the settings are ignored. I think it uses in that situation a default build file instead the build file from the project.

If you work with the latest jax-ws (sun reference implementation) and try running the wsgen task using ant inside JDeveloper, you will most likely encounter this error.

[wsgen] java.lang.NoSuchMethodError: javax.jws.WebMethod.exclude()Z
[wsgen] at com.sun.tools.ws.processor.modeler.annotation.WebServiceVisitor.hasWebMethods(WebServiceVisitor.java:375)
[wsgen] at com.sun.tools.ws.processor.modeler.annotation.WebServiceVisitor.shouldProcessWebService(WebServiceVisitor.java:351)
[wsgen] at com.sun.tools.ws.processor.modeler.annotation.WebServiceVisitor.visitClassDeclaration(WebServiceVisitor.java:145)
[wsgen] at com.sun.tools.apt.mirror.declaration.ClassDeclarationImpl.accept(ClassDeclarationImpl.java:95)
[wsgen] at com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.buildModel(WebServiceAP.java:347)
[wsgen] at com.sun.tools.ws.processor.modeler.annotation.WebServiceAP.process(WebServiceAP.java:232)
[wsgen] at com.sun.mirror.apt.AnnotationProcessors$CompositeAnnotationProcessor.process(AnnotationProcessors.java:60)
[wsgen] at com.sun.tools.apt.comp.Apt.main(Apt.java:454)

This is due to the fact JDeveloper loads in an older version of the jax-ws api and always seems to add its classpath to ant. The most simple solution is to disable the following jar: [jdev]/webservices/lib/jws-api.jar (just rename it to e.g. jws-api.jar.original). It will not be loaded anymore. If you now have the proper j2ee jars in your classpath you can run wsgen inside JDeveloper. Don’t forget to close and restart JDeveloper.

Obviously this is not a preferable solution as you destroy other JDeveloper related webservices support; you can place back a new jar containing the latest javax.jws.* and javax.xml.ws.* classes. However I have not tested this, so it may or may not work.

Today, I read on the OASIS site that the BPEL4WS 2.0 specification is finally approved as Commitee Draft a few weeks ago. I do not had the time available to read the whole spec (roughly 280 pages…), but a quick scan of the contents showed me that 2.0 adds some new language constructs, like the exit statement to exit a process without triggering any compensation or fault handlers. BPEL-WS is also defined to be extensible. Extensions can range anything from from new attributes to new elements, to extended assign operations and activities. This means that the language definition contains constructs to use extensions in a bpel process. The BPEL4People extension for human interaction is such an extension developed by IBM and SAP.

I wonder how soon this specification will reach it final stage and implemented by BPM vendors like Oracle or IBM…

I just finished giving an Oracle ADF training. This is a 3 day training were people learn to use EJB3, JPA, JSF, ADF Faces and ADF Data Controls and Data Bindings. This is a lot of material for 3 days, next time we’ll probably extend the training to 4 or 5 days.

As always, the students aren’t the only ones who learn a lot during a training. I always find that whenever I’m giving a training I’m learning a lot too. To be able to explain how something works, and how you should use it, means you have to really understand it. Just being able to use it, doesn’t mean you understand it well enough to explain it.

I created the training material myself, which was also quite a challenging task. There’s so much information available about the subjects, what do you put in your slides and what do you skip? In the beginning i just put everything i thought relevant on the slides, but this is not a good way to learn about ADF.

So i turned it around, it’s not the slides nor the information that is important. What is important is that the students learn how to use the tools to create the applications that they need. This means that the core of the training should be the exercises. If a student can complete an exercises it means he’s able to use the technology. So i created a lot of exercises, and only put in my slides whatever i though necessary for the students to be able to complete the exercises (to be honest, i still have some slides in there that aren’t really necessary for the exercises, these will be removed the next time i give the training).

It’s also important that the exercises slowly become more complex, it’s a step by step process. I read an interesting statement some time ago on a forum which said that you can only learn what you almost know. I think this is very true, and it means that a training needs a lot of exercises that slowly expect more knowledge of the subject.

Another interesting fact i learned during the training is that ADF Business Components and JHeadstart are quite popular. Personally, I prefer to use standard solutions whenever a good standard solution is available. For example, Java Persistency API. Before JPA, java didn’t have a good standard and broadly supported solution for ORM, so better alternatives became mainstream. But in my opinion JPA is good enough for most applications, so for me JPA is the default pick, unless there’s a good reason to use something else. Using standards has the advantage that there’s a lot of information available, and it’s easy to find developers, which is quite important in today’s market. For nonstandard niche solutions it’s a lot harder to find support and developers.

But most of the students in the training had a Oracle Forms Developer and Designer background, and they really like ADF Business Components and JHeadstart. Business Components because it allows them to reuse their extensive SQL knowledge, and JHeadstart because it’s the only tool that gives them the generation productivity similar to Oracle Designer.

On my current project, we decided to use a textfield with auto-completion to have both the functionality of a listbox and a free textfield. With AJAX you can easliy build this feature yourself, or you can use one of the AJAX/Javascript frameworks like DWRorDojo. We choosed to use the more lightweight library AjaxTags. The AjaxTag library is developed for JSP and Struts and consists of several standard ajax jsp tags, e.g. auto-completion. It also contains a servlet implementation and a Struts action implementation, which you can extend to implement the server-side functionality. In this posting, I will explain how we have implemented auto-completion. For more details and screenshots please look here

First we implement the servlet that will handle the actual search action and send a XML respond message containing the search result back to the client.

package nl.iteye.autocompletion;

import java.io.IOException;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import javax.servlet.ServletException;

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.ajaxtags.helpers.AjaxXmlBuilder;
import org.ajaxtags.servlets.BaseAjaxServlet;

/**
 * @version 	1.0
 * @author
 */
public class AutoCompletionServlet extends BaseAjaxServlet {

	/* (non-Javadoc)
	 * @see org.ajaxtags.servlets.BaseAjaxServlet#getXmlContent(javax.servlet.http.HttpServletRequest, javax.servlet.http.HttpServletResponse)
	 */
	public String getXmlContent(HttpServletRequest arg0, HttpServletResponse arg1) throws Exception {
		System.out.println("getXmlContent begin()");
		String prefix = arg0.getParameter("model");

		List items = new ArrayList();
		items.add("ababba");
		items.add("ababbadsad");
		items.add("ababbabxvxbvxb");
		items.add("ababbasadasd");
		items.add("ababbazvzxvzv");
		items.add("ababaaavvvaa");
		items.add("accccaacbbbb");
		items.add("accccaacvv");
		items.add("accccaaccccc");
		items.add("accccaacaaaa");
		items.add("fffccjjjjss");
		items.add("ffetrwer");
		items.add("fwtrwer");
		items.add("fwerqwrqwr");

		//AjaxTags contains some builder classes to generate plain text, html or xml output
		AjaxXmlBuilder builder = new AjaxXmlBuilder();
		Iterator it = items.iterator();
		while(it.hasNext()){
			 String optie = (String) it.next();
			 if(optie.startsWith(prefix)){
			 	builder.addItem(optie, optie);
			 }
		}

		return builder.toString();
	}
}

Implemented the server-side, we can now use the ajax tag library to build the client with auto-completion:

<%@ page language="java" contentType="text/html; charset=ISO-8859-1" pageEncoding="ISO-8859-1"%>
<%@ taglib uri="http://ajaxtags.org/tags/ajax" prefix="ajax"%>
<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

  <meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" />
  <title>AJAX JSP Tag Library Examples</title>

  <script type="text/javascript" src="<%=request.getContextPath()%>/js/prototype-1.4.0.js"></script>
  <script type="text/javascript" src="js/scriptaculous.js"></script>
  <script type="text/javascript" src="js/overlibmws.js"></script>
  <script type="text/javascript" src="<%=request.getContextPath()%>/js/ajaxtags-1.2-beta2.js"></script>
  <link rel="stylesheet" type="text/css" href="css/ajaxtags.css" />
  <link rel="stylesheet" type="text/css" href="css/displaytag.css" />

</head>
<body>
<h1>Autocomplete Demo</h1>

<form action="." class="basicForm">
  <fieldset>
    <label for="model1">First enter:</label>
    <input id="model1" name="model1" type="text" size="30" />
    <span id="indicator1" style="display:none;"><img src="img/indicator.gif" /></span>
    <!-- Used to store the value of the label />
    <input id="make1" name="make1" type="hidden" size="30" />
  </fieldset>
<div id="errorMsg" style="display:none;border:1px solid #e00;background-color:#fee;padding:2px;margin-top:8px;width:300px;font:normal 12px Arial;color:#900"></div>
</form>
<ajax:autocomplete
  source="model1"
  target="make1"
  parameters="model={model1}"
  baseUrl="${pageContext.request.contextPath}/autocomplete.ajax"
  className="autocomplete"
  indicator="indicator1"
  minimumCharacters="1"
  parser="new ResponseXmlToHtmlListParser()" />
</body>
</html>

Note that we use a XML to HTML parser, because the servlet returns XML to the client. You can further specify the mininal characters after the auto-completion will start. The indicator points to the span that will be displayed only during the actual search and will disappear afterwards. So the user sees that something is going on.

My conclusion, AjaxTags is easy to use and can be integrated perfectly into any JSP Struts app to add AJAX features.

When doing a BPEL project which processes contains user tasks – actions which need to be performed by the users – there are two options.
1. Build your own worklist based on the Worklist API.
2. Use the default worklist which is provided by Oracle in the SOA suite. Since the default worklist contains all functionality we need for our project we decided to save ourselves some time building our own and use the oracle default worklist. However some modifications are still necessary. We want to use jsso instead of the worklist login. We also want to change some visual aspects like branding and the look-and-feel.

Oracle describes all the steps to create your custom worklist application. It even includes documentation on how to make the application jsso enabled. However they assume you are working from the application server where the samples are installed and that you leave it there. For me, and I think for many people this is not an option.
I copied the worklist from the app server to my desktop and created a JDeveloper workspace & project from it. I changed the code to make the worklist jsso enabled and created a deployment descriptor for easy deployment. It took me some gathering all the required library’s which are not documented by Oracle. Turns out you need the BI-Beans jars and uix2.jar for the graphs. What I want to do next is run my worklist application from the Jdeveloper embedded OC4J so I can do some developing/debugging. To do so I need to change the way the worklist connects to bpel from JAVA_CLIENT to REMOTE_CLIENT.
I included the bpel jars to the project, created a wf_client_config.xml file on the classpath, changed the connection to remote and deployed. Whatever I do, I cannot get a connection to the worklist. For now I will settle deploying the worklist to the soa-oc4j as a child of orabpel.

When diving into the worklist code it strikes me the way the worklist is build. It is a Model 1 jsp servlet application with lots of scriplet code. This makes modification and maintenance quite hard. I thought we had had left this kind of programming behind us and moved on to Model 2 MVC applications. Especially Oracle with it’s own MVC framework (ADF) should be able to do better I think. After going through all the trouble of getting the sample worklist running I wonder if it might be smarter to build your own worklist.

The ADF.Faces.NEXT posting on this blog gets a lot of traffic, many people ask for more info. Shay Shmeltzer just posted an entry on his weblog which will be of interest to them: ADF Faces Rich Client Demo and Other AJAX Thingies. He links to a viewlet which demos Oracle’s upcoming AJAX enabled JSF components used for a webstore: ADF Faces Rich Client – Sneak Preview. Btw, Oracle internally refers to these components as the “Rich Client Components”, not ADF.Faces.NEXT.