Problem #1: Registry
We have a problem that the registry is a mishmash of Perl and Java. The RESOURCES script is problematic since it is used by MOBY::Central to generate the RDF that is passed back from a registerService call. This needs to be Perlified. The agent is NOT a web script so that isn’t a problem. The isAlive “pinger” can be ported to Perl, but since it uses threads it will run slower in Perl than it did in Java. In any case, the entire registry can be written in Perl.
Decision: write a CPAN distribution
Decision: write an installer
Martin suggests “Perl Hacks” book as a must-read.
Problem #2: Services
need to support legacy. All 1300 services are currently RPC, so we have to keep that.
We need to add a field in the registry to indicate which style of encoding is being used. We prefer document-literal-wrapped.
Separate field in the database, API, LSID metadata, … field called “style”. Currently have a field called “category”, which has values “moby”, “moby-async”, and unofficially “post’. Separate “style” from “category”? Probably a good idea.
Tell Wendy that we need to put the async protocol up on the website.
IFF we provide “correct” WSDL will that make people happier? Maybe… we can provide WSDL in ~90% of the cases (though NOT for validation!)
Burning issue is that we don’t have XML Schema. Why? Because we allow more specialized objects to be passed into a service (and problems with HAS relationships). The world is moving to RDF, and RDF also cannot be expressed in XML schema, so the “political” arguments against Moby are going to eventually die-out.
One problem is that we pass a full XML document in our SOAP:body. If we use document encoding, we will need to strip the XML header which has other encoding info that we want to have… and the message will have to be parsed twice – once by the SOAP libraries and once by our Moby libraries (because we don’t have an XML schema to give to teh SOAP libraries to unmarshal the objects) and that will give us unacceptable overheads.
If we move to a REST style, then we don’t have these problems, but we don’t get any (what?) advantages of WSDL or SOAP.
We can use string encoding and send Moby messages exactly as we do now in teh body of a document-style SOAP message. No advantages of the SOAP libraries, but also no overhead of double-parsing of teh message (exactly as we do with the Moby XML-RPC style right now)
Conclusion: INB – could you consider asynchronous services support from a REST perspective and suggest a specification?
CONCLUSION: we will support RPC, Document-style and REST services, but REST services cannot (right now) be asynchronous.