Choosing an Enterprise Service Bus (ESB) Product

 

Which Enterprise Service Bus (ESB) product you evaluate and choose will depend on your exact ESB requirements, your budget, and any existing vendor relationships or products, but according to Forrester (and me), you might want to at least look at the following ESB products:

Commercial Enterprise Service Bus Products

• Software AG Webmethods Integration Server
• Tibco Active Matrix Service Bus 
• Oracle Enterprise Service Bus
• Progress Software FUSE ESB
• IBM Websphere ESB

Open Source Enterprise Service Bus Products

• Mule Soft Mule ESB
• WSO2 
• Apache Service Mix
• Apache Camel

As an aside, Spring Integration  provides an easy entry into the world of ESB concepts, providing a single instance, easy to use integration container with many ESB-like features.  Regardless of which ESB product you end up with, I would consider, assuming you're using Java, decoupling your code from the underlying ESB or low-level protocols using Spring Integration.

Read More

Migrating Weblogic to JBoss (4)

Ok, so now you have some fairly respectable, though not yet perfect, style sheets, but how do you apply them to hundreds of deployment descriptors, potentially repeatedly as you refine the stylesheets?

Ant, is the simplest answer. Ant is widely used to build and deploy J(2)EE applications and includes a very hand XSLT task which fits the bill perfectly. For .Net-ers, there is NAnt

For example...

Read More

Migrating Weblogic to JBoss (3)

My XSLT skills are coming on pretty nicely, but the real battle in all of this is finding equivalent features for those Weblogic application server specifics that we've used. So far I've been able to map most features 1-1 between the respective deployment descriptor files, but today I encountered one that doesn't fit this pattern. In Weblogic, entity-cache is in the weblogic-ejb-jar.xml, whereas in JBoss its equivalent is in the jbosscmp-jdbc.xml not jboss.xml, so XSTL becomes tricky.

I'm also pondering moving to XDoclet since it would allow us to maintain one source going forward and still target multiple application servers, but that would mean redoing all our Weblogic descriptors and involves some element of risk, particularly as I'm not certain all the features we use are covered by XDoclet.

If you've not used XDoclet before, it allows one to embed deployment configuration within Java and then generate XML deployment descriptors using an Ant task. For example see below (notice the use of @ejb, @jboss, @weblogic and @websphere tags.) An additional benefit of this approach is it enables one to see clearly which open and which app server specific JEE features are being used.

/**
* This is a teller bean. It is an example of how to use the XDoclet tags.
*
* @ejb.bean name="Teller"
* description="Teller example bean"
* jndi-name="ejb/bank/Teller"
* type="Stateless"
*
* @ejb.ejb-ref ejb-name="Account"
* ref-name="ejb/bank/Account"
*
* @jboss.ejb-local-ref ref-name="File"
* jndi-name="blah/File"
*
* @ejb.ejb-ref ejb-name="Customer"
*
* @ejb.security-role-ref role-link="Administrator"
* role-name="admin"
*
* @ejb.permission role-name="Teller"
* @ejb.permission role-name="Administrator"
*
* @ejb.transaction type="Required"
* @ejb.transaction-type type="Container"
*
* @ejb.resource-ref res-auth="Container"
* res-name="jdbc/DBPool"
* res-type="javax.sql.DataSource"
*
* @jboss.resource-ref res-ref-name="jdbc/DBPool"
* resource-name="MyDataSourceManager"
*
* @jboss.container-configuration name="Standard Stateless SessionBean"
*
* @jboss.ejb-ref-jndi jndi-name="ejb/bank/Account"
* ref-name="bank/Account"
*
* @weblogic.pool initial-beans-in-free-pool="1"
* max-beans-in-free-pool="3"
*
* @weblogic.stateless-clustering stateless-bean-call-router-class-name="Whatever"
* stateless-bean-is-clusterable="True"
* stateless-bean-load-algorithm="Whazzup"
* stateless-bean-methods-are-idempotent="Sure"
*
* @websphere.bean timeout="239"
*
*/

Read More

Migrating Weblogic to JBoss (2)

Hmmm, I may have spoken a tad early.

The XSLT scripts I found only translate the very basic deployment descriptor elements. The remaining elements are usually of the vendor-specific performance optimisation type which often don't have a 1-1 equivalent, if they have one at all.

The JBoss community forums are very quiet on these fronts. Perhaps there is a conspiracy to drive me to JBoss.com's migration programme...

Grumble.

Read More

Migrating Weblogic to JBoss (1)

This is the first in a series of posts on the joys of migrating our JEE application from Weblogic to JBoss. Being JEE it should be trivial right? ;-)

The steps so far...

1. Stripped out a couple of EJBs from our application to port as a POC
   
2. Jboss download from jboss.org and installation was very quick and painless.
   
3. Read some of the documentation which is fairly good, and fine when supplemented with Google, but not as good as Weblogic's
   
4. JBoss runs pretty much out of the box and is very quick. Needs Sun JRE - it didn't like JRockit (which is bundled with Weblogic)
   
5. Setup Oracle datasources (non XA for now) and message queues and topics. Found the documentation clear as mud and had to get help from examples
   
6. Rebuilt our JEE application against the Sun JRE and JBoss EE library and found that we were using some Weblogic classes. No more.
   
7. Found a free set of XSLTs to transform our Weblogic EJB deployment descriptors to JBoss. Worked mostly but needed some manual tweaking. I'll fix the XSLTs sometime.
   
8. Dropped our application EAR in to the deploy folder
   
9. Started JBoss
   
10. Removed the CreateException from our MDB ejbCreates. JBoss complained rightly that these violated the EJB spec and even gave the section number! How cool is that?
    
11. Changed the JNDI properties in our application configuration files
    
12. Application deployed pretty much first time which surprised me no end
    
13. Ran a little test and got some cryptic SQL error (Invalid scale size. Cannot be less than zero) which after much hunting turned out to be an Oracle-Sun JDBC incompatibility issue resolved by using -Doracle.jdbc.J2EE13Compliant=true on the server
    
14. And that was pretty much it folks!
    

J(2)EE rocks and vendor extensions don't! Fortunately our app was built with portability in mind so it should have been this easy. Porting was an interesting exercise and much nicer than Powerpoint architecture for a change.

Initial JBoss impressions? Very favourable (apart from the imperfect documentation).

Now I have to get a cluster running and test messaging, but a cup of coffee beckons. first.

P.S. Happy to share some of the details with you if you email me

Read More

Lightweight Enterprise SOA Platform!?

According to SOA World, Red Hat Will Realease JBoss Enterprise SOA Platform 4.3 and JBoss Operations Network 2.1 At the End of the Month.

My mouth is watering already, though you do have to wonder at anything that is claimed to be a "Lightweight Enterprise SOA Platform" ;-)

Read More

JBoss

I have in the past worked on Websphere and now Weblogic JEE application servers and fortunately never had to port between the two. Just porting from one version of a product to the next is difficult enough, never mind a cross product port! I have found Weblogic to be a fine product, certainly much easier to learn and use than Websphere, but its not cheap, and one of our prospective clients has raised the question of running on JBoss which is of cours open source.

“No problem!” our sales people cry and I wince. JEE is a fine thing in theory and certainly gives you a hope of porting whereas .NET gives you no such hope at all, but the problem is in those little extras that the vendors give you for competition's sake.

So I worry about those JEE implementation variations, some obvious like the Weblogic deployment specific files, some more subtle, like the way CMP works, and I worry about whether JBoss' messaging and clustering will be as tidy as Weblogic's.

So I've downloaded JBoss and will be giving it a go. Hopefully there are some migration guides and even tools out there to simplify my task, but I'm expecting tears and further hair loss.

What's worse is that I'm dying to get rid of all our EJBs, introduce Spring and Hibernate, and run in a servlet container rather than full a blown application server. That would certainly be much more portable, since with Spring you are essentially taking your application container with you. Of course then you are tied into Spring...

Read More