Proxies
Summary
OSIDs define two kinds of managers; one with proxies and one without. Proxies serve to pass necessary information about the context of the environment to an OSID Provider.
Native Flow
In a native application, the environment is expected to be understood by an OSID Provider without any "help" from an OSID Consumer.
These OSID Consumers do not pass any information to OSID Providers who are responsible for getting what they need from their own environment and perhaps with the help of other OSIDs. These OSID Consumers use the normal OsidManagers to launch OsidSessions. This is the way to do it when using OSIDs on the client side.
Server-Side Flow
Servers process requests from clients. This also includes web applications such as servlets. The context of the client request includes information such as their time zone, preferred language, and most importantly, their authentication credentials. It is not possible for an OSID Provider to access this information without some help.
This information can be passed through to OsidSessions using a Proxy in OsidProxyManagers.
Where Does the Proxy Come From?
The OSID Provider in the above diagram is a consumer of the Proxy interface supplied by the OSID Consumer. The roles are reversed and this is one of the few cases where OSID Consumers can construct whatever they want and send it the other way.
Before we get too excited about this new-found liberation, we may yet want to organize things a bit further.
If the OSID Consumer is responsible for pawing through the client request to populate a Proxy, the OSID Consumer assumes what the OSID Provider needs. You might also argue that having arbitrary OSID Providers grab what it wants from a server environment it shouldn't understand isn't the way to go either. When theres a this vs. that, there's usually a third party.
The Proxy OSID
The Proxy OSID is the intermediary between OSID Providers and server environments. The Proxy OSID takes input from its consumer to produce Proxies used with OsidProxyManagers in other OSIDs.
The role of the Proxy OSID is to isolate both the knowledge of what the OSID Provider needs and the knowledge of the server runtime environment (Java Servlet API in the above example).
ProxyCondition
ProxyCondition is an OsidCondition. The ProxyCondition hardens several inputs, such as the authenticated Agent and various Locale information. The example above shows passing the servlet request instead. This requires an OsidRecord.
The choice is whether to encapsulate the transformation rules within the Proxy OSID Provider or whether to leave these swimming around consumer space.
Two Ways To Get To The Same Place
OSIDs define two managers, or two service entry points. One supports the passing of a Proxy and one does not. Otherwise, they are identical.
There's a design choice to be made early on which is whether or not to support the proxy mechanism. While it is necessary for server-side consumers, it also opens up a pandora's box of what can be sent out of band between OSID Consumers and OSID Providers. The focus can be on the OsidManager where the architect knows that a proxy is not necessary. The additional work of understanding how the Proxy will be used and aligning the Proxy OSID Provider with other OSID Providers is necessary when the OsidProxyManager comes into play.
Both mechanisms get to OsidSessions.
OsidSessions
OsidSessions reflect the resulting evaluation from what was determined from the environment, sent via the Proxy, or both. OSID Providers cannot be commanded by OSID Consumers. OSID Providers may use all the information, some of it, best match, or ignore it completely. We can see what happened through an examination of the OsidSession.
What about OSID Authentication?
OSID Authentication Process is yet another tool to encapsulate identity management apart from other work performed within an OSID Proxy Provider. This can serve to support different authentication mechanisms.
An Integration Perspective
The gist of the Proxy OSID is to broker the agreement between the server environment and other OSID Providers. It acts as a replaceable shim to orchestrate OSID Consumers and OSID Providers in the areas of identity and localization.
The Proxy OSID is a more replaceable component than a full blown OSID Provider you might want to reuse in a variety of environments. Keeping the touchpoint between the OSID Consumer and the Proxy OSID light generally eases replaceability and moves any assumptions about what other OSID Providers need out of the OSID Consumer.