Over the last few months a number of Apache projects started on the next level of Web service protocols - Apache Sandesha based on the unsubmitted IBM/MS WS-ReliableMessaging specification, Apache Addressing based on the unsubmitted IBM/MS WS-Addressing specification, WSS4J based OASIS WS-Security and lastly WSRP4J based on OASIS WSRP - Web Services for Remote Portlets.

These efforts were clearly a harbinger for the BPEL space. Today Tug Grall pointed me at an open source BPEL implementation he found - Twister, put out in mid-March.  Paul Brown mentioned OpenBPEL as another example in the space arriving sometime back in February.  Clearly early days if you download either one, but some serious initial effort appears to be underway.

This should be seen as a "good thing" because the more public BPEL implementations there are the clearer the ambiguities in the specifications/standards become. It becomes more viable for groups like the WS-I to conceive and arrive at reasonable interoperability scenarios against a range of implementations.  We also get to see a bit of how the different implementations will go about differentiating themselves in the face of some initial commoditization of the standard. 

11:03:30 PM    

Nice presentation from Jean-Jacques Dubray posted yesterday.  Lots to chew on, but for reasons of discussions we have been having around SOA recently, I particularly liked this cliche line that is likely used by every integration vendor on the planet but still rings true in this space:

1:20:10 AM    

It seems like BPELJ, IBM/BEA's submission to facilitate JSR 207 discussion has brought out a chorus of voices opining about whether it is good or bad - Paul Brown, Edwin Khodabakchian, Phil Wainewright, Howard Smith, The Register and many more ... shock, disbelief, outrage and much more.  It doesn't get much more exciting in the world of Web services.

I think the general agreement outside of IBM/BEA is that embedding Java in BPEL is generally not a "good thing" but I also think a number of folks, including myself (though I can't say I am representative of the opinions in Oracle), wish there was some variation of the "window in the glass bottomed boat" that Paul Brown calls BPELJ ... but with some more restrictive rules on its usage rather than the wholesale tight coupling provided by the BPELJ proposal.

There are clearly many BPEL friendly ways to hook Java in to BPEL ranging from simply working with Java as Web services to giving more native access through frameworks like WSIF.  Yet at the same time, having some well-defined hooks for native languages, not just Java, because of idiosyncracies in your BPM project, seems like something that vendors will naturally provide anyway. 

Avoided by thoughtful project managers - just like proprietary J2EE extensions - those same managers will be happy they are there when they need them, treating them with caution as they rightfully should.  Further, perhaps, while the analogy may be weak, just as JSP scriptlets turned into tag libraries which resulted in JSTL, usage patterns and best practices of a more constrained and thoughtful BPELJ-like feature set may in fact turn into well-considered general changes to the underlying BPEL specification over time.

Others are more dogmatic that BPELJ is an evil idea for which, analogously, we will end up paying the multi-year standards evolution price we paid to get to the reasonably usable CMP EJB 2.0 solution (with EJB 3.0 to fix it even better!) which is fair enough.  Hopefully given this is being discussed in at least two relatively open standards forums (OASIS, JCP) unlike other proprietary specifications, both sides will be accomodated.  Whether it resolves in something useful for users rather than something that vendors will use to promote proprietary implementations remains to be seen. 

For insight into the jockeying and general user opinion on this, it is worthwhile to peruse the OASIS BPEL mailing list.

12:39:31 AM    

I've been on a bit of a rant lately to folks who complain that nothing is a Web service - my simple minded retort is everything is a Web service. 

What I mean by that is that nearly any executable/programmatic resource/component can be described using WSDL and, generally, though not necessarily, talked to using SOAP.  Some of these things are nicely standardized in the Java world with J2EE 1.4; others are provided by vendor/product extensions (e.g. JMS Web services are not standardized but most folks offer some solution in the space; database DML/SQL are not Web services but nearly every database vendor worth their salt gives you tooling to do these things via a Web service, nearly all proprietary platforms inevitably offer their "things" as Web services too etc).

This doesn't mean that when you build a Web service centric solution that every endpoint will be the ideal Web service.  Real life is messy.  Things like C programs, Forms applications, CICs, JCA and much more don't quite fit but more often than there are relatively painless ways to make them work (see the resolution in my Forms note as an example).  Further, there are interesting technologies like WSIF which enable WSDL descriptions of endpoints but then let clients bind using native protocols rather than packaging things up using SOAP (e.g. native bindings to JCA). 

But if your going in position when building a new Web service centric solution is that everything of interest can be normalized to a service with WSDL, then it shapes how you go about about solving the problem.  The cries of performance, reliability, transactions security and much more will inevitably come up (and all are clear issues to be dealt with) but starting from a "everything can be a Web service" gives a consistent context to shape your response and ultimate solution.

I think a common sentiment and it is just my turn to say the obvious.  I must be in my "everything is a nail because I have a hammer" mode which generally indicates too big of a problem is being solved.  I suppose we will see.

10:11:30 PM    

A slide from a recent Microsoft presentation:

BPEL Import
1 BPEL is an interchange format
2 BPEL is like WSDL but for behaviour of services
3 Defines External/Public behaviour across Platform
4 Export BPEL from one platform; import into the next
5 Each platform will have its own execution engine; leveraging the platform strengths

I can work with 1 - share business process best practices is something that naturally falls out of that conclusion.  I can work with 2 as an analogy.   I like 4 - kind of the same as 1 though ideally with a fleshed out BPEL standard, "copy" might be better - this may simply be a reflection of MSoft's current implementation.  And 5 is the industry opportunity BPEL brings to the table.

It's 3 I have to wonder about - BPEL by its very name is *executable* and generally seems best suited for private processes.  Abstract BPEL gives a view of a BPEL process's external, public behaviour but I am not sure it is enough to really capture all the semantics of a peer to peer, business to business collaboration.  This is the complementary problem to BPEL the folks in the W3C Choreography group are tackling with CDL.

Taken from  Edwin Khodabakchian's blog where he posted a link to a broadcast  that was hard to resist last night.  As he notes, Scott Woodgate is a heck of a presenter - someone who clearly knows his story.

10:21:21 PM    

The San Francisco Chronicle had an interesting, likely purposeful juxtaposition, of stories on the front page today:

• Outcry at schools -- sports dropped - Sports programs were dropped for budget reasons as an West Contra Costa school
• More schools making the grade - More Bay area kids are scoring better on state tests

• Poor diet killing more in U.S. - Bad eating habits and physical inactivity are overtaking tobacco as leading cause of death in the US

I guess the conclusion is kids are getting smarter from all that studying but perhaps by doing less sports but their lifespans will be shortened because of all that inactivity.   Go figure.

These things start seeming more relevant when you have kids.   Fortunately, my six year old daughter doesn't seem to have inactivity on the brain quite yet.  She is currently whipping me into shape by getting me into having jump rope contests at every spare moment I have.  Anyone whose tried "hot peppers" as she calls them - skipping as fast as you can until either you trip or fall down from exhaustion - will know that it's either a quick way to get  a coronary or an amazingly intense workout in 30 second to 1 minute intervals.  

9:35:30 PM    

Jeepers, the Oracle Bloggers are running amok ... I see today that Shay Shmeltzer, a huge JDeveloper advocate, has been blogging away for several months too.  Both of us were hired into the same group at Redwood Shores originally back in 2001 - he's ended up on the JDeveloper team and I have ended up on the OC4J team.

9:43:03 PM    

A recurring question folks seem to have in the Oracle Web services world and likely elsewhere is how to send a file to a Web service ... the typical use case being one or more XML documents from a partner, separate department or external client that needs to be shared/processed by a peer service.  This can be done in a number of ways - two outlined here:

1. Read the file content as XML, turn it into an XML element and send it to a service endpoint where upon the service endpoint either works with it as is or writes it back out as a file to be dealt with by some other process.  This is quite easy in both OC4J 9.0.4 and 10.0.3 as this blog will show.
   
2. Send the file content as an attachment to a Web service and again, as above, have the service endpoint  either process it or write it out to be picked up by some other process. This is possible in OC4J 10.0.3 using SAAJ, which I plan to tackle in another entry.

Recently, a customer had been asking me to provide a sample for #1 and I finally got around to getting this out today.  It's pretty easy to do once you have done it once; it's doing it the first time that seems tricky, especially to folks unfamiliar with XML and type support within Web services.

The Web service implementation is provided in below.   I did two things here - first, the inbound parameter is of type org.w3c.dom.Element, a supported parameter type in Oracle's and most other Web service implementations; second, I had the service endpoint write the inbound document out to a server file, another customer requirement.  I published this as a doc/literal Web service using the steps outlined in my JDeveloper Doc/Lit tip.  Remember from that entry the key thing is *not* to deploy the WSDL generated by JDeveloper (which is rpc/literal) so that the server side generates the correct doc/literal WSDL.  Here is the implementation:

package com.doc.server;
import org.w3c.dom.Element;
import java.io.PrintWriter;
import oracle.xml.parser.v2.DOMParser;
import oracle.xml.parser.v2.XMLDocument;
import oracle.xml.parser.v2.XMLElement;
import oracle.xml.parser.v2.XMLPrintDriver;
import org.w3c.dom.Document;
import java.io.OutputStream;
import java.io.ObjectOutputStream;
import java.io.FileOutputStream;
import java.io.File;

public class XMLDataHandler {

// Method to publish as  a Web service
public void WriteXMLFile(Element XMLData) {
 XMLDocument doc = new XMLDocument();
 XMLElement el = (XMLElement) XMLData;

 // Turn the inbound Element back into an XML document
 doc.adoptNode(el);
 doc.appendChild(el);
 // Stick the <?xml version="1.0"?> on the output doc
 doc.setVersion("1.0");
 try {
   // Now write out the document to a file
   XMLPrintDriver output=new XMLPrintDriver(new FileOutputStream(new File("/home/oracle/temp/result.xml")));
   output.setEncoding("utf-8");
   output.printDocument(doc);
   output.close();
 }
 catch (Exception e)  {
   System.out.println(e.toString());
 }
}
}

I then generated the client from the server WSDL (in my deployment available at http://127.0.0.1:8888/ws/XMLDataHandlerService?WSDL) and then did two things in the stub - first, I read the XML from a local file assuming it was an XML document; second, I converted it to an XML element and sent it off to the service endpoint published above.   Here is the relevant bit of code that does the work - this is the main method within the stub generated from the WSDL called XMLDataHandlerServiceStub.

  public static void main(String[] args)
  {
    Element inXMLFile = null;
    try {
      // Instantiate the Web service stub
      XMLDataHandlerServiceStub stub = new XMLDataHandlerServiceStub();

      // Read in some arbitrary XML document
      DOMParser parser = new DOMParser();
      parser.parse("file:///home/oracle/temp/data.xml");
      inXMLFile = parser.getDocument().getDocumentElement();

      // Send the read in file data to the Web service endpoint
      stub.WriteXMLFile(inXMLFile);
    }
    catch(Exception ex) {
      ex.printStackTrace();
    }
  }

Not the prettiest code you've ever seen but it does the trick and gives hopefully the folks that are stumped with this problem a quick step up to a working example which can be easily enhanced to do things like schema validation, more efficient reads and writes etc etc.

Something to bear in mind with this approach is I had to read the entire document into DOM which can be a machine killer if your document is large; it is perfectly fine if your inbound file/document is small.  Larger documents likely need a different treatment - one being SAAJ.  For another day.

9:26:42 PM    

I thought Jonas Jacobi of Oracle's JavaServer Faces team had started and stopped his blog as the version I was looking at only had two entries.  I ran into him the other night and harassed him a little (not having much of a leg to stand on given my February output!) and found out he had moved his blog to Orablogs and has been blogging nearly daily since the move.  Those thinking about JSF should add it to their must read list.  Added to my Oracle blog list - check it out - http://www.orablogs.com/jjacobi. 

There seems like there should be an interesting intersection that bears exploration between JSF and XForms from a schema centric XML forms perspective:

1. XForms, XML schema centric forms standard.  BT B, Oracle has been doing some work with XForms in our wireless technology that bears exploration - a bunch of examples are here on OTN.
2. JSF - clearly aimed at easing the user interface development of J2EE developers.  There seems like there should be a very complimentary story to tell between XForms and JSF but I haven't seen knowledgable folks from both camps tell one yet.

Microsoft has embarked down this path schema centric forms development in a big way with  Infopath which is based on the same ideas as XForms though productized and now embedded in much of Microsoft's client technology.  See this comparison between XForms and Infopath.   They set the bar on this integration last week with a launch announcement of the pending production release of Biztalk 2004.

Why does a guy thinking about BPEL care about this?  Well, one of the missing links in the BPEL specification is the link to human interaction which consists of many different things (users and roles for instance) that will either need to be added to BPEL or to a complimentary product/specification.  One key feature of such support will be how to provide highly user friendly, interactive user interfaces for the schema bound documents that feed into and out of BPEL scenarios.

8:10:46 PM    

Last night I gave a crack at building a tutorial on using Eclipse, Lomboz and OC4J together. I was quite impressed ... rather than trying to mask the complexity of the underlying task, they tried to make the common tasks and activities that are there by the very nature of J2EE easy and straightforward. It had some rough edges ... that is why I am writing up the tutorial to save other folks a bit of pain ... hopefully by end of this coming week I will be done.

Simple example: when you are building, assembling and packaging J2EE applications many developers think in terms of JARs, WARs and EARs. This isn't an after thought, it is fundamentally how you work with your application. Not doing it this way can be confusing to J2EE folks. Lomboz does it exactly that way - from the start you are thinking in that context. Folks new to J2EE or unfamiliar may find this strange but it as soon as they pick up a book on J2EE, build their first real J2EE application or start maintaining an existing one, it will likely become pretty clear.

Here's a quick Eclipse/Lomboz screen shot of the launch tool where you can choose different J2EE artifacts to build.

12:20:42 AM    

A few months ago I wrote a simplified view of tooling for BPEL and divided the world up into roughly three categories - those who want to see BPEL, those who want to model BPEL and those who want to work at some level of abstraction beyond BPEL though semantically based on BPEL.

This article, Process Modelling Notation and Workflow Patterns, at Business Process Trends, authored by Stephen White out of the standards research organization of IBM, gives a pretty comprehensive comparison of the BPMN Business Process Diagram Notation versus UML 2.0 Activity Diagram notation out of the IBM standards group.  If you are in the midst of building BPEL tooling, this makes for a good read.

He does it in context of another well know article in the BPEL, Pattern Based Analysis of BPEL4WS  by Petia Wohed,  Wil M.P. van der Aalst and Marlon Dumas, who broke BPEL4WS into 20 different patterns and analyzed them against other process languages (and have a ton of other material on the patterns Web site of the Faculty of Technology Managment at the Technische Universiteit Eindhoven). 

9:42:37 AM    

Finally, it's out the door ... a lot of folks here at Oracle worked awfully hard to get it out.  About 17,900 or so Sun CTS tests passed along with our own massive regression suites - with the last two weeks filled with "squashing" the last bugs.  A lot of folks pretty happy it's done.   Check it out: 

http://otn.oracle.com/tech/java/oc4j/1003/content_preview.html

We have a variety of exit criteria and an obvious one is, are all the demos working including Sun's Adventure Builder application? We were feeling pretty good because we've had Adventure Builder .9x running since sometime around Christmas but then somewhere around mid-February we noticed that Adventure Builder 1.0 was out.  Same UI but architecturally a completely different application using all sorts of interesting features of J2EE 1.4.

A little bit of panic that close to release but OC4J came through with flying colors.  Debu Panda, the EJB PM on OC4J and general all round J2EE wizard, did a lot of the last minute "squashing" on that one including sending back a bunch of fixes to Sun (Steve Button, another of my teammates [who I believe reads J2EE specifications for entertainment :-) ] talks about one issue here).  The how-to for this, which for all intents and purposes is "ant deploy" with lots of words around it, should be available early next week.  

Nice to see the value proposition of J2EE illustrated but it would have been nicer if Sun had put it out a little earlier than exactly when we were getting down to the last minutes of our our release!

10:23:42 PM    

These two guys I think are having too much fun on the JDev team - Aspect Oriented Programming in JDeveloper from Gerard and topics all over the place like Tiger and the Magic of Synth   from Brian.  Fixed their links into my blogroll - check them out, they are doing cool stuff. 

10:11:44 PM    

Another break from blogging but I am back.   I've had a slew of side projects going on one of which has been getting a partner going with Oracle Lite so they could embed it into their product.   The other, coming up in another blog and eventually more official writeup for OTN is using Lomboz with Eclipse for OC4J. 

Anyway, because I know close to zero about Oracle Lite I became a customer of Oracle rather than a know-it-all about my particular area.

I had two requirements:

1. A light footprint database that ran on Windows and Linux.  Despite the 358 megabyte download on Windows and 256 megabyte download on Linux, the actual footprint of the Oracle Lite runtime on Windows is about 1.2 megabytes and on Linux about 3 megabytes. 

The reason for this size mismatch is that Oracle Lite really consists of a whole slew of features, one of which is a lightweight database for a ton of different form factor mobile devices as well as mainstream OS's like Windows and Linux.  This download has native kits for all sorts of mobile platforms, synchronization technology, queuing stuff, something called Branch Office etc etc. 

All I wanted was the database, as small as possible on Windows and Linux.

2.  It had to be accessible from servlets and EJB's on OC4J from a JDBC driver - thus my involvement as an OC4J PM.  

The first challenge was getting the big download to a minimum size.  The next was figuring out how the concept of a database listener on Oracle Lite worked.  And the last, the easiest for me, was hooking it up to OC4J.

Now that I have it going it is very slick and easy to use - but I have to admit, I did have some challenges getting here.  This is the purpose of this writeup - for my own record!  So here goes:

1. Download the zip file.  I chose the latest 5.0.2 release. Run the installer, on Windows setup.exe; on Linux runInstaller, and do a custom install.  On Windows install the Windows SDK.  This reduces the 358 megabyte footprint to about 38 megabytes.

2. Now you're ready to build your minimal distribution.  Here is the set of files you need - copy them into your new Oracle Lite distribution/runtime directory:

   createdb.exe

   msql.dll

   msql.exe - 'sqlplus' of Oracle Lite

   msql.jar

   OLAD2040.DLL

   OLADCL2040.DLL

   OLITE40.JAR (thin JDBC driver)

   olite40.msb

   oljdbc40.dll

   olobj40.dll

   OLOD2040.DLL

   olsv2040.exe ('tns listener' of Oracle Lite)

   olsql40.dll

3. You will have from the install a file polite.ini in the directory c:\windows or c:\winnt.  Edit it to point to your working directory and one of the Olite message file:

[All Databases]

DatabaseID=502

DataDirectory=c:\olite

NLS_LOCALE=ENGLISH

MessageFile=c:\olite\OLITE40.MSB

DBCharEncoding=Native

4. You are now ready to create a Oracle Lite database:

>c:\olite\createdb.exe mikedb c:\olite\mikedb.odb

5. Next make sure you have the ODBC registry entries for OLite.  Here is the screen shots of mine which I manually entered - first the node Software->ODBC->ODBCINST.INI->Oracle Lite 40 ODBC Driver:

and second the node Software->ODBC->ODBCINST.INI->ODBC Drivers->Oracle Lite 40 ODBC Driver:

6. On Windows, Oracle Lite uses ODBC, even if you come in through thin, type 4 JDBC, the Oracle Lite equivalent to Oracle mothership tnslsnr, converts those JDBC calls into ODBC calls - at least as I understand it.  So, we need to go into the Microsoft ODBC administrator and create a datasource for mikedb.odb.  You will find you have from the SDK install a user datasource called POLite ... you can alter that one or create a new one.  Here are my properties:

Datasource Name: mikedb

Data Description: Oracle Lite 40 Data Source

Database: mikedb

Default Isolation Level: Read Committed
AutoCommit: Off

Default Cursor Type: Static

Here is a picture of from the Microsoft ODBC tool: 

7. Now so you can handle incoming thin JDBC calls from your Servlet running on OC4J, start up the Oracle Lite listener - this is the part that had me stymied for a while:

>c:\olite\olsv2040.exe /debug  /wdir=c:\olite

In debug mode, above, errors will be output to the file olsv.log.  This listener can also be more usefully installed as a service using the command:

>c:\olite\olsv2040.exe /install

This service listens on port 100 for JDBC calls to data sources defined in the Microsoft ODBC Administrator.

One of the tricks with this is two things need to available on the path and classpath:

a.  <JDK_HOME>\jre\bin\server\jvm.dll has to be on the path

b. OLITE40.jar has to be on the classpath

8. Now you need to populate that database with something. Here is how to do scott/tiger:

>c:\olite\msql system/manager@jdbc:polite4@127.0.0.1:100:mikedb

SQL> CREATE USER SCOTT IDENTIFIED BY TIGER;
SQL> GRANT DDL TO SCOTT;

SQL> GRANT ADMIN TO SCOTT;

SQL> GRANT RESOURCE TO SCOTT;

SQL> COMMIT;

SQL> EXIT;

>c:olitemsql scott/tiger@jdbc:polite4@127.0.0.1:100:mikedb

9:28:28 PM