[Sis-ams] AMS deliberations

[Scott Burleigh]

Roger, thanks very much for such a quick and comprehensive response.  Some thoughts in-line below:

Roger.Thompson at scisys.co.uk wrote:
> 
> Publish/Subscribe would support the MO Common "observe" service, in 
> which the service Consumer would register interest in a subset of 
> available objects and the Provider would respond with asynchronous 
> status update messages.  The published objects are either pre-defined 
> [in the configuration data] and known in advance to both consumer and 
> provider, or dynamically created by the provider, in which case the 
> consumer can only subscribe to a specific object if its ID has been 
> obtained in advance [e.g. in a response to a Control message], otherwise 
> subscription is to a scoped sub-set.

Just to clarify in my mind: when you talk about the "published objects" being known in advance vs. dynamically created, in the messaging terminology I'm used to I would take this to refer to "message types" and associated object structures.  That is, I figure you're talking about a menu of all available types of messages (each of which transports some sort of object; a one-to-one mapping between object classes and message types?) that is provided in the data used to configure consumers and providers.

However, a provider can dynamically define a new message type.  A Control message might be used to tell a consumer to subscribe to the newly defined message type.  Alternatively, one of the topics that the consumer already subscribes to might be an abstract topic that maps to several specific message types, and the newly defined message type might be characterized as one of the types that this abstract topic maps to; in that case, the consumer should automatically start receiving published messages of the new type because of the implicit subscription that's already in place.  Does that sound right?

AMS as currently conceived covers all of this except the last part: there is currently no notion of abstract topics that map to multiple specific message types, and dynamically adjusting subscriptions in response to changing the scope of an abstract topic is even a little further from what is currently in the concept paper.  Certainly doable, but it will take a little thought.

> Request/Response would be used for transactional message exchanges, and 
> could be used to support the MO Common "control" and "manage" services. 
>  Two cases have been identified:  1) a control message from service 
> Consumer to the Provider, with optional response(s) from the Provider; 
>  2) a request message from service Consumer, with an associated response 
> message containing the requested data.
> 
> By "Mail" I mean an e-mail like service, involving delivery of messages 
> to a mailbox, that the recipient can retrieve messages from at some 
> later point in time.  Useful for unsolicited messages from Provider to 
> Consumer.

I would suggest that the best way to provide this kind of capability might be to use AMS message transfer on top of the DTN "bundling" overlay network protocol, which already has a "pick up from mailbox whenever" feature built into it.  AMS messages are delay-tolerant by their nature anyway; upon registering as an AMS node that is prepared to receive messages at a specified DTN endpoint, the consumer would immediately start receiving any messages destined for it that were queued up at that endpoint, regardless of when they were sent.  (DTN also provides for assigning a "time to live" to each "bundle" so that the producer of a message can assure that the message is silently destroyed if it hasn't been picked up by its destination application after some predefined length of time.)

> I'm not sure whether or not an e-Mail type interaction is necessary, or 
> even whether it is significantly different to Request/Response.  I 
> suppose we were starting from the position that the Request/Response 
> interface is based on an open end-to-end connection/session between 
> consumer and provider, while Mail implied some form of connectionless 
> store-and-forward.   However, this distinction may not be necessary if 
> requests and responses do not require an open connection, in order to 
> handle discontinuous contact.

Here again I think running AMS over bundling could provide the functionality you're looking for.

> File/Transfer would allow for bulk data transfer between service 
> consumer and provider, in either direction.  In a SIS context, we 
> assumed this would be provided by CFDP, not EMS.

Sure.

> All services would need to exist within a partitioned context.  In this 
> sense the world is partitioned in two dimensions:
> 
> "Domain":
> This is used to decompose the world into a scoping hierarchy, to ensure 
> uniqueness of identifiers, etc.:
> i.e. Mission.Spacecraft.Subsystem.Component.Object
> The same service may be instantiated for multiple domains.  Its a good 
> idea to make sure you're conneting to the right spacecraft ...
> 
> "Session" or Timeframe or, I believe the term you used was "Continuum":
> This is used to separate data that would otherwise be potentially 
> identically keyed - live operational data, multiple simulated or test 
> data series, and maybe historical replay data series.

We should discuss this some more, but I think the AMS notion of "message space" (rather than the "continuum" notion) works for both of these purposes.  A message space is a set of communicating nodes for a single instance of an "application", characterized by the combination of two orthogonal labels: "application name" and "authority name".

The idea is that, for example, "Genesis" and "Phoenix" might be two applications while "ops" and "test" might be two authorities, and all four combinations of these are potential message spaces.  Message spaces are closed, in the sense that messages don't cross message space boundaries, so it's straightforward to keep test traffic distinct from operations traffic -- for both missions -- even on a common LAN.
  
> The timeframe can be different for each session:  the live session is 
> presumably synchronised with the present;  simulated sessions can be in 
> the past, present or future; replay sessions can be past or future. 
>  Timeframe for simulated and replay is externally controllable - it may 
> be paused and stepped; or evolve at a real-time rate, faster or slower 
> than real-time, or at a random rate [e.g. as fast as possible].  Not 
> sure if this has any impact at all, other than the potential for 
> "continua" to be dynamically created ...

Right, it's easy to create a new message space dynamically: you just fire up one or more registrars for it.

> Not all services would be available for replay sessions - you can 
> observe history, but not change it.
> 
> Other issues to be considered:
> -  User [Consumer] Authentication:  access rights may be limited to 
> certain services for certain domains and certain classes of session

This is important, but it will take some discussion.  As currently conceived, AMS does not yet support anything like this.

> -  Security

Here's another point on which I think we can save ourselves some anguish if we run AMS on top of DTN bundling: a great deal of effort is going into the design of solid security measures for bundling, at a couple of layers.

> -  Quality of Service

Yes, this goes to point (1) of my earlier email.  Let's discuss.

> Not sure if that's got close enough to the issue to identify the issue 
> raised in November.

There was something else, but it's still not leaping to mind.  I'm sure it will come up again.

> Sorry its a bit of a ramble ...

Not at all, Roger, this is terrific.  Comments from anyone else?

Scott