|
|
Wednesday, July 28, 2004 |
|
Plea for Ease of Use in JAX-RPC Web Services As the result of prioritizing our bugs in our OracleAS 10.1.3 release and writing up some labs for a J2EE/Web Services/BPEL roadshow we are starting next week, I was painfully reminded of why JAX-RPC sometimes tees me off. While the basics are fine and perfectly usable, sometimes I wonder if someone wanted to invent a harder way to do Web services they might have to work pretty hard to beat some of the things that came out in JAX-RPC 1.1. Holy moly. Yes, its got all the checkboxes down pat - WS-I compliance, RPC/encoded and Doc/Literal, Handlers, Attachments, standard configuration with JSR 109, configuration capabilities for anything you want via mapping files ... the list goes on. Depending on the vendor, you can get seduced during the bottom up publish process - implementation class, interface class, the standard webservices.xml, a mapping file and, in our case like every other vendor, a proprietary oracle-webservices.xml - and away you go. Build a client or look at changing the mapping file and all bets are off. For a simple doc/literal Java class with 2 parameters - 9 classes generated. Come on, that sucks. Four lines of code to invoke from a J2SE static client a doc/literal service endpoint (sample below for a simple two parameter service)? Sure, elegant and all using factories but easy? Remember Web services and SOAP were SIMPLE to begin with. ServiceFactory factory = ServiceFactory.newInstance(); I almost had to laugh at a JavaOne session I attended on how easy JAX-RPC is. Yes, at face value and if your vendor bends over backwards to smooth the rough edges, yes, then it is possibly easy to use. Make sure you try out your implementation first or you might be surprised. As we close down what I have been writing about in the last several months in Oracle Magazine our 10.1.3 release where we have a full J2EE 1.4 implementation, usability has been a big focus of the Web services team. Little polish things like organizing and naming the generated files in a fashion so the focus is on what the developer needs to do rather than what JAX-RPC needs for runtime infrastructure and providing helper classes to jumpstart the novice developer are baby steps in the right direction. The one place where I think there is huge opportunity and we as Oracle have a first cut of this already shown in the examples of our OTN preview is early support for the JSR 181 Web services annotation approach. If you have ever explored a JAX-RPC mapping file, it makes writing BPEL look like childs play - yes you can do lots of things, if you can figure it out. Cries out for an editor - isn't the requirement of an editor for ease of use the sign of too much complexity? The cool thing about annotations is they give a reasonably human readable form to the task you would like to do - e.g. I want a parameter name x to map to y in my WSDL - to the 4 or 6 lines of XML I would have to enter in the mapping file to to do the same. JAX-RPC 2.0 promises to fix many and more of these complaints, but J2EE 1.4 is pretty much here and now for most people over the next 12-16 months while J2EE 1.5 shapes up and eventually is released for the vendor community to implement. I vote for annotations and probably will be making that my next Oracle Magazine article for November as it will make me feel better about Web services and usability! comment [] 10:43:24 PM |