Request for applications defined within CeaCapability

Guy Rixon gtr at ast.cam.ac.uk
Sun Oct 14 04:40:32 PDT 2007 

On Fri, 12 Oct 2007, Paul Harrison wrote:

>
> 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
> > app).
> >
>
> 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.

Quite. And that's what we've agreed to do with STILTS: Mark will register each
new version as he produces it.

> 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...
>
> Cheers,
> 	Paul
>
> > Cheers,
> > Guy
> >
> > On Wed, 10 Oct 2007, Paul Harrison wrote:
> >
> >>
> >> On 2007-10 -08, at 14:36, Guy Rixon wrote:
> >>
> >>> Hi,
> >>>
> >>> 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
> >>>
> >>>   ivo://whatever/MyCoolApp
> >>>   ivo://whatever/MyAppServer
> >>>
> >>> as separate registry entries, one would register
> >>>
> >>>   ivo://whatever/MyAppServer
> >>>   ivo://whatever/MyAppServer#MyCoolApp
> >>>
> >>> 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
> >>> client
> >>> consuming the registrations. It makes the service definition self-
> >>> contained
> >>> and it fits well with VOSI and pull-registration. We trade a little
> >>> more
> >>> complexity in the schema for a lot less complexity in
> >>> installation and
> >>> operation.
> >>>
> >>> 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">
> >> 	   <xs:annotation>
> >> 	      <xs:documentation>
> >> 	         The definition of a capability conforming to the CEA
> >> 	         specification, capable of running one or more
> >> 	         CeaApplications
> >> 	      </xs:documentation>
> >> 	   </xs:annotation>
> >> 	   <xs:complexContent>
> >> 	      <xs:extension base="vr:Capability">
> >> 	         <xs:choice>
> >> 	            <xs:element name="managedApplications"
> >> 	               type="cea:ManagedApplications" maxOccurs="1"
> >> 	               minOccurs="1">
> >> 	            </xs:element>
> >> 	            <xs:element name="applicationDefinition"
> >> type="ceab:ApplicationBase" maxOccurs="1" minOccurs="1"></xs:element>
> >> 	         </xs:choice>
> >> 	      </xs:extension>
> >> 	   </xs:complexContent>
> >> 	</xs:complexType>
> >>
> >> 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
> >> http://www.manchester.ac.uk/jodrellbank
> >>
> >>
> >>
> >
> > 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
> http://www.manchester.ac.uk/jodrellbank
>
>
>

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

More information about the grid mailing list