DRAFT
Right now the design for the service is strongly modeled on the IdP, partly because it’s rock-solid stable and secondarily to allow reuse of as much code as possible. The major difference is that this is not, contrary to expectations, a web application. The main reason for this is that introducing HTTP as a transport, while likely making future agents somewhat easy to develop, greatly complicates the re-development of the C++ agents we have now. HTTP is also quite over-complicated for the requirements of this scenario. On the down side, that requires that the service be developed as a stand-alone Spring application, which will create some additional complexity. For now, Spring Boot isn’t a candidate for this, but we could always introduce it at a later stage if it were beneficial.
The root Spring context, as with the IdP, contains most of the “infrastructure” beans that provide low level support, and is not designed to be reloadable. This is primarily because much of the customization for these beans comes from properties, which are not themselves reloadable. The root context also contains the Spring Integration objects that provide networking and messaging support, currently limited to TCP. The majority of the rest of the architecture will hopefully be made up of a variety of reloadable Spring service contexts, much as in the IdP.
The first “new” such service is one that exposes an EndpointManager interface to the Spring Integration layer to identify the possible recipients of messages. Reloading it would refresh the possible message destinations.
Many of the other services should be identical to those in the IdP, such as the metadata and attribute resolver/registry/filter services. Unlike the IdP, it is a possible goal initially to support multiple instances of these services in order to adapt the SP’s current behavior. While most (and preferably nearly all) SPs define default configurations for metadata and attribute handling that are reused even when application overrides are used, there are deployers that insist on isolating these configurations.
To accomodate this, the proposed (yet to be prototyped) architecture is to layer the concept of an “Application” into the remoting components as the destination of a message. The current SP typically, though not universally, identifies the application involved with an operation by embedding an “application” member into the input data. This revised proposal is to promote that value to the top level as the name of the input object, targeting the Application object that should receive the request. The Application(s) would be auto-deployed into the net.shibboleth.sp.remoting.EndpointManager alongside any other objects implementing the net.shibboleth.sp.remoting.Endpoint interface (e.g. status/monitoring). Applications could then be hot-deployed through reload of the EndpointManager service.
Internally, the Application objects would dispatch messages to another set of lower-level auto-wired components that perform work for the SP agents. Agents would map requests to Applications in some fashion similarly to today, create a message targeted for that Application, and then embed the additional message inputs in a TBD manner (probably an embedded “operation” member).
To achieve the separation that the “containment” relationship provides now between Applications and components like metadata and attribute handling, the various reloadable services for these functions would be injected into the Application objects with Spring. Applicatons would then be free to reuse (or not) common instances/configurations of these services as required.