Directory Service
During a session to determine the requirements for our ‘directory service’ we decided to store some additional ‘role’ information for the services in our service repository. Within our architecture we would like to have the possibility to let our services react differently based on the ‘functional role’ off the service consumer. This means that a service can perform additional behavior based on the functional role that the service consumer has within an application. If no role information is supplied in the service request, the service performs its default behavior. If a valid role is submitted within the service request the service can, for example return some extra confidential data about an employee in case the functional role of the service consumer is ‘manager’.
So what does this mean for our directory service? The first version of this service will hold the following information for each service within the service repository: the logical service name, the roles the service supports (zero or more entries) and url information for every EDRA transport this service supports. At this moment our services only supports the default EDRA transports (webservice, remoting and MQ). Initially the service gets 1 service action to retrieve the information based on the logical name (and optional the transport) of the service. A simple caching mechanism will be used to make sure the service meets the performance requirements that apply to a service that will be used that much within the architecture.
One issue that has to be resolved is to determine what is the best way to deliver the functional role of the service consumer to the actual service. 'Forcing' the service consumer to supply this information as part of the request message isn't my favorite option. to be continued....
For the development, the VS.NET solution structure will be used that is created by the ‘CreateNewTemplate.wsf’ script that comes with EDRA.
Time to start developing!
So what does this mean for our directory service? The first version of this service will hold the following information for each service within the service repository: the logical service name, the roles the service supports (zero or more entries) and url information for every EDRA transport this service supports. At this moment our services only supports the default EDRA transports (webservice, remoting and MQ). Initially the service gets 1 service action to retrieve the information based on the logical name (and optional the transport) of the service. A simple caching mechanism will be used to make sure the service meets the performance requirements that apply to a service that will be used that much within the architecture.
One issue that has to be resolved is to determine what is the best way to deliver the functional role of the service consumer to the actual service. 'Forcing' the service consumer to supply this information as part of the request message isn't my favorite option. to be continued....
For the development, the VS.NET solution structure will be used that is created by the ‘CreateNewTemplate.wsf’ script that comes with EDRA.
Time to start developing!
4 Comments:
I agree that the role information should not be part of the message. That is, not at the service client side. The service itself should determine which roles it assigns to the identity of the message sender (i.e. the service client). The identity information should be part of the message header. Once the service infrastructure has succesfully authenticated the service sender and determined the correct roles, it could add this role information to the message header or - even better - the message properties. Message properties (available in FABRIQ) are never communicated outside the service boundary, whereas message headers may be re-used/copied to outbound messages.
Another comment, because roles a service-specific it shouldn't be necessary to register them centrally in a directory service, a service configuration file should be enough. However, for administrative reasons it may be easier to centralise role definition and mapping to security ids/groups. The result is then something that is very similar to the COM+ catalog which also lists components, their locations and associated security policy details (including role-based authorisation settings).
This post has been removed by the author.
Using message headers is the way to go for 'sending' this kind of information within EDRA. Unfortunately the concept of messages isn't that extensive in EDRA as it is in FABRIQ. to me it looks like the FABRIQ message is very much prepared for the future indigo message concept. For now will use message headers....
Post a Comment
<< Home