C2MS12 — Replace simple service REQ/RESP

Replace simple service REQ/RESP and deprecate current simple service messages. Maybe call this "Generic Service".

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.

If we create a new replacement for Simple Service, need to account for the question raised in C2MS12-41.

Text from C2MS12-17, which was marked a dup of this issue:
= = =
Simple Service Request uses ME1 to indicate the target of the request, but this can have one of two mutually-exclusive forms:

Service Provider Name (a named instance of a component, such as FDServiceApp1)
A Service Name not related to a specific component (such as Flight Dynamics)
Meanwhile, the Simple Service Response also uses ME1 in a similar, but slightly different way. In the RESP, ME1 represents one of two mutually exclusive forms:

A Requestor Name (a named instance of a components that requested a service, or will receive data from the Service Provider, such as C2App7)
A Service Name not specific to a component (such as Flight Dynamics)
Note that when using ME1 to designate a component, it is always the target recipient of the request/response, but when specifying a Service Name, it is always the name of the Service Provided, which is more related to the responder than the requestor. In this way, the Request Message uses that form of ME1 to designate the recipient, but the Response Message in that form designates to the provider.

This dual-hatting of ME1 is pretty confusing. One major user of C2MS has modified these messages to separate out the two uses of ME1 into ME1 and ME2, shifting ME2 and ME3 to the right.

This issue requests to do that same thing, matching the modification made by that major user.

= = =