Service Repository Overview
Service Repository. What is it?
Service Repository is an open source distributed "no single point of failure" web service directory for registering info about your services(which can be used by accessing an url).
It contains a very easy to use API which acts like a proxy for the clients of your provided services - proxy which queries the Service Repository repository first for locating where you have registered your services and then connects to them. The API also helps you as service provider registering your services to Service Repository without altering your existing code.
One of it's main features is that it helps you get rid of hard coded dependencies to (web/rest)services you or your clients might have, bringing the benefit of more hot deployments by providing a versioning mechanism found in the information about your service.
By using Service Repository Client proxies you can benefit from their internal load balancing mechanism, which will decrease server load where your services are hosted, though increasing bandwidth and availability of your service's response time.
How it works
Usually a client will request some service(web service or rest) on server.
Mostly software is designed to have the address of a (web/rest)service hardcoded, or being stored in some other flavour which usually is designed to be single point of failure. This may result in service being out of order, cold costly deployments, hardness of managing both new and old versions, or rigid upgrades affecting uptime and user experience.
So we thought of a no single point of failure service that will resolve the following problems:
- increase availability of your existing (web/rest)service without impacting your current architecture
- increase scalability of your existing (web/rest)service without impacting your current architecture
- turn your painfull cold deployments into easy hot deployments
- easy management of versioning with having the possibility of having both old or new versions of a service running the same time
- easy maintainance of this software by making it open sourced under this terms of license
- share it with others for free
Now here comes our solution. Some metadata about your (web/rest)service will be registered in Service Repository. We simply called this metadata "artifact". An artifact has a key which will be used for lookup and some info like url where your server runs as data. When your service container will start this artifact will be published to a Service Repository.
But as we've mentioned this is not a single point of failure solution. So what we advise you to do if you want to enable this feature is to register an artifact to more than one Service Repository.
Also if you have the same version of a (web/rest)service running on separate machines or on the same machine but on different urls you can register it under the same artifact key as shown below:
All the above registration scenarios of a (web/rest)service to a Service Repository are handled by Service Repository Registration Client. Let's see what happens when registered artifact will be fetched from Service Repository.
The artifact is published on a distributed Service Repository though the client can fetch it. Of course fetch from a Service Repository because of various reasons(repository can't be found, connection to it is too slow, it's not registered anymore in there due to a previous power failure in our data centers). If specified client will try to lookup this artifact in the next available Service Repository.
The usefull info has been brought now to client from Service Repository and ready to be used. The client will now connect based on the info that is stored in the artifact to any available matching (web/rest)service.
If you have registered more than one (web/rest)service with the same artifact key and request to one of them fails, client will switch it's calls to the next available (web/rest)service.
The whole fetching/using scenario is accomplished by Service Repository Client Fetch module.