Request for applications defined within CeaCapability

[Guy Rixon]

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.

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

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