SOA School: Governance 2.0 with Anypoint Service Registry


The Service Oriented Architecture stipulates a change in perspective for software purchase and development which traditionally limited itself to catering for the isolated needs of a department or sub-division of the Enterprise. SOA exploits emerging standards to facilitate the development and purchase of software so that the requirements of the Enterprise as a whole are satisfied. Thus, services are identified, defined and subsequently reused in orchestrations with other services that map to the processes which form the life arteries of the Business. SOA advises the use of a Service Registry to govern the initiative in order to ensure the proper re-use of existing candidate Services and their compliance to the policies of the Enterprise. That said, in recent times, with the explosion of APIs, the Enterprise has flung open its doors and windows and ripped off its roof in order to reach to the sky to exploit the vast array of cloud-based services on offer and include them in its software inventory. Thus, the New Enterprise has come of age and brought with it the need for a suitable form of Governance.  With Anypoint Service Registry, MuleSoft are the first to offer a cloud-based Governance solution which allows the New Enterprise to securely register, discover, manage and monitor its services as well as the consumers of those services. With this post, we’d like you to see for yourselves how sets the standard for next generation SOA Governance.

From Architectural Principles to Business Goals

The Service Oriented Architecture represents an attempt to have software development more aligned to the strategic goals of the Business. It strives towards a greater Return on Investment and Organisational Agility while affording the Enterprise the luxury of mixing and matching solutions from different vendors due to a more natural Interoperability between their products, as well as reducing the IT work load. These goals are achieved by embracing best-practice Guidelines in the design of solution logic.  We wish to focus your attention on how Anypoint Service Registry collaborates with Mule Enterprise Service Bus to ensure that these Principles are consistently embraced for the success of your SOA architecture and hence the Business that it serves.

Service Discoverability

The New Enterprise needs to ensure rapid delivery of new orchestrations of existing IT resources to meet with its requirement for agility in response to changes in Business Process. To this end it is essential to ensure that as Services are developed, meta-information about their purposes, capabilities and limitations is stored in a centralised location and made easily accessible both to Service designers and to potential Service Consumers for reuse. With its Service Repository AnyPoint helps in this regard by cataloging Version Information, Interface and Message Schemas (e.g. WSDLs and XSDs), location Endpoints as well as Runtime Policies. Tags and Custom Taxonomies can also be applied to make search and discovery a lightening fast operation.

Service Loose Coupling

It is necessary that Services and their Consumers both evolve with minimum dependency on each other. Anypoint’s Service Virtualization feature enables the dynamic lookup of Endpoints by allowing Service Clients to locate the Services through an Endpoint registered on the Service Registry which it will resolve at runtime to a concrete Service Implementation. The criteria for this choice can be represented by meta-data associated with each Implementation Endpoint on Service Registry. Thus, the contract between Service and Consumer remains the same but the runtime behaviour of the Service varies dependent on meta-data present in the service calls. The criteria can cover geographic region for example, or SLAs, language or customer category. Updating endpoint meta-data for your Services in Anypoint has no impact on the consuming Applications much less on the Services themselves.

Service Standardisation

Just as the Standardisation of Service Interface and Message definitions results in a natural interoperability between Services in a SOA Architecture because they all, as it were, speak the same language, it also produces a set of Services whose functionality is clearly understood for potential reuse. A Service defined on Anypoint can have any number of descriptive artifacts associated (per Service version). Artifacts such as WSDLs, XSDs and indeed anything that can add to the richness of understanding of the Service can be uploaded. The desired design commonality is not, however, limited to the technical aspects of the Service: cross-cutting concerns are ever present in IT architectures. Those of interest to the business fall in the realm of Policies governing Security, Quality of Service and Contract Compliance. Anypoint’s Runtime Policy Management enables the centralisation of Policy application: when new policies are dictated by the ever changing business model, they can be applied at runtime in a global fashion or on a per-consumer-contract based approach. For example, Security Policies can be applied to a particular consumer of a Service or to all Consumers without effecting the uptime of the Service.

Service Abstraction

Care should be taken to avoid Service Consumer to Service implementation coupling which could be brought about by exposing too much information about a Service. The principle of Service Abstraction promotes the type of Information Hiding that should also allow the Service owner to provide various levels of Quality of Service according to agreements with any potential Consumer. Anypoint facilitates this abstraction with its Contract Management feature. Service Consumers can choose to tie their use of a Service to a Contract for that service which guarantees for them a Service Level Agreement. You could expose a Service on Anypoint which has a number of SLA tiers associated with it. Consumers who have signed up for a certain SLA will use the same service as those with higher expectations, for example some Consumers might have a rate limit of 10 calls per hour (or any time unit) while others may have a higher 50 calls. The differentiation is made at the level of the contract, so the Service has no knowledge of its multiple usage scenarios. 

Secure Governance

All of the above functionality delivered by Anypoint Service Registry is realised while being particularly mindful of the tight security requirements of your Enterprise.  Anypoint Service Registry is protected with the best the Industry has to offer in the area of Security. Communication between Mule Enterprise Service Bus and Anypoint is executed by way of a secure Agent protected by WebSocket technology and HTTPS. At no point in time are any information sets contained in the messages passing through Mule sent up to the Service Registry. Anypoint only has knowledge of the meta-data associated with a Service. Likewise, access to this same Service meta-data is strictly protected by OAuth 2 based access-control so that only registered Service Owners and Service Consumers can see it whether that be on Anypoint’s UI or through its RESTful API.

See for yourself

We suggest you take a look yourself and see how Anypoint can help you guarantee the success of your SOA initiative.

We'd love to hear your opinion on this post