Deploying Multiple Virtual Services for a Single Native Service
Often you will need to deploy a service on multiple endpoints to make the service available over multiple transports and/or security mechanisms. For example, you might want to extend the same service over JMS and HTTP transports. Or, you might want to allow internal users to access a service using basic HTTP user name/password credentials and you might require other users to submit digital certificates.
To accommodate these kinds of operational requirements for a native service, you deploy multiple virtual services for a single native service. For example, to make a particular native service available to consumers over both HTTP and JMS, you would create two virtual services for the native service: one that accepts requests over HTTP and another that accepts requests over JMS. Both virtual services would route requests to the same native service on the back end.
The following shows a registry in which a native service (SalesReportingService) has been exposed over two virtual services.
Figure 20. Virtual Services provide two transports for one native service
Note: | To make it easier to manage virtual services, consider adopting a naming convention like the one shown above. Doing so will make it easier to identify virtual services and the native service with which they are associated. Keep in mind however, that unlike native services, the names of virtual services cannot contain spaces or special characters (except _ and -). Consequently, if you adopt a convention that involves using the name of the native service as part of the virtual service name, then the names of the native services themselves must not contain characters that are invalid in virtual service names. |
