Request for applications defined within CeaCapability

[Paul Harrison]

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