Directory Service Live!
Today we finished version 1.0 of our directory service. This service is the first in a range of changes/additions we will make to the EDRA framework. All functionality as described in my previous posts is implemented in this first release. Below some implementation details for this service:
As a datastore for this ‘directory service’ we decided to use Active Directory. Of course using UDDI as a source for this is also a very (maybe even more) logical choice , but some requirements of our client made us decide to use Active Directory.
Because it is not that easy to implement a schema change in a company Active Directory, we used ADAM (Active Directory Application Mode) during development so we didn't have to wait before the schema change is implemented in the Active Directory.
After defining and implementing the schema in ADAM on our development server, the directory services was build using the default EDRA structure, created by the ‘CreateNewTemplate’ script. A simple caching mechanism is implemented within the service to reduce the relatively low performance of querying ADAM. The actual communication with ADAM is implemented in a ‘AdamProvider’ class that is registered in the directory service configuration file. This makes it relatively easy to implement an ‘UDDIProvider’ class in the (near) future.
The directory service is available through remoting and webservice interface. Because every service consumer within the architecture is allowed to use the directory service, none of the EDRA handlers for authentication or authorization are used for this service. During development no issues were found in using EDRA.
During the ‘deployment’ phase of our service however, we did encounter some (potential) issues. We think some adjustment need to be made in de setup and deployment scripts that come with EDRA. Especially in the situation that a ‘new service’ needs to be installed on the server that is already running an EDRA instance (and some services) we see some issues.
More on these deployment issues (and hopefully our solutions!) in a later post.
As a datastore for this ‘directory service’ we decided to use Active Directory. Of course using UDDI as a source for this is also a very (maybe even more) logical choice , but some requirements of our client made us decide to use Active Directory.
Because it is not that easy to implement a schema change in a company Active Directory, we used ADAM (Active Directory Application Mode) during development so we didn't have to wait before the schema change is implemented in the Active Directory.
After defining and implementing the schema in ADAM on our development server, the directory services was build using the default EDRA structure, created by the ‘CreateNewTemplate’ script. A simple caching mechanism is implemented within the service to reduce the relatively low performance of querying ADAM. The actual communication with ADAM is implemented in a ‘AdamProvider’ class that is registered in the directory service configuration file. This makes it relatively easy to implement an ‘UDDIProvider’ class in the (near) future.
The directory service is available through remoting and webservice interface. Because every service consumer within the architecture is allowed to use the directory service, none of the EDRA handlers for authentication or authorization are used for this service. During development no issues were found in using EDRA.
During the ‘deployment’ phase of our service however, we did encounter some (potential) issues. We think some adjustment need to be made in de setup and deployment scripts that come with EDRA. Especially in the situation that a ‘new service’ needs to be installed on the server that is already running an EDRA instance (and some services) we see some issues.
More on these deployment issues (and hopefully our solutions!) in a later post.
1 Comments:
Glad to hear things are going well Edward - drop me a line and let me know more about what you are doing with EDRA.
Ron Jacobs
rojacobs@microsoft.com
Post a Comment
<< Home