JMS testing with HermesJMS

HermesJMS is a handy tool that can be used to visually interact with JMS destinations (JMS Queues or JMS Topics).  I find it convenient for ad hoc testing of JMS applications.  I use it to monitor the status of JMS Queues, browse their contents, and to drop messages onto queues for testing purposes.  

When viewing a message in a JMS Queue, HermesJMS shows you the JMS headers and the value of the message payload, even if the payload is a serialization of a custom Java object.   For example, in my current consulting engagement, we had a situation where we had a bad message stuck at the front of one of our JMS Queues (and due to invalid configuration our app kept processing that same message over and over, rather than proceeding onto the next message in the queue).  Through the WebLogic Console we were able to see that there was a message in the queue that wasn't getting processed, but we couldn't see the actual content of the message that was causing it to get stuck.  By connecting HermesJMS to the queue we could view the message payload and as a result identify and fix the issue.

Browse Queue Contents

The screenshot below shows an example of what browsing messages in a JMS Queue looks like:

The table lists the JMS messages currently in the queue and the JMS headers for each message.  Below the table is then a text rendering of the actual payload (typically a serialized Java object).  In this example the payload is a Java class called HermesDemo with two properties, foo and bar (which I creatively concocted for this blog post :)


Drag Messages Between Queues

Another handy feature of HermesJMS is that you can easily copy messages between queues.  For example, if I click on the top message in the demo/Queue on my local machine I can drag it over to a queue in my testing environment (UAT):

HermesJMS asks me to confirm the action and then copies the message over.  HermesJMS will automatically handle any necessary mapping if the JMS Destination names differ between the source and the target queues.  I find this drag and drop feature quite handy for ad hoc testing JMS applications in multiple environments.  I produce a message on one of my local queues and then drag it as needed onto a corresponding queue in the environment I want to test.  

Build Message Stores

HermesJMS also has a feature where you can build so called stores; that work off of a database rather than an actual JMS destination.  Using this feature you can build a database of various JMS messages and have them ready for dragging over to a remote destination anytime you need to test a specific condition in one of your JMS applications.

XML Export/Import

Alternatively HermesJMS allows you to export messages to XML files, for later import into queues/topics. To do this, you simply click on a message in the queue and select Save as XML... from the Messages menu, then give it a file name and hit save.  To import the message to a queue you click on the JMS Queue and select Send XML Encoded Messages from the Messages menu and then select the XML file to import from on your hard drive:

Note: if the JMS Destination name does not match between the source and target queues you will need to edit the XML and update the value to match that of the target queue.  

In our example the exported DemoClass.xml file looks like this:

where the value of the object tag is an object serialization + Base64 encoding of the following Java class:

When you export a message from a Queue to XML, HermesJMS handles the serialization magic for you and writes it out to the XML file.   If you want to create a new XML message from scratch (e.g. when adding the first message for a queue), you can build the serialization string using the SerializeHermesDemoClass in my Github repo (just modify the main method to use whatever class you want to serialize).

Setup Instructions

Below are basic instructions for getting HermesJMS set up.  In my case I am using WebLogic as the application server.  Setup for other app servers is similar; you just need to use the ContextFactory and jar files specific to that app server.  If you go to hermesjms.com you will find setup instructions for many app servers under the Providers menu.

1. Download and install HermesJMS, either directly from Sourceforge or as part of SoapUI install.
2. Start HermesJMS by running hermes.bat/hermes.sh.
3. Create a ClasspathGroup for your app server jar files 
1. Select Option and Preferences
2. Click on the Providers tab
3. Right-click on Classpath Groups and select Add Group and give it a name (e.g. JarDependencies)
4. Click the + sign and right-click on Library and select Add Jars and find the jar files you want to import.  In our case that is weblogic.jar, wlclient.jar, and HermesDemo.jar, which has the custom Java class used in our demo.  If you want HermesJMS to show the contents of a custom Java object in your JMS Queue, it needs to have the corresponding class file on its classpath.  You can either add the jar here, or alternatively edit hermes.bat/hermes.sh and add it where the CLASSPATH variable gets set.
   
4. Next we need to create a Session for JNDI browsing the JMS server 
1. On the Preferences screen, click the Sessions tab.
2. Give the session a name, corresponding to the JMS server you are pointing it to.
3. Select the Plug In matching your app server.  In our case it is BEA WebLogic.
4. Under Loader, select your JarDependencies and under Class select hermes.JNDIConnectionFactory.
5. Populate the binding, initialContextFactory, providerUrl, and security properties as appropriate for your app server.  For WebLogic the properties are:
   
6. If the destination names don't get auto-populated, right-click under Destinations and add the names of JMS Queues/Topics you want to connect to on the JMS Server.

Note: If you are using WebLogic you can alternatively download this pre-populated hermes-config.xml file and put it in your .hermes directory (replacing the default one that HermesJMS puts there during install).  Before you run HermesJMS make sure you edit the file and change the following:

• Update the providerUrl value to match the server and port of your JMS Server.
• Set the securityCredentials and securityPrincipal values to mach your username and password.
• Edit the library paths for JarDepdencies and make sure they point to wherever you have these jar files on your machine.

In Conclusion

I hope this overview and these setup instructions help you get going with HermesJMS.  Once you have it working, interacting with your JMS destinations is a breeze, and testing a given JMS app can be as simple as a drag and drop.

If you need to run a suite of JMS tests, e.g. for sanity testing or load testing, you can use SoapUI, which knows how to interact with HermesJMS.  I may write a future blog post demonstrating this integration.  For SoapUI basics, see this blog post.

All the examples used for this blog post can be seen in this Github repo.

Happy JMSing!

How do you explain Java technologies to non-technical audience?

Today I had the interesting challenge of trying to explain various Java buzzwords to people with very little technical knowledge.  Basically, we wanted our talent managers (recruiters) at Quick Solutions to gain a high level understanding of some of the Java technologies they recruit people for.

In prepping for this presentation I put on my "simplification hat" and tried to think of the essence of some of the more popular Java technologies.  I wanted to leave the talent managers with a simple visual picture in their minds, that represented the benefits of each technology.  Then I followed each of those visuals up with a basic architecture diagram that explained how the technology fits into a typical application.  I also gave them sample questions and answers for each technology, all focused on the high-level benefits of each technology (which problems the technology is meant to solve).

At the beginning I also went over some of the reasons I love being a consultant, and how to use those to attract talent.  I basically walked through the bullet-points in this blog post.

The general feedback I got was that they were able to follow along and they found the information very helpful.  I suspect though I may have lost a few of them near the end, when I got onto design patterns :)

Below are some of the more visual slides from my presentation.  The full slide deck is available on Slideshare.

What do you think?  Did I pick the right visuals?  Could I have made it even simpler?

Visually Import SSL Certificates to Java Keystores

Working with SSL certs in Java, in particular those self-signed ones frequently found in dev & QA environments, usually means dealing with the command line keytool that comes with Java.  Either to add a certificate to a keystore (JKS file) or to add a new certificate authority to your truststore (cacerts file).  If you are tired of reading the keytool help or googling what the exact import command looks like (and have forgotten it in the year or so since you last had to deal with it), I recommend the GUI tool Portecle.  It makes it very easy to view the contents of a keystore/truststore file and to import new certificates, and it allows you to download public certificates right from within the tool.

To add a public key certificate to a keystore, open up the JKS file in Portecle, select Examine SSL/TLS Connection and type in the hostname and port number of the https site you would like add certificate from.  Then hit the PEM encoding button and save the certificate to a file.   Next click the Import Trusted Certificate button and select the file you exported and hit save.  That's it!

To add a trust for a new certificate authority in your truststore you open up your cacerts file (password most likely 'changeit') and add the CA certificate file via the Import Trusted Certificate button.  You will need to locate the CA certificate file on your app server and convert it to PEM format if it is not already in that format.  For example in WebLogic the CA file is located in the [WebLogic Home]/server/lib directory (CertGenCA.der by default).  In IIS you can export the CA file to PEM format through the IIS Management Console.  After importing the CA file to your cacerts file your JVM should trust certificates issued by that CA.

Jfokus Conference

This week I had the pleasure of attending the JFokus conference in Stockholm, Sweden.  This was a gathering of some 1250 Java geeks and some excellent speakers.  I thoroughly enjoyed sessions by Arun Gupta, Guillaume Laforge, Mario Fusco, Henrik Kniberg, Neal Ford, and many others.  Here are some of the technologies that caught my attention and I will be considering putting to use at my current work on the Eplica CMS system.

• Lambdaj - This library is just brilliant and really simplifies working with Collections.  Write more readable code in fewer lines.  Stop writing loops!  Mario Fusco's slides.
• CKJM - Use this library to intelligently pick areas of your code base to refactor.  To get bang for your buck you want to pick classes with high Cyclomatic Complexity and high Afferent Coupling.  That is, complex code in frequent use.  Comes as part of a Sonar plugin.  And BTW, if you are not already using Sonar, use it!
• Groovy - I have been intrigued by this language for some time now but never actually put it to use in my work.  I think it is time to change that.  Groovy to me is a natural progression of the Java language.  Making the boring/tedious parts of Java optional and adding syntax improvements and useful features like closures.  The kind of changes you might envision seeing in Java 10 or somewhere way down the road.  Why wait so long?
  As a starting point I am thinking about using these Groovy frameworks for our web based testing:
• Geb - Browser automation framework based on Selenium.
• HTTP Builder - A convenient API for complex HTTP requests.
• WADL & Jersey - When consuming/publishing RESTful web services from/to our customers I prefer to have a contract to work by.  WADL is just that and Jersey an API (JAX-RS 1.1 implementation) for creating/consuming REST services.
• JDK 7 - Obviously eagerly awaiting that one.  Planned GA date July 28, 2011, according to Tomas Nilsson at Oracle.

Other technologies I found interesting but don't envision using in the near future (just not a good fit for Eplica CMS): Scala, Clojure, deploying to the cloud,  NoSQL, Vaadin and DDD.

All in all a great conference which I highly recommend to Java developers.

Photos from the trip

Tweets

CodeMash 2009

I just got back from CodeMash 2009. This is my third year going there and it keeps getting bigger and better. The quality of speakers is high and so is the quality of attendees. It seemed like no matter who you sat next to at breakfast, lunch or dinner they all had something interesting to say and a wealth of experience to share. Having my family there with me was the icing on the cake. They played in the water park or did some of the Kalahari activities during they day, while I was getting my techie fix and then I joined up with them in the evenings for some fun in the wave pool or a stroll down the lazy river. Hats off to the organizers of this conference. For those of you not familiar with CodeMash, it covers a broad spectrum of programming languages and technologies, and its 'focus' is essentially to diversify. That is, get you out of your comfort zone and learn about what is happening in other tech communities. This year they had sessions covering in one form or another Ruby, Scala, Erlang, C#, F#, Objective-C, Java, Groovy, Python, ActiveScript and PHP! On top of that they had various sessions on improving software development, including sessions on Agile, Lean software development, value stream mapping and Kanban. I highly recommend this conference to any developer. For the low registration fee it is a steal.





Below is a sprint through the sessions I attended this year.

Day 0 - PreCompiler

Groovy and Grails 101 w. Chris Judd and Jim Shingler

This was a good overview session on Groovy and Grails. Groovy in the morning, Grails in the afternoon. Chris did a good job of explaining all the things that suck about Java, by showing a Java class and then piece by piece groovy-tizing it down to less than half of its original size. The last lab of the morning involved writing code to read an RSS feed and write the ids and title of all blog postings to a relational database, then pull it back from the db and spit out as an XML document. We did this in about 40 min, and I have to say that even with all my Java experience I doubt that I would have been able to pull the same off with Java in that amount of time. Reading from an http url, extracting info from an XML document, writing to a database, reading from a database and creating an XML document was all very easy in Groovy and required very few lines of code. Here is the code that did it:

import groovy.sql.Sql

//Read the RSS feed
def feed = new URL("http://stanjonsson.blogspot.com/feeds/posts/default").text

//Create a database instance
def sql = Sql.newInstance(/jdbc:derby:C:\temp\blogs;create=true/, "APP",
                      "APP", "org.apache.derby.jdbc.EmbeddedDriver")

//Delete table if previously created
try {
   sql.execute("drop table blogs")
} catch(Exception e){}

//Create table
sql.execute('''create table blogs (
    id varchar(200) not null primary key,
    title varchar(500)
)''')

//Parse XML and populate the table
def blogs = sql.dataSet("blogs")
feed = new XmlSlurper().parseText(feed)
feed.entry.each {entry ->
  blogs.add( id: entry.id.text(), title: entry.title.text() )
}

//Read from table and create Xml
def writer = new StringWriter()
def builder = new groovy.xml.MarkupBuilder(writer)
builder.setDoubleQuotes(true)
builder.feedlist {
    sql.eachRow("select * from blogs") { row ->
        feedentry(id:row.id) {
            title row.title
        }
    }             
}

//Print out XML, and voilà, done!
println writer.toString()

Pretty easy heh? No try-catch blocks, no headaches around setting up and closing database resources, no InputStreams, no importing an external XML parser. And the code even creates the database and table on the fly!!

For those curious the output from running the above is:

<feedlist>
  <feedentry id="tag:blogger.com,1999:blog-2241013152284479770.post-720388331940374029">
    <title>No Fluff Just Stuff 2008</title>
  </feedentry>
  <feedentry id="tag:blogger.com,1999:blog-2241013152284479770.post-1855527957885191012">
    <title>Career 2.0</title>
  </feedentry>
</feedlist>

Which, hehum, proves that I really need to be more active in my blogging.

During the afternoon session we went over the Grails framework, which is highly reminiscent of Rails. Jim showed us how to quickly put together a web site by defining a couple of domain objects and having Grails do its magic by generating the persintance layer and database tables and a nifty front end for CRUD operations on the domain objects. It looked really nice, but started loosing some of its charm once he started mocking with the view GSPs and we came to realize it effectively made any further auto-generation from the domain objects impossible (or you would overwrite your changes). So the lesson learned is to put detailed thought into designing your domain objects up front and save your self some work by having Grails auto-generate your views, controllers and persistence layer (via GORM, a Groovy object relational mapping implementation on top of Hibernate). But know that once you have put some work into customizing your application any changes to your domain objects means you will need to edit your views, controllers and database mappings by hand.

Here are the slides from the PreCompiler.

Day 1

Introducing iPhone SDK - Chris Adamson

This was a session had been looking forward to a lot. I have been a trusty iPhone 3G owner since it was released last July (I even stood in line before stores opened the day it was released!) and have been eyeing getting into iPhone development. The session provided a good overview of what it takes to get into iPhone development and walked through the implementation of a simple application. Unfortunately the starting cost is somewhat high; get a Mac, learn Objective-C, pay for a development license, deal with Apple's registration process, write your app and wait for up to month to get it approved. Objective-C is a Smalltalk inspired C like language dating back to 1986. I must admit that manual memory management and pointers aren't exactly things I have missed for the past 10 years or so. So delving into Objective-C is something I'd do with some hesitation. Actually, Chris Judd's iPhone with Grails presentation on Day 2 got me thinking I might start by doing an iPhone web application rather than native application.

Slides from the presentation.

Three tips to improve your dev process - Jim Holmes

Former Quick Solutions colleague Jim Holmes had an interesting talk on things we can do to improve our software development processes. He discussed the importance of daily standups and retrospectives, and provided tips to improve estimation. The session was mainly memorable for the somewhat heated discussion that materialized between Jim and a few of his audience members, headed by Mary Poppendieck, who as Jim put it "lead him out on a branch and then proceeded to saw it off".

Slides to be posted at FrazzledDad.com.

Erlang: The Basics - Kevin Smith

Very interesting session and by far the one that made my eyes spin the most. As Kevin put it "Erlang Is Weird". If you can not imagine life without for-loops, while-loops or strings, then Erlang is not for you! I enjoyed getting familiar with the language, but to be honest, don't see myself as a hard core Erlang fanboy anytime soon. But due Erlang's strength in dealing with concurrency I imagine the language will continue to prosper in a world where 256 core CPUs will soon be a reality.
Since there are no loops in Erlang, recursion is the name of the game. Here is a simple Erlang code to print out the contents of a list:

print([H|T]) ->
  io:format(“~p~n”, [H]),
  print(T);

print([]) ->
  ok. 

I found it interesting that the language has three (!) line terminators (, ; and .), when most of the new generation languages (Ruby, Python, Groovy, Scala, etc.) have gone the route of dropping terminators.

Slides here.

iPhone development with Grails - Chris Judd

Another session I was looking forward to. Chris walked us through the pros and cons of doing native vs. web application development for the iPhone. The pros of native development being:

• Access to native features like GPS, accelerometer and camera.


• Offline access.


• Performance.


• The glamour and marketing associated with having your app in the AppStore.

The pros of web app development being:

• Don't have to learn Objective-C. You can develop with whatever technology you are most comfortable with.


• Deployment under your control.


• Don't have to get a development license.


• Don't have to bury yourself in a mountain of legal agreements.


• The process is on your timeline and not Apple's

Chris then walked us through developing an iPhone web application using Grails with a custom iPhone plugin that he wrote for the iUI JavaScript framework, which allows you to customize the look and feel of your web app to rival that of a native application.

I have been brewing an idea for an application that I would like to write for my phone. Since the benefits of writing it as a native application are limited and clients will require access to a centralized database, I am making it my mission to write it as a Grails web app in 2009. I even went ahead and registered the domain goodweatherlocator.com just now, which should give you some idea about what I am planning to build.

Slides from the session here.

Sexier Software With Flex - James Ward

This was an overview session on how to build applications using Flex. It showed some pretty sexy Flex applications and then walked us through the creation of a basic Flex app using MXML and ActionScript.

I have never been very interested in RIA development, but figured I would at least dip my toe in the pool.

If you are unfamiliar with Flex, check out the tour at http://flex.org/tour.


Day 2


Practices of an Agile Developer - Venkat Subramaniam

As in his keynote a day earlier Venkat was excellent in this no frills Agile session. He provided many good tips on how to get into Agile and how to practice Agile software development, along with some gold nuggets on how to improve yourself as a software developer:

• The most important thing in adopting Agile is attitude.


• Criticize ideas, not people. Take pride in arriving at a solution rather than proving whose idea was best.


• Learn everything about something and something about everything.


• It is very hard to learn if don't learn continuously. It is incredibly easy if you do it all the time.


• Spend 30 min a day reading something unrelated to your current job.


• Present details and let your customers decide. Developers, managers or business analysts shouldn't make business critical decision - let the business owners make those.


• Run your unit tests on all platforms you plan to support.


• Use standup meetings to keep the team on the same page.

No slides, but Practices of an Agile Developer by Venkat and Andy Hunt a recommended reading. A colleague of mine won a copy of it at the closing ceremony and from my 5 min of browsing through it looked very promising.

Cool Stuff With computer Vision - Scott Preston

Scott showed us his robot Feynman and how he sees the world. Apparently robots are really into Jessica Alba because much of the presentation focused on a beach photo of her, seen through various image filters. When he showed us how his bot can discover and zoom in on her breasts, I noticed the lone female in the room moved uncomfortably in her seat.

All in all this was an entertaining session that gets a 10 on the geek scale.

Slides and photos of Jessica's top here.

Spring 3.0 MVC - Ken Sipe

A nice overview of Spring MVC (mainly 2.5 features) and all the benefits it provides over older MVC frameworks like Struts. Takes "convention over configuration" to the max and greatly reduces the amount of Java code needed for a typical Web application. Or as Ken put it, "The next best thing to Grails"!

Slides to be posted here.

Cloud Computing with .Net - Wesley Faler

The last session of the conference. I figured I couldn't go home without seeing at least one .Net related presentation. Wes walked us through the Cloud Computing concept and how it differs from web farms, grids and clusters. The nuts and bolts of it is essentially computing resources on demand. He got me all excited when describing Amazon's EC2 service and the fact that you can use it with numerous different programming languages. But once he gave us some samples of the pricing, my excitement withered away.

Fancy slides here.

This wraps up my CodeMash 2009 experience. As in previous years I had a lot of fun and will definitely be looking to coming back again. From what I've heard CodeMash 2010 will be even bigger and better.

No Fluff Just Stuff 2008

I just finished attending the 2008 No Fluff Just Stuff conference in Columbus, Ohio. It was a lot of fun, had some informative sessions and as expected these days some pointless fights over language syntax. Here are highlights from some of the sessions I attended.

10 Things an Architect should know

Speaker: Richard Monson-Heafel

This session was a good eye opener for getting your head out of the sand. A one-liner summary would translate to something like: Stop wasting time arguing about implementation details and start focusing on customer needs!

Below is some paraphrasing of the top 6 noteworthy things I got out of Richard's top 10 list.


People are the Platform

User interface is the most important part of your system. The point of IT is to make people more productive not to write beautiful systems. What happens underneath the hood is really not that important, as long as it works. A great UI on top of ugly middleware is much better than bad UI on top of pretty middleware.

All Solutions are Obsolete

When picking technology, pick what works best today, don’t try to predict the future.
For example a couple of years ago a lot of people banked on JSF becoming tomorrows golden standard, and are now suffering (to some extent). You can’t really predict what is going to be the popular in the future. Just pick what works best today and stop worrying about future proofing your system. There is no such thing as future proofing... it is a myth.

Data is forever, everything else can change

IT architecture keeps changing, but the data (often) lasts forever.
With that in mind Richard promoted the use of relational databases, as opposed to object databases or XML databases, which are tied to a specific technology. Likewise Richard took some shots at Rails & Grails, for probably getting things wrong in the long run. Basically stating that we should not have systems be generating our databases. We should build the database first to meet the company needs and then the systems on top of the databases. 5 years from now the database might still be there but everything else has changed.

I can agree with this to some extent, as I have had some bad experiences in the past working with tools that try to autogenerate a database based on some higher level entity. Usually what gets generated is somewhat of a mess and not easily reusable by other systems at a later time. On the flipside though, the productivity gains of newer development frameworks make them hard pass on. We just need to be mindful of taming them to some extent to generate maintainable databases.

Flexibility Breeds Complexity

Simplicity can create flexibility, but flexibility will always create complexity.
When designing a system always err towards simplicity.
Building a simple system and adding features to it later probably costs you less in the long run than building a super flexible system upfront to handle all possible future changes.

Know The Business

As a software architect you are in the tough position of having to be an expert on all things related to the technology of the company, but just as importantly you need to know and understand the business of the company you work for. You need to know the business as well as the business people! Remember, it is your job to make the business people more productive. If you don't understand what they do, then how can you help them?

Software Architects Should also be Coders

Get out of your ivory tower and into the trenches. Bits talk, Bulshit walks.
Every architect should spend at least 10% of their time doing code reviews with the engineers building their product. That’s how you see what is working well and what is giving people headache. Pull up a chair and sit next to a developer for an hour. In addition to getting a better feel for what the developer is dealing with you'll be surprised at how hard he/she will work during that hour! :)


So You Have Been Promoted to Tech Lead. What do you Do.
Speaker: Mark Johnson

This session brought up some useful points for us Tech Leads to think about.
A few of them were:

• Requirements Acceptance Criteria
• 66% of requirements have no business value
• When you are on a project that gets flooded with new requirements, try to put each one of through the following pick list:
  
  Any requirement that ends up in the "Kill" category you should bring back to the business (or product owner) and explain your case for getting that requirement dropped. On the flip side be more open to requirements that have high business value but low complexity, risk and cost. If you can get some of those in, in favor of throwing out a couple of "killers" you might make your project more likely to succeed, even though business people keep wanting to change things on you. Also, don't just automatically say no to every new request (over defend you project). Evaluate it via the above pick list and try to work out what is in the best interest of everyone involved.
• Delegate
  (This might have been the hardest thing for me to learn when I stared doing tech lead work)
• Stop playing superman! Don't assign all the hardest tasks to yourself. You won't have time to implement them properly. Trust your developers and they will usually reward you.
• Don't go to every meeting! In most meetings nothing noteworthy happens. Delegate attending some meetings to your teammates.
• Once you come up with a plan, share it with everyone
• Make sure you have peoples buy in to what you are planning to do. If you run into trouble later people will be much more willing to help you out if you included them from the beginning.
  

Getting Started with BPEL
Speaker: Mark Johnson

I have to admit that this session sent a few gusts of cold shivers down my spine. I did not know much about BPEL and was kind of curious to see what the fuss was about. After doing some preaching about BPEL being XML driven and one of its design goals being "Not to define a graphical representation of processes", a few slides into the presentation Mark brought up the NetBeans BPEL IDE. To my shock I found myself staring at something that looked an awful lot like a WLI JPD (WebLogic Integaration Java Process Definition)! It tied together several web services in an elegant looking flow diagram, with forks and splits and what have you. Even some visual transformations of data from one web service passed to another. Now, for anyone not familiar with the JPD technology, it tries to do pretty much the same thing, basically tie together multiple service calls and transformations in a nice looking flow diagram. On the surface it sounds great, but my actual experience in dealing with the JPD technology has brought about multiple frustrations:

• The flow through your JPD is written in a custom XML language which ties back to autogenerated Java code that programmers are discouraged to change
• It breaks many key OO concepts such as
• No encapsulation (everything that holds data is a public global variable in the JPD class),
• No inheritance. Two JPDs for similar services are pretty much a copy-paste of eachother.
• One business method per JPD. There is only one entry point into your typical JPD.
• Some of the JPD UI language concepts don't work as expected
• For example the JPD Parallel node, which is meant to call multiple services in parallel and then wait for all to finish before proceeding onto the next node in your flow. After some hair pulling I discovered that actually doing things in sequence rather than parallel resulted in much faster code! The parallel node ends up spawning a new thread for each service call, which can be very taxing on your app server resources.
• When writing JPDs, a lot of time is spent trying to figure out how to get something working, as opposite to focusing on writing business logic.
• You never really know what is going on underneath the hood.
• WebLogic claims that you don't need to know anything about how the JPDs are implemented. But in actuality you will run into problems that require you to understand what is really going on when your JPD is being executed (like with the parallel processing nodes) . Over time you will come to realize that underneath all the glory you have a ton of autogenerated EJBs and JMS messages hard at work, but little documentation on what is really taking place.
• Most JPDs are hard to read, even for developers!
• The idea of JPD being a great tool for you to communicate your process to business people was not my experience during the couple of years I used the technology. Most of our JPDs ended up being complicated and convoluted, and we found ourselves using sequence diagrams as a more useful tool to communicate design to our business analysts. Over time we learned to simplify our JPDs, but even so I never saw them being used much when communicating with the business.
  

Now I am not saying that BPEL necessarily suffers from the above problems. It might have an awesome implementation and myriad documentation. I have no idea. But when I asked Mark point blank if his developers enjoyed developing in BPEL and whether they had any complaints, and he ended up admitting that most of them preferred pure Java, I got my answer.

At the end of the day I decided to apply a duck typing analogy on BPEL. If it acts like a JPD and quacks like a JPD, then it must be a JPD! :-) I hope I will not have to deal with this technology in the future.