Life in Sun Micro Kiran Bhumana & Sun

There seems to be a good amount of interest in dynamic composition (orchestration) of webservices using BPEL. There are also a lot of users who don't know that this feature exists and also users who know about this and are interested in using this seems to scramble around for more information. This blog entry is to help users to make use of the dynamic composition feature of BPEL point them to the right resources. Refer to the wiki information on this feature from openESB BPEL engine, also refer the feature implementation details.

There are two variations of this feature. The partner address is not known at the design time (and variation of this use case, like, the partner address changes at runtime based on some business rules). Along with the dynamic partner address, the number of partners is also unknown. Users have asked for use cases when the number of partners the service orchestrates. Current version of BPEL engine supports all this functionality. Users would like to invoke their partners asynchronously and this can be done using the BPEL's Flow construct. But if the number of partner links is dynamic as well, then Flow construct falls short of the requirement. Fortunately BPEL spec defines ForEach 'parallel' to solve this, unfortunately current version of BPEL engine doesn't support ForEach 'parallel'. Not to worry there is a good work around,  the work around makes use of the BPEL's asynchronous service invocation feature. Here is a blog that explains in very good detail with a working example of how to do this.

I will post another entry on this subject with a simple sample project that would help the users of dynamic partner link to avoid the common pitfalls I noticed thus far in it's usage.

I was posed a question regarding patterns in integration. Although I had quite a bit of experience in integration, when the question was put forth like that, I found myself with no good answers. Someone is compiling a list of patterns in EAI space, http://www.enterpriseintegrationpatterns.com/eaipatterns.html. This is good news as these patterns can be used as a good reference. I realized that although I knew most of these use cases, I just didn't know their "supposedly" standard names to refer them to. Being able to refer a pattern is almost as useful as knowing about the pattern. Just be aware that the link referred earlier mentions a lot of patterns. Just be sure to find out which ones are important and which ones aren't, be your own judge.

My comments on patterns in general and to people who are "hung on patterns" and refer patterns for every silly thing.

I recognize the benefit of patterns but too much of patterns is actually a bad thing. It helps to recognize the most important patterns which are not quite obvious and which help new users understand the problem domain as well as the solution. Every pattern, how ever simple it may be, if given a name and is referred to during designs and implementations, causes more confusion. This is so because, expecting everyone to remember every silly pattern under the sun, that anywho can come up with a name is unreasonable. To drive the point there is a pattern defined to create and initialize a data structure. Imagine that! I think people should use common sense rather than introducing unwanted complexity into defining patterns and diluting the importance and benefits of design patterns.

Last week it was all busy with JavaOne and CommunityOne. I conducted a Hands on lab along with another colleague on sun SOA, BPEL tools. The lab was full with about 150 people and it was well received, with quite a few people showing interest in talking further with our teams. I was pleasantly surprised that most of the lab attendees were able to complete the exercises well within time and went on to complete the challenge exercises. We had estimated the times to be a bit aggressive and were concerned that the newbies to BPEL will just be able to complete 2 of the three exercises. But gladly the tooling seemed to be quite simple that they pleasantly surprised us. Another indication that the Netbeans enterprise tooling is pretty good.

For those of you who are interested in the BPEL lab that I did or other labs, click here.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

    by Martin Fowler in his book Refactoring.

With all due respect, I gotta ask how can a fool write computer code? If that were to be true then the market wouldn't be paying such good money to programmers. Or maybe we can deduce that the economics that govern the market are irrational, contrary to what a lot of economic theories suggest and many country's economic policies rely on, which is "market is rational and open market governs the economics". Perhaps the recent economic debacle (still unfolding) in US whose ripple effects are seen across the globe is an indication of the irrationality of the market. Thus proving that any fool can write computer code.

Well all that riff-raff aside, I totally totally (intentional double there) understand Martin Fowler's intentions in the afore mentioned statement. The point being stressed is that developers need to write code that is easy to understand. This helps in fixing the bugs quicker, implementing new enhancements faster, keeps the cost of owning the code low and other such benefits which are not visible right away but which pay off over time.

What if software evolves into a phase where software-bots (automated software programs) do code development? Do they still need to write code that humans understand? Before we even think of how the code should be, lets just delve on what these bots can and can't do?

These bots may get an enhancement request or a request to fix a bug. Then they analyze the use case and write the code that enhances the functionality, churn out a set of exhaustive tests, embeds the new code and deploys itself onto the production system. That will be neat, eh? We are already seeing code that churns out tests automatically, we are seeing software upgrades to live systems happening all the time. The first part still seems to be the trickier one!

 
Netbeans Enterprise pack has cool tools to help the users to find references of elements being used. Users can also do XML based refactoring and undo. Here is a demo that shows XSD editor and WSDL editor

BPEL editor in NB 6.0 helps the user to develop BPELs that involve correlations. Here is a demo.

Video that shows some of the BPEL editor features. Importantly the validation aspect is to be noted. Here is the demo.

 
BPEL(2.0) editor to show creation of variables using the NB 6.0 enterprise pack. Here is the demo.

See how NB enterprise pack tools help develop SOA solutions. Here is a demo.

Learn to add a validator for an enterprise pack module. video

Refer  http://www.netbeans.org/kb/60/  for more NB documentation.

NB module creation video. 

Working with your file type in NB 6.0 video

Refer  http://www.netbeans.org/kb/60/  for more NB documentation.

I have noticed many folks have questions on the usage of the predicates in BPEL, creation of the predicates in the BPEL editor. Recently there was a question on the forum asking how to create new nodes, when the nodes are repeating. I felt the best way is to put a response on the blog so others may see it as well. It acts as some sort of informal documentation too. Here is a flash demo  that captures the editor creating a predicate expression. In this particular use case, we are populating the value for the predicated-node.

Note: If a green arrow appears on the screen, click on it to continue with the presentation.
 

 

Have you checked out some of the BPEL blueprints out there? Here's the link for BPEL blueprints published on Java.net. There is something about these BPEL blueprints that needs clarification, and what better place than this blog. The BPEL blueprints are written to serve the following important purposes,

• to demonstrate the most common patterns of BPEL usage and also
• to demonstrate better ways of authoring BPELs, (As in any programming language there are many ways to achieve your functionality in BPEL too)
• to demonstrate rich and interesting features of BPEL.
  

There is a need to write more BPEL blueprints and I hope we continue to add more blueprints feature other aspects of BPELs. Upon closer look at the source files of these existing 5 BPEL blueprints, one finds that some parts of the WSDL didn't conform to the WS-Basic Profile 1.0. Binding section defines a RPC-literal for a message part that is of "element". Although there is nothing glaringly wrong in this because this is a valid option as per WSDL spec. But for those who want to strictly adhere to Basic Profile they won't like it.

Maybe it is time to clarify from the author's stand point as to why this happened. :). BPEL blueprints, were meant to be WS Basic Profile compliant because they were blueprints, for reasons I mentioned above what these blueprints stand for. During some of the edits we were using different versions of NB builds, and somewhere during those iterations the editor chose to insert its own default values on some of the child elements and it missed our scrutiny. For instance, On the "soap:binding" element we defined "document" style, but on the "soap:operation" it is overwritten by "rpc" style.

 
In my previous log, I mentioned the immediate advantage of using Generics of Java 1.5. While the thought is still warm about good type checking I thought I would point to a good BPEL IDE. I am a firm believer in better and better and more better tools. As an author of BPEL engine I would like to see as many errors and mistakes found out during the development of the BPELs rather than running into them at runtime.

For this very same reason I have been pushing for a lot of validations from the NB enterprise pack for BPEL validations and other related(WSDL and XSD) validations. Incidentally I started to write up the list of validations before BPEL 2.0 experts started identifying the static analysis validations and made them part of the current spec. I kept asking for the validation features from the BPEL editor (BPEL editor folks may say, bugging :) ). Needless to say that there was a lot of overlap with the list I had and the list the spec came out with. Today NB does static analysis validations from the spec and on top of that a whole lot of other useful validations. This has enhanced the user experience considerably in terms of BPEL development.

If these validations were done during deployment of BPELs to engine, that would be sufficient too. For the sake of completeness, I will add by saying that the runtime does some validations but not a whole lot, and plans to put extensive validations are under way. No matter how many validation rules you provide during deployment, I still would prefer them to be identified during the development stage itself.

Imagine, before the advent of IDEs (in hard old days of no IDEs) if there were compiler errors in your program, they were all spit onto the shell or onto the command prompt. Did you ever like going through them, reading the issue and going to the line in the file to fix it? I for one hated it. Imagine what the IDEs do today, 

• You are told as soon as you write the code that there is something wrong (i.e, if there is something wrong)
  
• After you compile, you can click on the error reports. The file and line is opened for you to fix it.
  
• It also has suggestions about what the fix could be.
  

(Needless to say that IDEs help in a whole lot more ways, I am primarily focusing here about validations). In the same spirit, I would like to see a good IDE for BPEL. And that is what I have been after when I was bugging the NB BPEL editor team. I should say they have done a great job and you should check out the NB 6.0 enterprise pack. To illustrate further, try to hand write a simple correlation project without a user error. Today with the NB 6.0 BPEL editor, user errors are minimized to a great level. Am i saying that we are done with validations? No, NEVER! For two reasons,

• There are more validations we need to add and BPEL editor team is constantly evaluating them and planning in the releases.
  
• For instance, we can do deep validations trying to validate all the xpath expressions as much as possible.
• User experience can always be bettered. It is an ever improving process that will take some time before we can claim that there are not many more validations/improvements that could be done to take the user experience to the next level.

I have used generics for almost 2 years now. I find the generics useful for the very (primary) reason they are defined for. The tutorial says it all and i wanted to stress it one more time. The last line of the first page succinctly explains my experience and thoughts, "The net effect, especially in large programs, is improved readability and robustness". A lot of articles seem to be pointing the first use of generics is to help developers avoid the type casting when accessing elements from a collection. While that is a nice thing due to generics, the usage of generics should be viewed as that it helps in more type checking of your code and will result in less bugs.

As part of Generics feature java 1.5 brings in lot more than just the robust type checking. Haven't used them so far and sometimes makes me wonder if the thing was over engineered. I guess time would tell us how much these other features will be useful.

Java developers need to keep in mind that generics can be nested and that would call for good design/coding practices and principles.

For instance, Map<String, Map<String, Map<String, List<String>>>>.

This is not a good thing, Without generics I would have designed the above with some wrapper classes to keep the code readability at a high level. Using deeply nested generics can be a slippery slope and requires some good practices. I would recommend that anything more than 3 or 4 level deep is not a good thing to be captured in generics. It may in fact beat the purpose of code being readable and in effect being robust.