C2MS11 — Replace simple service REQ/RESP

Replace simple service REQ/RESP and deprecate current simple service messages.

Numerous issues are present with the current Simple Service REQ/RESP Messages. These include:

• Destination Component is overloaded with two different meanings, depending on use.
• Using Destination Component for SERVICE-NAME essentially requires the mission to establish a naming convention to separate SERVICE-NAME from DESTINATION-COMPONENT strings in order to tell the difference between them.
• The Request can include a SERVICE-GROUP to further the SERVICE-NAME, sort of like namespacing, but this SERVICE-GROUP is not included in the Response message, which means that if needed in the Request, it is not possible to correctly correlate a Response to a Request.
• The paradigm does not include a publish MEP natively, so at some point in the past, GMSEC/C2MS declared that a Request Message could be used to publish information, completely outside the Req/Resp MEP.
• Current usage is to submit a request and then to have the response message indicate either the DESTINATION-COMPONENT of the original requestor or, alternately, the SERVICE-NAME associated with the original request. In keeping with other response messages, it should probably be just the DESTINATION-COMPONENT. It doesn't really need to have the option to use SERVICE-NAME, because the requestor is known. It also creates an odd and confusing alternate use, where in the current mode, the DESTINATION-COMPONENT is the requestor, but the SERVICE-NAME is related to the provider.

Together, this makes the Simple Service Messages hopelessly tangled. The effort here is to start from scratch, deprecate the existing messages and move forward with something more workable.

In this there are two factors that need consideration:

• The Simple Service (and its replacement) should be intended for emerging services that go online in an existing domain, but that have not yet been able to establish their own set of dedicated C2MS-derived messages. It should not be the case that services live forever on this Simple Service (or replacement) mechanism.
• The C2MS Messages themselves, perhaps in 2.0? should have a mechanism for extension without having to define new messages types. In other words, a service provider should be able to create a C2MS message that is simply expanded by what the service provider needs. If this can be accomplished, the Simple Service Paradigm is greatly aided, either by providing an easier path to offload the temporary use of Simple Service, or even by obviating the need for Simple Service.

Defer to a later release

This issue is important to work on, but doesn't fit in the timeframe of C2MS 1.1.