Make It So!

IMS is updating Enterprise

2007-02-28T11:46:00.000Z

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

2006-07-25T11:12:00.000Z

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

2006-05-23T12:12:00.000Z

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

SDK for 1.3 works!

2006-05-08T17:22:00.000Z

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

2006-04-27T09:12:00.000Z

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

2006-04-19T15:12:00.000Z

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

2006-04-03T12:30:00.000Z

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.

Mapping group types

2006-03-18T12:11:00.000Z

To use Enterprise Services, you need to create a set of mappings between the objects used in the various Java method calls, and the data in your system. One of the most important aspects of doing this mapping is establishing what types of Groups you are working with.

IMS Enterprise mandates specifying a group Type for every Group instance, such as "Module" or "Course". These are identified with a Scheme attribute, so there is the potential to map groups across diverse systems based on value spaces. There is also a Level value for hinting at relative granularity, which can sometimes be useful.

For example, if you created a vocabulary of the types of groups Moodle supports as being in the http://www.moodle.org scheme:

[scheme:type:level]
moodle:course:1
moodle:group:2

And for LAMS:

lams:enrolledGroup:1
lams:sequenceGroup:2
lams:dynamicActivityGroup:3

(these are just examples, I don't know what structures Moodle and LAMS actually use - ask Alex!)

When calling the service, you can then correlate the types so that you get the right types of groups.

For example, if LAMS is the provider, and Moodle is the client, and a call returns a Group with the type "lams:sequenceGroup:2", you might assert that you're dealing with the equivalent of a Moodle Group rather than a whole new course.

These mapping rules can then be encoded into an interface you wrap around the SDK at the client end so that it just returns the kind of groups that make sense in local terms, rather than any and all generic IMS groups.

This is important, because in a lot of MIS systems groups are keyed on all kinds of factors, like semester and campus, and also often contain both canonical and actual courses, so doing a straight transfer from MIS->VLE can generate zillions of courses if you don't sort out the mapping rules.

Enterprise "version 2" Considered Harmful

2006-03-13T12:04:00.000Z

A lot of people have been mentioning the "version 2" of Enterprise Services mentioned on the IMS site.

For the record, this isn't a more advanced or later version of the spec, instead its the Asynchronous binding, which while it was produced by the IMS team, none of the working group members were interested in implementing or testing it. Therefore, its basically there as experimental only, with no reference implementation, and without having gone through the iterative testing process that got most of the bugs out of ES v1.0. Which means it probably won't work without messing around with the XSDs and WSDL.

Basically, don't bother with "v2" unless you really, really have to do point-to-point async transactions, and you can't think of another alternative.

Example client code

2006-03-02T16:38:00.000Z

The article over at CETIS only explains how to code the difficult end of enterprise - the server. How do you implement a client?

Below is a code snippet that might shed some light. Its from an application that aggregates groups and resources from a range of sources, in this case this is the method it uses to get information about people who are members of a group.

The array of java objects returned by the call represent Persons (in this case), and you can do the usual sort of operations on them like getFormatName() and so on.

Pretty much any enterprise API call is coded in exactly the same fashion.

(Apologies for the lines scooting off the end of the page...)


/**
 * Get the members of a group from the service
 * @param id the id of the group to get members for
       * @param url the location of the service
 * @return a set of persons
 * @throws PlexException
 */
public PersonDType[] readPersonsForGroup(IdentifierDType id, String url) throws PlexException{
 _readPersonsRequest = new _readPersonsForGroupRequest();
 _responseHolder = new _readPersonsForGroupResponseHolder();
 _responseHeaderInfoHolder = new _syncResponseHeaderInfoHolder();
 try {
   _readPersonsRequest.setGroupSourcedId(id);
   _requestHeaderInfo = HeaderInfoHelper.newRequestHeaderInfo();
   PersonManagementServiceSyncLocator loc = new PersonManagementServiceSyncLocator();
   PersonManagementServiceSyncSoapStub svc = (PersonManagementServiceSyncSoapStub)loc.getPersonManagementServiceSyncSoap(new java.net.URL(url));
   svc.readPersonsForGroup(_readPersonsRequest,_requestHeaderInfo,_responseHolder,_responseHeaderInfoHolder);
   _status = _responseHeaderInfoHolder.value.getStatusInfo();
   _persons = _responseHolder.value.getPersonSet();
 }catch (Exception e){
   throw new PlexException("There was a problem connecting to the remote service");
 }
 if (_persons == null || _status.getCodeMajor().getValue().equals("failure")){
  throw new PlexException("There was a problem with the remote service ("+_status.getDescription()+")");
 }
 if (_status.getCodeMajor().getValue().equals("unsupported")){
  throw new PlexException("The remote service doesn't support this type of request");
 }
 return _persons.getPerson();
}

Hey, ho, lets go!

2006-03-02T15:54:00.000Z

This is the new home of the Enterprise SDK - all the old stuff (such as it was) is still on the Sourceforge site which you can access over from the link list. This is where I'm going to announce any updates, and publish any new documentation. If you've got support questions, feature requests, or bugs, then use the regular SF features.

Congratulations to MINTED and JoinIn on getting their projects started!