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.
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.
Without the single point of failure service that helps to solve the following problems.
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.
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.
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.
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.