Friday, April 18, 2008

I would like to reply to Ross Mason's article titled JBI Misses the Mark. It was too hard to include this in a comment, so I decided to post my reply here.

Ross,As a JBI Component Developer and user of ServiceMix and OpenESB I am going to try my best to give some answers to your points with the goal of discussion and not persuasion. I am not a "die-hard" fan trying to push JBI adoption. So hopefully I will come off as unbiased and honest as possible.

"It’s been a few years since I read the JBI specification, but here goes."

As evidence by the different ways JBI was implemented by Apache and Sun, just reading the spec alone I think is not sufficient to disregard JBI. For example, I remember when I first read the spec and looked at ServiceMix, I was totally confused. I was asking myself, where are all the WSDLs? Most of the comments I have read from JBI opponents have usually just read the spec or heard from co-workers and have actually never used or seen JBI used. Now I am not saying this person is you Ross; you have obviously done your homework. I believe the biggest failure of JBI has been communicating clearly what JBI is and how to use it. It took me many months until I felt like I actually "understood" JBI. And before that moment happened I thought I knew what JBI was only to find out something new and that I never actually did.

"Adaptive Integration"

Unless I misunderstood it, your definition of Adaptive Integration fits well with my experience with JBI. Using JBI I can build "best-of-breed" integration solutions using any number of the JBI components available with ServiceMix (SM) or OpenESB (OESB). If I need to integrate with JDBC I can do that; or RSS, XMPP, SIP, Corba, and CICS. Perhaps my lack of knowledge of Mule capabilities is making me naive here, but to me I can use JBI to bridge multiple systems together.

"JBI attempts to standardize the container that hosts services, the binding between services, the interactions between services, and how services and bindings are loaded. The problem occurs when the APIs around all these things makes assumptions about how data is passed around, how a service will expose its interface contract and how people will write services."

In a nutshell the only thing I think JBI standardizes on is the interactions between components or put another way the format of a message that goes over the NMR. Beyond that its up to the component developers to do what they wish. For example, with the RSS BC, there are no assumptions that need to be made about incoming requests from the NMR; it's a standard JBI message. Doesn't matter if it came from a SIP, HTTP, Corba. To me that is the beauty of JBI. Once I create my JBI layer in my component anybody in the container can call me.

"Xml messages will be used for moving data around"

As stated above, JBI doesn't say if your legacy system doesn't know XML, then you can't use JBI. The exact opposite is true. To me this is the perfect fit for JBI and Binding Components. My definition of a Binding Component is a translator. It's sole job is to translate protocol X to JBI and translate JBI to protocol X. Perhaps what you are suggesting is that some message types don't "convert" easily to XML since that is what essentially messages over the NMR are. So in your example, a Cobol CopyBook message can't be or shouldn't be attempted to be converted to XML. Not sure I would agree since I would think, given a schema, anything could be represented in predictable XML.

"Data Transformation is always XML-based"

Since everything is converted to XML to be passed over the NMR, the only transformation needed for that is XML. So what you is true, but to a JBI user I guess it doesn't matter. I guess on the other side, if the NMR allowed for other message types, then yes I guess you would need more transformers, but I guess with JBI the transformers are the Binding Components.

"Service contracts will be WSDL"

This is a very true statement and I am not exactly a WSDL/XML lover; unless I don't have to deal with it. I think the original intent was there would be a lot of tooling support for JBI to alleviate that burden from the JBI user. To me Sun has done a better job of this than SM, but this is definitely a drawback to JBI. However SM has all but eliminated WSDL's in JBI so users of SM don't need tooling support since they don't actually require WSDLs.

"No need for message streaming"

Another very true statement of there not being an "easy way to stream messages in JBI". With XML being so verbose I believe SM or OESB would probably dislike a 3 MB XML file getting pumped through it. Especially if that gets copied over and over again from one component to the next. This is where JBI might have difficulties scaling. As a colleague pointed out, the content of a JBI message is XML. And that XML has to be marshalled and unmarshalled. And that process is very heavy and even more so if there are reliability/durability constraints on the Message.

However, I think its a current tradeoff in order for all components on the NMR to communicate in a predictable fashion. Since that is the main concept of JBI: the ability for all the JBI components communicate. They have to communicate some how. One component can't decide that he expects format A and another decides he requires format B. Then nothing would work. So it sounds like to me XML was that language to guarantee interoperability between components.

On a side note, JBI components have the ability to set the content of a JBI message that goes on the NMR as anything implementing the interface javax.xml.transform.Source. Meaning that they can use streaming XML with the SAX and Streaming implementations. However, once consumed, that stream is gone and is probably represented as DOM (ouch) somewhere in the process. Our components use the Streaming impl when creating JBI Messages, but that doesn't mean the others do.

Either way, I have to think that smart people like Peter Walker, yourself, and other spec leaders can't come up with something to resolve this and get the best of both worlds.

"You need to implement a pretty heavy API to implement a service"

I disagree that JBI users have to know more about JBI than is necessary, but then again its hard for me to play that person since I am also a component developer. But most of the people that I have taught how to use JBI have been successful in using it without having to know as much as me. I know in SM you can expose a POJO pretty easily. In OESB you can use the Scripting Engine or create an EJB Service to be used in JBI. From what it sounds like though, its much easier with Mule.

Again I have not had a hard time teaching non JBI users about JBI. However I skip the spec and jump straight to a demonstration of how you can use JBI. This seems to help. I remember the first video I watched when the light bulb finally went off. It was a video on how to use the Sun SMTP BC and creating a Service Assembly with Netbeans. After I watched that video everything just came together for me and my co-workers. This is basically how I start off explaining JBI: It's best explained with an example rather than a bulleted powerpoint.

"It’s not actually that clear what a service engine is in JBI."

Touche. I hear this a lot, even from me. Again, as I stated earlier, the JBI community has done a poor job of training and communicating to its users and developers. My first definition of a Service Engine was basically a Service. I still don't have a good definition of an SE; usually I will just talk about what existing SEs are out there like the BPEL and XSLT SE. To me Binding Components are easy to define so an SE is just everything else (granted not exactly the best definition).

"The JBI specification is obfuscated with lots of new jargon"

Yes, yes, and yes. Again poor job of communicating. However, the JBI user should not be concerned with most of this jargon; only the JBI developer. For example, the JBI user shouldn't need to know about what the NMR is or what it does; but it's important for JBI developers to know.

"This breaks the re-use story since, if I use a JBI Binding Component in one container doesn’t mean it will behave the same way in another container."

Ideally JBI was suppose to be this loving community of predictable containers and components. Unfortunately that hasn't exactly happened. I will say this though, from my personal experience of using different components on different containers, for the most part most components and Service Assemblies work in a predictable way on other containers. For example, I have successfully used many SM components in OESB and and I have heard of Sun components working in SM. However the failure is you can't intermix Sun and SM components (or at least from what I know). For example, you can't use the SM HTTP BC with the Sun BPEL SE. To me this wasn't a failure of JBI; only how the JBI container was implemented. In a perfect world this would have happened but it hasn't.

Ironically it actually doesn't take that much to get your components to work on both SM and OESB. Of the four components we have written (RSS, SIP, XMPP, and UDDI), XMPP has been modified to work on both. We haven't had a chance to ensure the other 3 can, but hopefully we can get to that or the open source community could help. At the time of development we didn't actually understand JBI that well and consequently when we had our components originally working in SM and tried to port them over to OESB, they worked but only with other SM components. In order for our components to work with Sun components we had to basically rewrite the JBI layer. Unfortunately, due to time constraints it was not our current goal to keep backwards compatibility with SM. It wasn't until after we finished all this that we actually understood JBI and what it meant to create a portable component.

"If you look at every JBI implementation each has written their own JMS, FILE, HTTP, FTP etc Binding components… not exactly what I’d call re-use."

You are exactly right. Each container has implemented their own components for File, JMS, HTTP. Most likely because of the issues I mentioned above. However I don't think this doesn't mean JBI can get there. If these projects wanted to make them portable than we wouldn't have this problem. Instead they focus their efforts on other things.

As a side note, since my group was using OESB, when I joined a new group, we needed to get OESB working on JBoss. This currently was not supported and my previous group was able to work with Sun to get this working and its currently being incorporated in OESB.

SummaryIMHO I think a lot of assumptions where made about JBI, but you also addressed some of the issues with JBI. One reason I think JBI has not been adopted is the fact that it didn't have the backing early on of IBM and Bea. From what I recall they dropped out pretty early once they realized it was going to be a competing product. Another reason for a lack of adoption is I think again the lack of communicating what JBI really is.

I hope I didn't reiterate responses you have heard in the past. I wasn't around when JBI was originally approved, so I don't know a lot of the history. These are just my opinions I have collected through developing components and using SM and OESB.

Wednesday, April 16, 2008

Today I needed the ability to modify files on my Linux host machine from my Windows VM instance running in VMWare Server. This was actually pretty easy and once I found this article I was able to get it working in about 5 minutes.

Tuesday, April 15, 2008

In case you missed it, an important feature is being worked on in order to support direct deployment of a Grails application in Glassfish v3 (see Getting Started with Grails on Glassfish). According to Mr. Gupta, they are working towards being able to deploy a Grails app to GFv3 using the grails commands (currently Grails uses Jetty). Also they are working on deploying a Grails App for production purposes without having to create a WAR; which is the current method. Both of which will definitely improve developer productivity when using Grails and GFv3.

And since it was recently announced that GFv3 can run on OSGi, I think GFv3 continues to look very interesting.

Thursday, April 10, 2008

I previously wrote about specifying a release version for maven plugins in your POM files to have a more stable build and stop depending on SNAPSHOT plugin dependencies. It now seems with the latest version of maven2, version 2.0.9, that maven now comes with release versions for all the commons plugins (see the release notes).

"MNG-3395 - Starting in 2.0.9, we have provided defaults in the super pom for the plugins bound by default to the lifecycle and a few other often used plugins. This will introduce a bit of stability to your builds because core plugins will not change magically on you when they are released. We still recommend taking control of your plugin versions via pluginManagement declarations as this is the most robust way to future proof your builds. Defaulting the plugins in the superpom was a step towards introducing stability for small builds and new users. A full table of the versions used is shown in the next section."

Note how they still recommend specifying release versions in the pluginManagement section of your POM.

Previously I wrote about how to use the JBI JavaEE Service Engine to increase performance when orchestrating EJB Services created in Glassfish with the BPEL Service Engine in OpenESB. That was almost 8 months ago and Netbeans and OpenESB have changed a lot and consequently I needed to update it.

So I would like to provide an update using the latest Netbeans (20080402).

Again, if you haven't already, go ahead and download and install OpenESB which includes Netbeans v6 and Glassfish v2.

Create an EJB Module

File > New Project > Category Enterprise > Projects EJB Module

Create a new Web Service

Right click on your EJB Module project

Choose New > Web Service

Add a new Operation

Create a new BPEL Module

File > New Project > Category SOA > Projects BPEL Module

Create a new BPEL Process

Right click on your BPEL Module project

Choose New > BPEL Process

Create a new SOAP WSDL

Right click on your BPEL Module project

Choose New > WSDL Document

Go through the wizard and for the Binding Type make sure its SOAP

Configure your BPEL Process by dragging the SOAP WSDL onto the left side of the BPEL Process.

Add the standard "buttons" to the BPEL Process Sequence

Receive

Assign

Invoke

Assign

Reply

Utilize the EJB Web Service in the BPEL Process (this is where things are different than in past versions)

Right click on the Web Service under the EJB Module and select Generate and Copy WSDL

View your CASA file by double clicking on the Service Assembly file under your Composite Application.

Your CASA file should look something like this

Now you should be able to start Glassfish and deploy your Composite Application. Now your BPEL Process will utilize the Java EE Service Engine. FYI, do not deploy the EJB Module separately since its included in the Composite Application.

Wednesday, April 9, 2008

I previously wrote about not installing multiple versions of Netbeans 6 and now I would like to include another tip.

When installing a new version of Netbeans 6, while uninstalling your previous version make sure you remove the .netbeans directories. Otherwise the support for creating Tests in Composite Applications doesn't work.

In fact just delete the following before each new install and you will have better luck:

rm $USER_HOME/.asadminpass

rm $USER_HOME/.asadmintruststore

rm -rf $USER_HOME/.openesbinstaller_[machine_name]

rm -rf $NETBEANS_HOME/.netbeans

rm -rf $NETBEANS_HOME/.netbeans-derby

Note this is on Linux using the most recent version 20080402. Not sure where the directories are placed or called on windows. Also I believe older versions of Netbeans 6 placed the .netbeans* directories under $USER_HOME, so you might check there as well.

Tuesday, April 8, 2008

Not sure all my Idea co-workers are aware, but if they are its worth repeating. Now in Idea 7 (I am specifically using 7.0.3) you can quickly open your project in Idea by pointing it to your projects maven2 POM. It works pretty slick and now that saves me from having to run mvn idea:idea. It also supports the ability to synch with the maven structure on startup in case you add new dependencies to your POM, you shouldn't have to perform any magic to get Idea to recognize them.

Jeff Black reports the same ability with Netbeans 6. And here is the original Idea post describing this new feature.

In my unending quest to figure out how to efficiently do a demonstration from my Linux machine, I finally was fortunate enough to come across a solution. Today I did a demonstration for a friends company and they use WebEx. Luckily enough for me I reluctantly tried it first on my Linux machine, but not expecting it to work, and it worked! I was able to do a demo from my Linux machine and it actually worked seamlessly.

So if your company consists of different types of operating systems (windows and linux) and you need software that works on both for employees to share and view demonstrations then take a look at WebEx. It is not free so that is a bummer, but neither is Goto Meeting (which is what we currently use).

As an update to my premature post yesterday, I was able to finally use Ubuntu's Remote Desktop ability to share my desktop to a windows machine in order to perform a demonstration. VNC Server did not work and neither did No Machine (for me that is).

Luckily someone mentioned Ubuntu's Remote Desktop and I was able to VNC from windows using RealVNC's VNC Viewer and presto. Now I will just join a session in Yugma, share out my windows desktop, which is displaying a VNC session into my linux laptop. Wew!

I can't wait for the day when I can get a Mac or Yugma can share a linux desktop.

Thursday, April 3, 2008

Currently our company pays to use Goto Meeting to coordinate meetings. Unfortunately, Goto Meeting does not work in Linux and consequently I usually connect to meetings from my Windows VMWare instance.

Today I had the need to do a demonstration with offsite coworkers and I needed to do it within Linux. Since I have used the free service called Yugma in the past and it supposedly works in Linux I decided to spend some time trying to get it to work.

Well see for yourself.It took some time, but with their free online chat Help Desk (which unexpectedly was amazing) we eventually got it to work.

I image others wouldn't have as many issues as myself, but just in case here are some of the steps I had to perform to get this to work.

First, if you haven't already created an account, go ahead and create one (http://www.yugma.com). Then try visiting the Start a Session page. If you haven't already installed the software it should provide a link to download yugma. If not then you have issues like I did. Basically I had an old java version that FireFox was using and I had to update it to JRE 6. I followed their instructions here, but that wasn't enough.

Then restart FireFox. Revist the Start a Session page and you should be golden.

As a developer I really like Yugma because it has a free version that allows you to invite at least 10 people. Which is perfect for developers. And since our Goto Meeting licenses are controlled its difficult to get a Goto Meeting scheduled on short notice (Although Josh Hoover is the King of Goto Meetings). The other nice thing about Yugma is its easy to start and share a session. I remember in Windows Outlook you could even install a package that put buttons in Outlook and set it all up; very handy.