[Sis-ams] better subject-matching?

[Scott Burleigh]

Edell, David J. wrote:
> Tim,
>  
> Advanced filtering options could have potential usage, and if I 
> remember correctly are available to some degree in the software bus of 
> Goddard's cFE.  I don't think its worth the added processing costs to 
> change to a string-based subject ID to accomplish that though. 
>  
> At a minimum, there's always the possibility of psuedo-filtering by 
> specifying ranges of subject-IDs for specific categories, which 
> is sometimes done on its own to organize ID listings.  This becomes an 
> implementation choice within a program though, rather than a 
> specification. 
>  
> I think the SubjectID, UnitID, RoleID field combination is intended to 
> give a similar effect in combination with the "all subject" and "all 
> role" subscription types.  It's been a while since I've looked at 
> these field definitions though, so I could be wrong.   This might be 
> another topic for discussion at Berlin.
You're right, David, that's exactly what the "domain" concept in 
subscriptions, announcements, etc. is all about.

The problem here is that AMS is really intended to be for very high 
performance (or, alternatively, for acceptable performance on highly 
constrained hardware) in messaging, and string matching functions just 
take a whole lot more processing time than integer comparison functions; 
also, strings are typically a lot bigger than integers, so they consume 
a lot more bandwidth -- not necessarily a big deal in Earth orbiters, 
but a fairly big deal in deep space operations.  So the design decision 
to use numeric subject IDs rather than strings was deliberate.

At the same time, the question of supporting more powerful subject 
matching capability does come up over and over again; most (maybe all) 
commercial message-oriented middleware systems have it.  The approach 
we've been taking is to say that where these capabilities are needed you 
presumably don't need high efficiency at the same time, so you can 
afford an extra transmission hop, in which case the AMS Proxy 
Architecture (section 6.1 of the spec) is the most flexible and powerful 
way to provide this functionality.  I believe CNES, in fact, is already 
contemplating development of a prototype AMQP-based AMS Proxy system.

Scott
> ------------------------------------------------------------------------
> *From:* sis-ams-bounces at mailman.ccsds.org 
> [mailto:sis-ams-bounces at mailman.ccsds.org] *On Behalf Of *Ray, Timothy 
> J. (GSFC-583.0)
> *Sent:* Wednesday, September 10, 2008 6:15 PM
> *To:* sis-ams at mailman.ccsds.org
> *Subject:* [Sis-ams] better subject-matching?
>
> Hello all,
>
>  
>
> Does anyone see a (worthwhile) benefit to enhancing our 
> subject-matching capabilities to allow hierarchical subject-ids and 
> some pattern-matching?  Subjects would be transmitted as character 
> strings rather than 2-byte numbers, and subscribers would be able to 
> specify some sort of regular-expression format.
>
>  
>
> For example, if there were these subjects:
>
>         Attitude.sun_sensor
>
>         Attitude.momentum_wheel
>
>         Attitude.gyros
>
>  
>
> Then an application might subscribe to   attitude.*   to receive all 
> subjects within the 'attitude' domain.
>
>  
>
> I don't think this enhancement is needed for the typical NASA/Goddard 
> mission, nor are any missions (that I'm aware of) asking for it.  
> Still, it seems like something worth considering.  Does anyone have an 
> opinion?
>
>  
>
> Tim
>
>  
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sis-ams mailing list
> Sis-ams at mailman.ccsds.org
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-ams
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sis-ams/attachments/20080910/c52d7ed1/attachment.html