[MOBY-l] My MOBY overview and questions

[mlinks at gene.pbi.nrc.ca]

Mark Wilkinson wrote:

> For the most part correct.  It isn't entirely clear to me yet whether it is always feasible to
> require an object as input.

	I would beg to argue.  I don't see how you could remove the input
object?  If you have a service and provide it wth nothing don't you get
exactly that?  Secondly if a service does not take a MOBY object as input
then how is it useful within MOBY?

> > Q. Does a class have to be listed at Moby to be useable or will the
> > service just not be fully 'moby-compliant' if it uses non-moby classes?
>
> Well...  if it uses non-moby classes, then it 'breaks the rules' as I understand them.  If you want
> to roll your own class, and for whatever reason not include this class in the data_type.xsd document,
> you will then have to write your own data_type.xsd document, as well as your own port_defs.wsdl
> document pointing to those data_types, and your service.wsdl document will then point to your local
> port_def's.  So long as you have registered your service.wsdl with MOBY-Central it will be discovered
> by MOBY Clients.

	I don't see the need (or desire) for MOBY-Central to catalogue
services that are not fully MOBY compliant.  You could (on the Client
side) easily reference a secondary repository of services (i.e. a local
MOBY-Central).  This pushes the problem off on the client.  If you (the
Client) know about other quasi-MOBY services and want to use them then
great.  As I see it the Client would use MOBY-Central and at some point
would switch to use a local service repository (or in tandem).  The idea
of MOBY-Central being the end all of service repositories is only for
those services that are fully MOBY compliant.

Thoughts?

> > Q. Can we create new classes by mixing other classes together, how
> > complex can a class be, is this limited only by the imagination of the
> > service provider?

	From the MOBY-Central perspective the complexity of a given class
shouldn't matter.  So like Mark said the only difficulty arises at the
Client side.  There is a operational issue on classes being to simple in
that a transition from one class to another would likely take more
intermediate steps if the class types are very simple.  I don't personally
see anything wrong with that so long as the environment exists for the
clients to do the transition without human intervention.

> > Clients can then query
> > MOBY-central for a service that will take the client's input class and
> > return the desired output class.
>
> correct.

	And the Clients could try to deduce the protocol for changing A
into B when there is no 1hop path from A to B ( I just can't wait to see
this work automagically ).

> > Q. Do we register a service or a server - could we register a server and
> > have Moby-Central query the server on a regular basis to get a list of
> > services that it currently provides?
>
> You register the service/server.  We did discuss automated updating briefly, but I think the idea was
> abandoned as being unnecessary and too complex v.v. the problem we are really trying to tackle at the
> beginning which is data-host interoperability.  Perhaps in the future MOBY-Central will become
> 'smarter', but that isn't part of the *immediate* plan.

	I think we can safely assume that MOBY-Central will routinely test
all of its registered services to ensure that the links are not dead.  To
this end I think it would be a good idea to enforce that the registration
of a service requires a test input and a known output.  This is also going
to greatly help the prototyping/development.

> > Q. How will the registering of a service at Moby-Central work - is this
> > a manual step the developer will have to do or can it be done
> > automagically?

	I dont't see this as being manual (eewwwwww).

> Depends who writes the MOBY-Central code ;-)  volunteers?

But of course...

> > Q. Will MOBY-central detect when a service is offline and not return
> it > to the client or will that be up to the client to detect - it
> would be > nice if Moby-Central took care of these things.

> I agree... but the overhead might be quite high if we do that.

If it ever gets so bad we will have MOBY-Central off load it to some
other computer(s).  (hey Mark I think MOBY-Central needs a cluster.  nudge
nudge)