Request for applications defined within CeaCapability

[Paul Harrison]

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.

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