caTissue Client API

The client API is a way of extending the caTissue application. Jeff suspects the aim is to achieve more functionality within caTissue with less effort from the official development team.

The client API allows you to use caTissue's domain objects (like Participant or Specimen) within another application (the client). All of the domain objects are serializable Java classes. The modus operandi is for the client to create or retrieve one of these and pass back the object to caTissue. The object gets serialized over the network for this to work.

Here is some pseudo code of what a client must do to register a new participant, with comments:

1. Locate caTissue application service.
2. Start a session within caTissue. This is just like starting any other interaction. There is the possibility of time out with inactivity. Some degree of housekeeping and authentication is required.
3. Use the application service to retrieve a local copy of the CollectionProtocol.
4. Create a local copy of the Participant and initialize it according to the CollectionProtocol requirements. This is quite an involved process requiring detailed knowledge of the caTissue business model.
5. Use the application service to pass the Participant back to caTissue. After this action, the Participant exists in the database.

Notes on the above...

The Client and The User

The client API is invoked within an application entirely separate from the caTissue application. They are both separate applications that happen to talk to one another. The client will need to be written in Java if it is to use serialized Java domain objects. The client application has a user. How does the user interact with it:

• Web browser?
• Desktop gui?
• Command line?
• Two-d barcode reader?

This user interface will need designing and programming.
(Also see next point below, which is also relevant).

Domain Objects

This concerns point 4 in the pseudo code example. The use cases we need to cover will involve business objects (domain objects) like Participant, Collection Protocol, Collection, Specimen Collection Group, Specimen, and so on. We will need to understand how these relate to one another. The code that supports the use cases must support the relationship between these objects. It is possible the integrity of the objects will be checked by the caTissue application when the client finally interacts with it. But:

• If it does, we need to handle error conditions. The examples I've seen are very rudimentary in dealing with errors.
• If it does not, we risk data corruption unless our understanding is good and we programme defensively.

Transactions

This is partly an extension of the above points on Domain Objects.
Normally, a business action within an application is defined by one or more transactions. I cannot see a clear transaction boundary yet in the API.