I was thinking application components would receive the information using push, which seems to be what you're thinking.
I was thinking that the aspect components could access the context information using pull, because their behavior is dynamic and potentially difficult to expose deterministically. By this I mean the purpose is to algorithmically inspect the execution context and expose a simpler model that can be pushed. Concretely casting the raw information into a push based interface seems unnecessarily brittle and expensive. By the way, doesn't the requirement for managed context extensibility seem somehow similar to the requirement for extensibility of configuration stream readers? Thanks...PC -----Original Message----- From: Jeremy Boynes [mailto:[EMAIL PROTECTED] Sent: Friday, September 15, 2006 10:47 PM To: [email protected] Subject: Re: Binding Context? On Sep 14, 2006, at 2:34 PM, Peter Cousins wrote: > These are interesting ideas. There are a few more things I think > should > be covered. > > I understand your motivations about coupling reduction by abstraction > promotion of the underlying artifact. > > One usage scenario would be logging the credentials of the requester > into a database for audit trail reasons. Given that for a given > service > component implementation, there could be multiple middleware bindings, > and each binding could have multiple types of credentials, it would be > helpful to have a declarative way for the service to declare > credentials > as authoritative. In that scenario I see the application function as being that of logging the credentials. In a simple case, the service interface for the application component could be: void logAccess(String identity) However, that in itself is not really sufficient as the interface does not convey what type of string should be passed. We want to know that this really is an identity, either through a tightening of the service contract: void logAccess(Principal identity) or metadata void logAccess(@com.example.UserId String identity) > For example, if I am using AMQP/Blaze with SOAP, what do I log? It > could be any one of the following: > * "user id" message property > * "app id" message property for trusted applications > * X.509 certificate used to sign the message > * WS-Security credentials in the SOAP header > > Whereas if I am using HTTPS with SOAP, it could be a similar set: > * "Authorization" http header > * "Proxy Authorization" http header > * X.509 certificate used for TLS/SSL > * WS-Security credentials in the SOAP header > > These bindings have no way of knowing which credential is > authoritative > when multiple credentials are supplied, so it seems the best way is > for > bindings to register a namespace with a binding context manager, and > present whatever they have received in their binding specific context. I'd view that slightly differently. I would like each binding to provide metadata about what it can extract from a message. For example, a socket processor can indicate that it is able to provide SSL identity, whereas a HTTP processor would say it could provide HTTP header information; a HTTPS processor could provide both. > This way an intermediate component like the "aspects" we discussed > could > be responsible for interpreting the policy to select credentials from > the lower level of abstraction and transform them into higher level of > abstraction. With the change above, I would see this more as the responsibility of the wiring framework rather than the aspects themselves. At the assembly level, we know we have a wire connecting the physical endpoint (the socket) to a component and that there are a set of policies (and other "aspects") that we want to associated with flows on that wire. In our scenario here, we want to invoke a component that will log the access for us and that component has declared that it requires the identity to log. Unfortunately, we just do not have enough information yet to determine which which identity to pass to the component. > > In this example, there could be three namespaces in the context > manager: > > > http://www.osoa.org/schemas/contexts/security/authorization.xsd > which could define a structure like: > authorizationContext > userId > authorizationData > > http://www.osoa.org/schemas/contexts/binding/amqp.xsd > which could define a structure like: > amqpContext > contentEncoding > headers > someCustomHeader > anotherCustomHeader > deliveryMode > priority > correlationId > replyTo > expiration > messageId > timestamp > type > userId > appId > clustered > > http://www.osoa.org/schemas/contexts/binding/http.xsd > which could define a structure like: > httpContext > authorization > userId > password > cookie > certificate > issuedTo > expiration > issuingAuthority > proxyAuthentication > userId > password > > http://www.osoa.org/schemas/contexts/binding/soap.xsd > which could define a structure like: > soapContext > wsseSecurity > userId > password > > wsTransaction > tid > > > And then a security policy aspect could have the following > Source soapContext/wsseSecurity/userId > Destination authorizationContext/userId > > Or could present a number of them in order of interest > Source soapContext/wsseSecurity/userId > Source httpContext/authorization/userId > Destination authorizationContext/userId > > Then the application need only pull authorizationContext/userId I'm almost with you here. The big difference I see is in "pull" - instead, if we already know from the application what it expects, we can push the right information into it. More importantly, we don't need to consider (process/extract) information that it does not need. It may be we're saying the same thing differently (email does that). I think the moving parts are same (front-end binding, extraction/ transform aspect, logging component) and the metadata is similar (what the binding has, what the component accepts, what the transform can do) and if there is a difference it is just in how the IoC controller/context manager uses that to assemble the invocation flow. > > Likewise this helps with the context propagation usage scenario you > alluded to in your mail: > > An aspect can be defined for call chaining that could handle amqp > context propagation, because it could take > amqpContext/correlationId > or > amqpContext/messageId > from the inbound and move it to the outbound call context > amqpContext/correlationId > > or for oneway short circuiting, could be configured to take the > amqpContext/replyTo > from the inbound and put it to the same place on the outbound call, > whereas if the application is going to handle the callback, > amqpContext/replyTo could be reconfigured before setting > amqpContext/replyTo on the outbound call context. > > The same approach could be used to conditionally propagate > soapContext/wsTransaction/tid. Yes. I see a chain of contexts being constructed as an invocation flows through from wire to wire, using references within a address space and suitably constructed messages when we hit a physical wire. I think it's important though to maintain separation between the namespaces for the different domains as users will typically want to focus on a single one. So, if I'm implementing a business component I may want to declare some requirements on say transactional behaviour but I should not care what the form of the transaction id is or how it flows across; similarly at a lower level, I should be able to flow a higher-level message that contains a transaction id and hence propagate the transaction without actually knowing that I did so. -- Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
