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!