Request for applications defined within CeaCapability
Paul.Harrison at manchester.ac.uk
Fri Oct 12 02:35:57 PDT 2007
On 2007-10 -10, at 16:42, Guy Rixon wrote:
> It's not the implementors I'm trying to help, it's those deploying the
> implementations. Also, the scheme avoids the mess we get at present in
> VOExplorer for DSA, where there are five different resources. The
> benefit to
> end users is great.
The current way that DSA works wrt CEA registration is a mistake
precisely because it does define a new "application" for every
service, even though the formal interface is identical for every
service and thus there should be a single CEA " asynchronous table
query application" registered that all services share - I believe
that the way that DSA is still registered was supposed to be a short
term hack for a demo that stuck to become established (poor) practice.
For this sort of use case there needs to be a different type of
relationship between the CEAApplication and the CEAService that can
supply the application. In CEAv2 this is dealt with by using the
ApplicationKind element that defines the applicationtype to be one of
Processing - this is the classic CEAv1 relationship between the
CEAApplication and the CEACapable services that claim to be able to
run the application. i.e. each service is assumed to be a mirror and
may be selected at random
DataProducing - in this case each CEACapable service that claims to
be able to run the application is not assumed to be equivalent but is
chosen according to the DataSet that is associated with the service.
How this choice is made is outside the scope of CEA itself.
> Personally, I don't have a problem with one app per service. That's
> how I
> deploy things by choice (with bundles like STILTS counting as one
So if each bundle is registered with the application description
encased within the CEACapability of the service, each STILS service/
Application when deployed will end up with a different IVOA ID, and
how is the client to know that each of these services is in fact the
same application? This sort of bundling would be best achieved by the
implementer of the application registering the CEAApplication himself
once, and then each deployer of the bundle simply registering the
service with a <ManagedApplications> reference in he CEACapability -
i.e. the current practice.
So in summary, I am cautiously in favour of this proposal (indeed I
have added it to my personal copy of the current draft schema - not
yet published), but it is only useful for unique applications that
are only ever to be deployed on a single server - DSA and STILTS are
not in this class...
> On Wed, 10 Oct 2007, Paul Harrison wrote:
>> On 2007-10 -08, at 14:36, Guy Rixon wrote:
>>> recent work with CEA and AstroGrid DSA (proto-TAP) reveals a need
>>> to define
>>> a CEA application inside the CeaCapability of the service providing
>>> it. E.g.,
>>> instead of registering
>>> as separate registry entries, one would register
>>> The latter form says, specifically, that MyCoolApp is only
>>> available via
>>> ivo://whatever/MyAppServer and nowhere else; the app does not have
>>> a formal
>>> identity. The old way of registering apps separately would be used
>>> instead to
>>> define a standard, mirrored app.
>>> Why would we do this? Because it's _easier_ to inline the local,
>>> unique apps.
>>> It's easier for the service provider, for the registry and for the
>>> consuming the registrations. It makes the service definition self-
>>> and it fits well with VOSI and pull-registration. We trade a little
>>> complexity in the schema for a lot less complexity in
>>> installation and
>>> This proposal applies only to schemata based on VOResource 1.0. I
>>> don't want
>>> to change the old oners based on VOResource 0.10.
>> This is not so easy to implement as it might at first appear with the
>> proposed 1.0 schema ( see http://www.ivoa.net/twiki/bin/view/IVOA/
>> CommonExecutionArchitecture) - I have been experimenting a little -
>> whilst it would be possible to define the CEACapability as
>> <xs:complexType name="CeaCapability">
>> The definition of a capability conforming to the CEA
>> specification, capable of running one or more
>> <xs:extension base="vr:Capability">
>> <xs:element name="managedApplications"
>> type="cea:ManagedApplications" maxOccurs="1"
>> <xs:element name="applicationDefinition"
>> type="ceab:ApplicationBase" maxOccurs="1" minOccurs="1"></xs:element>
>> i.e. the Capability either points to a list or managed applications
>> or a single ceab:ApplicationBase (which is the meat of the
>> Application definition excluding all of the Dubin Core metadata)
>> there are some issues I think with the naming of the application and
>> extra complexity of how a client might be able to discover the
>> applications that are available.
>> Dealing with naming first - There is no difference between the formal
>> identifier for the service and the application in this scheme - this
>> means that there can be only one application per server (presumably
>> not a problem) as the application normally takes its name from the
>> identifier of the whole resource - i.e. there is no place for naming
>> the fragment - though that could be added to the suggested capability
>> above. However, even then, there would only be one set of dublin core
>> metadata for both service and application, so the implementor needs
>> to be careful that the dublin core describes the application rather
>> than the service (even though the registry entry would be formally of
>> a Service type), as any registry browser would be displaying metadata
>> such as Title as feedback to the user.
>> While I agree that it is true that registering one application for
>> the server there is less work with this scheme, this is at the
>> expense of making life harder for a client that is looking for
>> available applications - only possible for a registry that allows
>> xquery and has "fine -grained" metadata.
>> I have to say that I am not sure that the benefit to the relatively
>> small number of service implementors outweighs the extra costs for
>> the client of having to deal with two ways of finding applications
>> and application servers.
>> Dr. Paul Harrison
>> JBCA, Manchester University
> Guy Rixon gtr at ast.cam.ac.uk
> Institute of Astronomy Tel: +44-1223-337542
> Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
Dr. Paul Harrison
JBCA, Manchester University
More information about the grid