Service discovery
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……
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……
3 Comments:
The FABRIQ specification (part of the FABRIQ download from gotdotnet) does decouple logical and physical addressing and also specifies what is needed to use UDDI as "directory service". Unfortunately this piece of logic (and the specification of the UDDI supporting taxonimoies) has not been done yet.
I was curious about some more of your thoughts around a 'directory service'. Would you see a directory service running on the same machine as the app server hosting your services, or on a central machine independent of where your services are deployed? Would your services need to be aware of the directory service or just your clients? Would the directory service return URL information for a logical service name, or would the directory service forward the requests to the actual service?
jwanagel
The most ideal situation would be a separate server for the directory service, but it is no problem to host the directory service on the server that also host the other services within the architecture. In my opinion all ‘service consumers’ (user interface or service) needs to know where the directory service is located. This means if one of the services needs to communicate with another service, it needs to know were the directory service is to retrieve the URL of that other service. If no communication is needed with other services, services do not need be aware of the directory service.
In the way we are building it right now, the directory service only returns URL information. The directory service does’nt forward the call to the service. This would be more of the responsibility of a “service agent” (dispatcher). Our directory service can store more than one URL for a specific service. If a service supports more than 1 transporttype, the service directory holds more than 1 URL for that service. In this case a priority is given to one of the two transporttypes. If a service consumer does a request for a URL without specifiying the transporttype, the URL belonging to the transporttype with the highest priority is returned by the directory service. If the service consumer also supplies a “preffered” transporttype, this URL is returned by the directory service. To make this last functionality usefull we also have to introduce the concept of a “service agent” (facade). This service agent is the real interface to the service consumers (user interface, services). The service agent is capable of communication with the service on all the supported transporttypes for the service and delivers a ‘transport indepent interface’ to the service consumers. The user interface for example only needs a reference to the service agent and not to the real service interface (EDRA interface). Now no recompile or change is needed in our client application to switch between transporttype. This can simply be manipulated by making a change in the directory service on runtime.
Post a Comment
<< Home