Re: client discovery related queries

For any association spanning namespaces (such as 
ElementConformsToProfile), providers in each namespace must support all 
the generic operations for that association.

On 7/23/2010 12:23 PM, sr!n!mg wrote:
> Hi,
>
> We have implemented providers (instance, association and method) using 
> Open Pegasus 2.7.1. The approach we took is that our providers will be 
> responsible for queries directed to implementation namespace where as 
> use the default pegasus interop provider for "pg_interop" namespace. 

I'm not sure this approach is feasible; I believe that the Pegasus 
built-in PG_Interop providers do correctly handle 
ElementConformsToProfile to a non-interop namespace without 
modification. This may work with recent versions of Pegasus, but 2.7.1 
is way out of date.

> We create the required RegisteredProfile instances in the pg_interop. 
> We link the Array registered profile instance to cim_computersystem 
> instance through elementconformstoprofile instance interlinking the 
> two cross namespaces. Now we have the elementconformstoprofile 
> instance having two object paths that has one end pointing to Array 
> registered profile (in pg_interop) and other end pointing to 
> cim_computersystem (in implementation namespace)
>
> The discovery logic used by clients is they get the array registered 
> profile and use the elementconformstoprofile association to get to 
> cim_computersystem.
>
> The question I have is:
>
>     * With our implementation only Associator Names, References and
>       Reference Names can be used. If client tries to do an Associator
>       operation, Pegasus throws an error. Is there a way to fix this?
>     * In general which SMI-S query is used for get to
>       cim_computersystem from array instance?
>

Associator, Associator Names, References and Reference Names are all 
required by SMI-S.  I believe CTP tests all four.

Paul

> Thanks,
> Srini