Service Repository

For registering information about our services or the services can be used by accessing a URL, we are using service repository. Service repository is an open source distributes “no single point of failure” web service. The API provides a service provider for registering our service to the service repository.

Service repository Features

  • 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.
  • Client proxies 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.

Working of service repository

The following steps are used for working of service repository.

1)      Client will request some services or web services or rest on server.

2)      Being stored in some other flavor which usually is designed to be single point of failure and this may leads to the following result.

  • Service being out of order
  • Cold costly deployments
  • Hardness of managing both new and old versions.

Without the single point of failure service that helps to solve the following problems.

  1. Increase the availability of the existing (web/rest) service without impacting the current architecture.
  2. Increase scalability of the existing (web/rest) service without impacting the current architecture.
  3. Turn your painful cold deployments into easy hot deployments.
  4. Easy management of versioning with having the possibility of having both old and new versions of a service running the same time.
  5. Easy maintenance of this software by making it open sourced under this term of license.
  6. Share it with others for free.

The solutions of the single point of failures are,

1)      One solution is by using the metadata artifact. An artifact has a key which will be used for lookup and some information like URL where your server runs as data. The service container will start this artifact will be published to a Service Repository.

2)      Another solution is to register an artifact to more than one service repository.

3)      We can use 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 registration scenarios of a web or rest or services to a service repository are handled by service repository registration client. The below actions are happeni9ng when the registered artifact will be fetched from service repository.

Failure of service repository occur in various reasons like  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. At this time the specified client will try to lookup this artifact in the next available Service Repository.

The useful 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.

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.

Service repository life cycle

 

 

During the system decomposition phase the analyst identifies the requirements for new services. The services get approved and appropriate service contracts are created and stored in the repository. At this point the service moves into implementation phase. The development team takes the responsible for creation and maintenance of service implementation artifacts and storing them in the repository. After completing the implementation phase the service is deployed into production. After the deployment phase the repository information is enhanced with the deployment information. After the appropriate approval the services are translated into service enhancement or new service versions captured in repository.

Capabilities of repository

1)      Developer efficiency:- It permits an organization to keep track of available services and service related artifacts and consequently permits for reuse of existing enterprise services related assets.

2)      Runtime governance:- It permits organization to virtualize and centrally control services endpoint addresses.

3)      Service cataloging and discovery:-During the service definitions cataloging the following information’s are captured.

  • Links to the auxiliary documents imported by the service definition document (such as XML schema documents, messaging semantics definitions)
  • XML namespaces used by the service contract documents
  • Name and description of the interfaces and the XML types used by the service contract
  • Links to the policies governing service invocation and execution

The repository provides discovery capabilities that are extensible and can be accommodate a wide range of domain specific discovery queries.

4)      Validation:- As the point of access to service-related information, the service repository should enforce organizational and domain-specific business rules, ensuring conformance of these artifacts to the enterprise policies and standards. This ability to enforce validation rules makes the repository a focal part of SOA governance.

5)      Dependency management:- As the number of services grows, tracking all these dependencies and calculating the impacts of changes becomes a difficult task. The service repository can simplify it by supporting the management of relationships between service artifacts. The repository should provide standard relationship types; it should also permits the organization to extend these types with additional ones based on their additional requirements

6)      Service evolution and versioning :- Once created, services typically evolve over time and this evolution can be leads to changes in the service functionality, semantic messaging, and implementation. Many of these changes will needs to creation and deployment of a new version of the service. In order to track all of this versioning information, the service repository should provide versioning capabilities for all service artifacts, regardless of their type.

7)      Artifacts publishing governance:- As the service repository becomes a centralized collection of all of the information about its service-related assets, it needs the same governance as any other enterprise assets repository. This type of governance typically provides permissions for publishing services-related artifacts and artifacts publishing approval processes.

8)      Support for multiple artifacts types:- One of the main requests in creation of a service repository is a great diversity of service-related artifacts, including XML documents that define services interfaces and messaging schemas, implementation code, UML diagrams, and text documents. The use of a generic representation for the different asset types can significantly simplify the repository implementation.