Last week I completed a survey of the EDRA team for new functionality in the 1.1 release of EDRA. Today the results of this survey were published on the EDRA ‘Got Dot Net’ workspace. Based on the ranking that is provided on the workspace as a result of the survey I can tell that: WIZARDS is what we want! Further improved performance is high on the ranking list.

My own request for new features had nothing to do with wizards or performance. One of them concerned the introduction of some sort of a ‘service repository’. This repository contains endpoint (url) information of all services available within the architecture. In my opinion ‘service discovery’ is an important issue in SOA. In the current release of EDRA this ‘service repository’ feature is implemented by using one or more configuration files. In this case the configuration file is used in the user interface to get the url information for the services required in the user interface. This works fine when using EDRA (and services) for only one application, but what if we are creating services that are used within an enterprise by more than one application? Any change in the url of one service in the enterprise architecture needs a change in the configuration file of all the user interfaces that are using that service. Not the most ideal situation!

So what do we need? We need a ‘directory service’ that delivers access to the service repository. Whenever a user interface (or another service) wants to communicated with a service within the enterprise architecture, a call to the directory service is made, supplying the logical name of the requested service, to collect endpoint information of that service. This endpoint information is then used to make the actual service call to the requested service.

The service repository could even store endpoint information for more than 1 protocol (webservice and remoting). In that case it is even possible to decide at runtime what transporttype to use for calling a service. Unfortunately this is not possible when using the default EDRA version 1.0 features. To make this work we also have to abstract away the knowledge of the transporttype to use for calling a service within the EDRA world.

I think to use EDRA within an enterprise architecture we need to make some small adjustments like the one above. Now I know 'my wishes' are not on the EDRA version 1.1 feature list, there is only one solution: start building this features myself……