Thursday, April 27, 2006

SDK and Axis versions

There are a number of differences between the various Axis versions which introduce incompatibilities of various kinds. I've done some investigating to check this:

Axis 1.1 and SDK 1.0a work together fine, both in client and service configurations

Axis 1.2.1 and SDK 1.0a works OK for a service, but the client code has problems because of a deprecated constant

Axis 1.2.1 and SDK 1.0b works OK for a client, but the service code has problems because of an issue with optional non-nillable elements. This can be fixed by regenerating the SDK, but Axis 1.2.1 has problems doing this due to the way it handles imports.

I've now started working with Axis 1.3, and have generated all the code again from wsdl2java, and added the bridge and implementation classes. The resulting jars work fine in client mode, and I'll start testing them in a service later today. If this works, then perhaps the best thing to do is to skip Axis 1.2.x and go straight to Axis 1.3.

The only niggle is that Axis 1.3 generates the classes "properly" (that is, with names like CreateGroupRequest and not _createGroupRequest) which means existing code will need to be updated.

Wednesday, April 19, 2006

Axis 1.1 -> Axis 1.2 Issues

The current build of the SDK works fine with Axis 1.1, however there is an issue with Axis 1.2.1 because of a change in where constants are stored:

org.apache.axis.enum.Style.DOCUMENT

is now:

org.apache.axis.constants.Style.DOCUMENT

Which will result in a NoSuchFieldError: DOCUMENT when using Axis 1.2.1 with the current version of the SDK.

So a rebuild is in order for supporting 1.2.x ...

Monday, April 03, 2006

SOAP-less web services for simple clients

Sadly this doesn't work for Alex over at JoinIn, but some time back I wrote some guidelines on creating a SOAP-less version of the IMS Enterprise Services spec for basic read access to people and group information, particularly for use with clients that either don't support SOAP or where coding for it is a pain and you can't use the SDK.

I'm sure this could be extended to a full ReST binding, but as it stands its basically the same as SRU.