IMS is updating Enterprise

So I don't plan on doing any major code updates after v1.3 until IMS release the new spec - at that point it may make sense to start afresh based on the inputs from the MINTED, JoinIn and BEWT teams, and base the work on Axis 2.0 rather than migrate the code from Axis 1.3. There may also be other services defined in the new specification, so it would seem like a good point to start on a new revision.

Bugfixes to v1.3 will happen as requested, however.

SDK 1.3 release, and CVS shenanigans

I've released SDK v 1.3 (a quick poll suggested naming the SDK versions after the Axis version they complement). It's up on SF now.

I also had to do a lot of work in CVS following the SF CVS disaster a while ago, putting a load of orphan 1.3 code. I'm fairly confident its all there and with the correct verions, but if there are any problems post something up!

No News Is Good News

No big issues over the past few weeks - which I'm attibuting to everything working as advertised!

SDK for 1.3 works!

I regenerated all the code for the SDK using Axis 1.3, and built a new set of libraries and examples for the distribution. Initial reports are good, so all being well I'll make a release for this in the near future. It does mean some changes to existing code based on the SDK, but on the whole the changes actually make it simpler as Axis basically seems to interpret the WSDL and XSDs more intelligently.

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.

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 ...

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.