Tuesday, September 26, 2006

How to do web services?

The project that I am currently on has been my first real exposure to enterprise grade, mission critical web services and I must say it's a real challenge.

What makes it even more challenging is that the project has a dotNet front end and a java back end, so we have to make the web service inter operable.

Let me start by just pointing out that we are using IBM's Rational Application Developer Platform version 6 to do the development, this does have a significant impact on your modus operandi, not only because of IBM's how can I say, blindness but also because of the current nature of web services development

When we stated out we were going the route everyone starts with, generating the WSDL and the web service plumbing from a java class, be that a session bean of a POJO. This as you may or may not know is not the best practice approach, and that shows when using RAD. In fact, IBM might as well remove the ability to generate wsdl's from java code RAD does it so badly. I know why it is not recommended.

Because of the fact that RAD is so poor at doing this and because none of the team knew how to hand code wsdl's, a notoriously complex job, we went a generic route where we have one web service which receives two strings, one for the details of the method to be called and another for the arguments. The translation between xml and objects is therefore our responsibility, and not dealt with by the application server and generated code.

We selected castor to handle this for us.

I then went on a mission to educate myself about wsdl's, and the surefire way to do this is to buy a book, which I did, Web Services Essentials (O'Reilly XML). That sure helped break the back. I was very chuffed when I successfully hand coded my first wsdl file that not only successfully validated with RAD but RAD also did an efficient job of generating java skeleton code from it. First I started with a hello world wsdl and then built one where an xsd file was referenced to provide the communication protocol.

I must say, it was not as difficult as I thought it might be - I also realised that most of that complexity is necessary. This is often the case, things are perceived to be complex because they are not understood.

One thing is for sure however, and that is that RAD's wsdl editor is a load of crap!

So to continue on my journey, generating java skeleton code from a wsdl is a painless process in RAD, whether you generate to a session bean or to a pojo.

The problem is, and this what I'd like to focus on, is that the web services runtime for Websphere (other web service run times as well), generate java source code for the communication objects from the schema. Now it is absolutely necessary that you use schema's (xsd's) to define the protocol in order that the client and server can understand what each other is saying, but the problem is this generated code.

Typically, in the schema you're going to have objects defined by the schema which are already defined in your code and if you've already built these objects, then you're going to have two versions. One generated and one hand coded, and you're probably not going to like the one that is generated.

Before continuing I'd just like to look at why it is done this way because there are technologies which allow you to take already existing java classes and map them to a schema (castor, jibx, et al). I think the builders of web service runtimes have taken the route to generate classes from a schema, the pojo as well as some kind of helper that knows how to marshal and unmarshal the pojo, because that way they can guarantee that the marshaled xml conforms to the schema. If they leave it in the hands of the developer to provide the mapping between the already built pojo and the schema, they cannot guarantee that this mapping is correct. I wonder if annotations and generics (which we cannot use because IBM is slow), could annotate already existent classes and save us this trouble.

Typically, generated code is not preferred. Developers like the code to be the way they like it.

You have another problem however, how do you copy between the dto objects and your value objects? Manually - are you kidding... If you have to do it manually then I'd rather re-use my value objects. If on the other hand you can in fact use reflection, fast becoming pervasive in computing environments, then it will in fact be a pleasure.

Watch this space for more lessons learned on the enterprise project.

Thursday, September 07, 2006

.net first impressions...

I have always been a java developer and since joining my current company, which does java and .net development, I have looked forward to the day when I would get exposure to how the .net platform works...

The project I am currently on has both .net and java elements and I have thus been able to dip tentatively into the world of dotNet.

The first thing I've discovered is that my learning the dotNet environment requires my learning a whole new IDE, and this, given the complexities and capabilities of modern IDE is a "double difficulty". Not only do I have to learn a new IDE but I also have to learn a new language. It is debatable which is more difficult.

If you consider that now only do I know java well but I also know eclipse (a java IDE) well and it would take me a long time to learn another java IDE, and it's not something I would find easy. Thus discovering the dotNet environment becomes doubly as difficult because I have to learn an IDE as well.

Now I must be careful of not making the mistake that I throw the book at the C# guys for doing, and that is condemning the platform because of the IDE. I can understand their thinking because for them there is only one IDE, thus the platform is the IDE.

Fortunately, in the java world, this connection is not so strong because there are a number of different java IDE's and thus you can choose the one that best suits your needs.

I think the point I'm trying to make is that learning a new platform is not simply learning the language and the intricacies of the platform, but also learning the IDE that goes with it. This is probably a bigger task than the language itself.

But then you may ask, so what are your first impressions...

I am not ready to comment on c# as a language as I do not know enough about it, but I can make some comments on Visual Studio... Do not see this as a comparison between c# and java, but merely as a comparison of two IDE's, regardless of what language they are for.

I think the first thing that must be said is that VS is unbelievably responsive! It is like waiting right outside the door to give you what you need. It is like the waiter who does not let your glass even get half full before he is on hand to fill it up. The java IDE's in general (possibly because of the non native nature of the gui), are more like the waiter who comes round every 5 minutes or so to make sure your glasses is full. Still gets the job done but just not so quick.

I must point out however, that it is probably not much more than a "nice to have". A lot of the facilities I've come to depend on in Eclipse just aren't there in VS. When I say facilities, I mean "micro facilities". It is also very difficult to assess an IDE objectively, first impressions are always clouded by the "I can do this in eclipse, why can't I do this in VS?".

I'll continue to report on my progress through the .net environment, as and when progress occurs.