[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Handle-info] Re: HVT - A concrete example - How to implement?

Hi Tony,

I'm beginning to get the fear.

Hopefully this is nothing more than me misunderstanding the new type
arrangements. Otherwise I might be in trouble.
From your outlined concerns in your email, I think it is more a misunderstanding due to an incomplete
description on my part. 
If the type registry is for system defined types only, then I can follow
where you're going. If it's also (or an extension of it) supposed to be for
publicly declared user defined types, then I'm not following.

You say

the registration of the abstract
services (as opposed to the handle value type)
such as OpenHandle

I don't know what you mean by "abstract services". OpenHandle - like many
My use of abstract service was a poor choice. What, I should have used was handle value type service (HVTS)
as opposed to handle value type encoding (HVTE). The difference is that the HVTE specifies the encoding of the handle value whereas the HVTS specifies the encoding
of a service reference (that is what is stored in the handle value), what the service does (its interface) and what it returns (encoding)
The OpenHandle service you are an HVTS. You specify a service a reference to a service that returns a specific encoding.

I just want to take this one step further and say that with the registry can be used to register any service. In this case
we register the service interface and its access point. The registry can the be used to location a specific instance of a specific
service interface.

other handle applications - merely gets some data from the HS (from the
handle values associated with the handle) and does something with that data.
Seems to me it's as concrete as the proxy redirect service.
You also make a distinction between an abstract service and the "handle
value type" which I don't really follow. You later say this:

Note that the abstract services will require a slightly different
description schema than the one used
for the handle value type.

I had thought that the aim of "typing" was to provide a semantic classing
only, and to use any handle registered with that type as a convenient place
to locate related info such as service endpoints, apis, documentation, etc.
This is exactly the purpose that I have in mind for the registry and implementing at the moment. As far as the slight difference in description is concerned, from some of my experiments with
HVT description schema and "service" description schema, it seems that certain fields within
the schema might have different cardinality requirements. Again, more experimentation is needed. 
If I'm following you, you seem to be suggesting that *each* instance of
service action (e.g. each separate format returned, or other service
behaviour) will require it's own type.

You seem to be aiming for something both bigger and smaller at the same
time. Bigger in the sense that more would (need to) be defined:

The registry will then provide the ability to search for services based
on their interface inputs, outputs, and
value added processing.

Smaller in the sense that we are inevitably dealing with a closed set of
types (or one that is "open" subject to abiding by the registry
requirements) if registry typing is mandated/recommended.
The plan at the moment (especially since we are starting with a focus on HVTs ) is to provide a standardized
description each HVT to enable the registry to enforce a minimum of description to allow for maximum type
discovery and reuse. I hope you are not suggesting that we let anyone describe their type anyway they feel
like using whatever scheme they want.

It is anticipated that this first version of the registry will be an experiment that will be iterated on and refined
for a while. We fully anticipate to have to modify any part of it, allow for externally defined schemata to be
either imported into the main description schema, or simply referenced within the handle type and somehow
indexed into the registry.
And what on earth does "value added processing" mean? Who will determine
that value?
Again, lack of terminology, this is only meant to talk about a service.
I am perplexed. It seems that the central type registry may be stifling by
being overly restrictive. If applications must adhere to whatever set of
types are provided then they will surely be limited. If, however, they can
choose their own types then they will have freedom to flourish, although
options for interop may be restricted.
I am not sure I understand your concern here. Applications will always be able to do whatever they want,
there is no restrictions as to what they want to do with any handles, HVT or services. The registry is only there
as a registry not as an enforcer of types.
The only point of the registry is to provide a type sharing and discovery mechanism. If one wants to ignore it fine.
I on the other handle one needs to find out about a type in order to be compatible with a specific application, they
go to the registry to find out.
I'm wondering where that leaves me with the OpenHandle service type. Maybe
user applications should steer well clear of the system types?
I am not sure what trouble you here. You have built a service to serialize handles, you can register your service (or not)
with the registry however you see fit. Do you want to register a HVT that indicates a JSON serialization of a handle value? Do you want to register a http based service that given a handle and serialization parameter expressed within a URL will
return you that particular serialization of a handle. You can do whatever you see fit for the distribution of your service.
How is that restrictive? The only restriction is that you will have to provide us with a description of that service that is
compatible with what the registry expect. If that description is what you are concerned with, we are opened to hearing
your suggestions.
I am wary also of this goal - seems a little centralized:

value added processing. Sort of like a web yellow pages (smart web) but
with typed service information which would
allow you more interoperability and maybe true distributed processing.
Again, it is only a registry not a centralized service delegation mechanism. I am only suggesting that a
registry of services will enable a more interoperable distributed processing paradigm.

Thanks,

Christophe

Cheers,

Tony


On 12/5/08 18:54, "Christophe Blanchi" <cblanchi@cnri.reston.va.us> wrote:

Hi Tony
Thanks for the follow up and further explanation on types. So, I understand
how a type (identified by a handle) might define a service interface, e.g.

12345/MyAPI

which would effectively class a set of service behaviours. Is that right?
Although I note you use the word "interface".
This is indeed a potential use of handle value type and one that I think
would be useful.
Service behavior, interface, for the purpose of our discussion, they
refer to the same logical concept of a handle value pointing a specific
service with specific set of publicly accessible operations.
So, to consider a concrete example - OpenHandle.

This is an open source project with an API that has a clearly defined set of
semantics. Returns one serialization (of a number of defined serializations)
of the handle value set for a handle.

Any ideas as to how you think this could be configured as a HVT? Under whose
naming authority, etc.? And would it be registered in the type registry? And
what handle values might be incorported into the HVT handle?

There is an instance of a service running at this base URI

http://nascent.nature.com/openhandle/handle?

although it is not intended that this be the only service - or even the
permanent location. I did toy with the idea previously of having a directory
of registered service endpoints, for experimental purposes registered under

hdl:10100/openhandle

See

http://nascent.nature.com/openhandle/handle?format=json&id=10100/openhandle

But that was just an early thought. Would be useful to register this service
type with an HVT and from that to be able to locate service instances.

Cheers,

Tony
As you mention, the OpenHandle could be bought into the HVT registry to
dereference the location of
the location of the service instance.

http://nascent.nature.com/openhandle/handle?format=json&id=10100/openhandle

could be expressed in a handle value as the type value combination
10320/JSON   10100/openhandle

The 10100/openhandle handle will be processed according to the
information (web proxy) associated
with the 10320/JSON value type handle.

I think that in the longer term, the registration of the abstract
services (as opposed to the handle value type)
such as OpenHandle into the HVT will be the logical extension of the
type registry.  Each service (and its interface)
would have their own handles.

The registry will then provide the ability to search for services based
on their interface inputs, outputs, and
value added processing.  Sort of like a web yellow pages (smart web) but
with typed service information which would
allow you more interoperability and maybe true distributed processing.

The type registry will have an OpenURL base service prototype to
demonstrate this functionality.

Note that the abstract services will require a slightly different
description schema than the one used
for the handle value type.

-Christophe




*****************************************************************************
*** DISCLAIMER: This e-mail is confidential and should not be used by anyone who
is
not the original intended recipient. If you have received this e-mail in
error
please inform the sender and delete it from your mailbox or any other storage
mechanism. Neither Macmillan Publishers Limited nor any of its agents accept
liability for any statements made which are clearly the sender's own and not
expressly made on behalf of Macmillan Publishers Limited or one of its
agents.
Please note that neither Macmillan Publishers Limited nor any of its agents
accept any responsibility for viruses that may be contained in this e-mail or
its attachments and it is your responsibility to scan the e-mail and
attachments (if any). No contracts may be concluded on behalf of Macmillan
Publishers Limited or its agents by means of e-mail communication. Macmillan
Publishers Limited Registered in England and Wales with registered number
785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
*****************************************************************************
***




_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info