Last Updated: 02/29/00 02:51 PM
In the context of Prism (our DLI2 project) we discovered that the current RAP IDL (version 1.1) needed some massaging. Specifically, there were some security issues requiring some IDL tweaks, but in the course of designing those changes, we ended up taking a fresh look at the IDL. In particular, we were motivated to try to clarify some awkward constructs because we are passing the Fedora software to a growing number of collaborators. We've changed very little functionally from RAP 1.1, but we feel the IDL and Servlet API are clearer now.
We now use three distinct terms for three distinct functions. We have our friendly SignatureDisseminator which lets us ultimately get a list of MethodSignatures. We introduce the term TypeSignature ( instead of "Signature") for this list of methods. (This also avoids confusion for those security-minded folks whose first thought of "Signature" is a Digital Signature.) We also introduce the notion of a SignatureGenerator into the IDL to make things more parallel with what goes on with Servlets. So a SignatureDisseminator now returns a SignatureGenerator, which in turn will provide the TypeSignature. There is now a nice similarity between how SignatureGenerators and Servlets are expressed at the IDL level.
To summarize the new terms:
Disseminators previously required unique IDs in the context of a DigitalObject, but the DisseminatorID was an uncomfortable concatenation of SignatureID and Descriptor. The URN format simplifies the DisseminatorID construct in RAP, while requiring Disseminators to have globally unique IDs allows Disseminators to become publicly registered interfaces (at the discretion of the DigitalObject owner). This facilitates flexibility for web integration: we might want a registered DisseminatorID to resolve to the URL of a special Web page that lets the user talk to a particular “portal” on a DigitalObject (e.g. via CGI or a Java Servlet (not a RAP Servlet) talking RAP behind the scenes).
We reiterate: A Disseminator can become a publicly registered interface if the repository owner wants to do this (unlike a DataStreams which has an internal system-generated name). A URN format for a Disseminator does NOT mean the Disseminator HAS to be registered in the Handle System. It just means that it has the potential to be registered. In fact, some Repositories may chose to never register a Disseminator's URN.
Also, since it is useful to have a 'human readable' descriptor associated with each Disseminator, we retained this concept. We made it more analogous to the descriptor associated with a DataStream.
Now that DisseminatorIDs are URNs, it provokes the possibility that a ServletDisseminator or a SignatureDisseminator would have its own URN. Where in the past a Servlet or TypeSignature was identified by the URN of the DigitalObject that disseminates it, now the Servlet or TypeSignature can be identified by the URN of the Disseminator that disseminates it. This results in a more direct naming of the Servlet or TypeSignature, as these are no longer known by their "parent" DigitalObject name, but instead by the name of their Disseminator. Additionally, this allows DigitalObjects to disseminate more than one interface (TypeSignature) or mechanism (Servlet). So a DigitalObject can have any number of any kind of Disseminator, which in turn means that a DigitalObject could be "self-contained": it could have all of its interfaces and mechanisms built in.
These are useful when a client needs to supply a parameter value for a MethodRequest and allowable values aren't inherently obvious.
This clarifies the commonalities and differences between SignatureDisseminators, ServletDisseminators, and StandardDisseminators. For example, SigDiss and SvDiss each require exactly ONE attachedDS, and it needs to be executable. Similarly, the notion of a "ServletID" for the Disseminator doesn't apply to the bootstrap Disseminators.
Bonus: the IDL requires fewer kludgy constants in SigDiss and SvDiss.
Aside from clarifying the commonalities and differences between SignatureGenerators and Servlets, these new interfaces clarify the relationship between Executables and bootstrap Disseminators. For example, the AttachmentSpecification is not an attribute of the ServletDisseminator, but of the Servlet executable. Bootstrap Disseminators now only allow setting and getting (dissemination) of either a Servlet or SignatureGenerator (respectively) -- and those RAP interfaces, in turn, allow you to get all the information about the Servlet or the TypeSignature, without over-encumbering the Disseminator.
In the past, before loading an executable (such as a Servlet or SignatureGenerator) into the java virtual machine (JVM), the executable's name was derived from the URN. We now require the class name of an executable byte stream when attaching it to a bootstrap Disseminator. This avoids requiring URNs to contain a parsable class name, while retaining the security practice of not loading completely opaque byte streams into the JVM.
They may be reinstated when their functionality is clarified.