Comments on Developing JAX-WS web service integration solutions using WebSphere Integration Developer V7

That’s what I like the most – learning by sharing. It’s the most rewarding learning experience so far and today proved to be very productive.

There’s an article Developing JAX-WS web service integration solutions using WebSphere Integration Developer V7 on the IBM developerWorks site. It brought my attention for JAX-WS and WID7. Although the article learned me a few things I must admit I would not recommend following its guidelines to build JAX-WS Web Service with WID. There’s another tool for such a service called IBM Rational Application Developer and whenever WID and Web Services are in a sentence there’s only one thought in my mind – a SCA component with an Web Services export or import. I believe it’d have been much helpful if the article had shown a WID7-way of developing Web Services with a SCA component implemented in Java and exported with Web Services JAX-WS export. It turned out that the article made it another way and the review process at developerWorks let it go live. It could’ve been such an excellent article.

The author’s Java programming skills are also questionable. I could live with incorrect formatting of these Java snippets (that made the reading a less pleasant experience), but I couldn’t  understand why the web service was implemented the way it was. Why didn’t DescriptionLookup use a HashMap<String, String>? There should have been no Keys and Values (uppercase!), no Hashtable (synchronized structure!) and no casting to String in getDescription. In this case, less would bring more value.

The package was against the rules of Java package naming which say it should’ve been a reverse domain name, i.e. This and the aforementioned naming and class selections which are all against the Java style formatting and naming made me wonder about the level of Java skills and how much effort dW reviewers put into the article to make it at the highest possible quality level. Sorry to say so, but it’s so obvious for any more experienced Java programmers.

When the Web Service was ready for deployment, why wasn’t WebSphere Process Server v7.0 at localhost selected? It’d be more natural (if not WAS7 itself). It can mislead to a false understanding that Monitor is really necessary for Web Services in WPS (which is not).

I would not recommend checking Generate WSDL file into the project and Generate Web Service Deployment Descriptor (shown in Figure 10.), so the Web Service is considered as an external Web Service with all its consequences like WSDL available under a given URL address. Having it more real-life-oriented would be of a huge advantage for readers.

With all that said, one could imagine I stopped paying attention to further reading and move on to other articles. Wrong.

In the series of WHAT_I_VE_LEARNT I could learn about Enable asynchronous invocation for generated client feature and Java SE’s java.util.concurrent.Future. A bit about the former is at JAX-WS Code generation in WebSphere Web services preferences. Also, you can check out the Creating a Web service from a Java bean using the IBM WebSphere JAX-WS runtime environment, but as far as that particular feature is concerned there’s nothing more than what you could read in the previous document. It seems there’s nothing to add beside the single sentence – once the option’s turned on, additional methods for asynchronous communication handling get created. It’s worth to note that the classes are generated in the client project and the most interesting piece is certainly the one that ends with Delegate. That’s where the Web Service’s methods are with their asynchronous counterparts. I’ve never stumbled upon it.

I decided to find out how easier it would’ve been to use another approach to import WSDLs and XSDs. As a IBM instructor I’d been teaching about the feature, but had never run it myself. That was the time to experience it. So, here goes a slightly improved version of the article as described in the section “Create BPEL process model application to invoke the service”.

Once you’ve created ElectronicSubmissionLib library, right-click it and select Import. Type in WSDL and select WSDL and XSD under Business Integration. Where WID shines (possibly it’s Eclipse itself, but can’t confirm it as I’m pretty newbie in this area) is the ability to import WSDL from a remote location. See the short screencast of mine – WID7’s WSDL and XSD Importh so I don’t have to type all in (it’s said that laziness is not that bad in the IT crowd). Don’t forget to have your server up and running upon importing so the URL is indeed fully functional.

With a very productive morning, I’ll leave the other part of the article for another “Reading” part of my next day.

Let me know how the screencast worked for you. Comments are highly appreciated.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s