Page Comparison

About Service-Oriented Architecture (SOA)

In the modern day, information technology (IT) systems of the enterprise are continuously challenged with demands to serve ever changing requirements. In order to get more out of existing investments, rather than developing new applications to serve such demands, IT companies are moving towards the service-oriented paradigm. In the service oriented architecture, a service is a well-defined and self-contained function, one that would not depend on the context or state of other services. Developing services and deploying them using a Service-Oriented Architecture (SOA) is the best way to utilize existing IT systems to meet new challenges. SOA represents a new generation of distributed computing architecture.

According to the OASIS SOA Reference Model definition, "SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations".

In simple terms, Service-oriented Architecture is a collection of services. Services in a SOA can communicate with each other. This communication could take the shape of either simple data processing, or, it could even involve two or more services coordinating some activity. The combination of services, both internal and external to an organization, makes up a service-oriented architecture.

SOA is mostly popular because it promises interoperability between heterogeneous applications and technologies with least hassle in application integration. A service's loose coupling to host applications gives it the ability to share data across enterprises more easily. Using SOA's increase reusability, overall costs could be minimized with increased response times to ITs change requests. This results in rapid involvement of IT systems, for both old and new.

However, as the organization matures, they tend to face the following challenges with SOA:

• Number of new services increases
• Number of dependencies among services increases
• Number of service users (both internal and external to the organization) increases
• Users develop interest in different versions of the same service
• Users sign up for different service level agreements. For example, John's request will go through high performance servers, while Jennifer's requests go through regular servers.

If not properly handled, and organization's SOA could transform into a complex unmanageable mesh. To avoid this situation, an organization should (but not limited to) perform the following  throughout the entire lifecycle of services:

• Properly manage services creation, adhering to rules laid down by an organization
• Increase reuse of services, by "socializing" existing services
• Properly analyze dependencies of a given service, before changing it
• Provide service versioning and allow users to consume different versions of a given service
• Properly validate services for standard compliance
• Properly test services to assure quality of services
• Document both technical and business aspects of services to help consumers and providers
• Properly define who accesses what services
• Measure service behavior at runtime (for example, how many times this service is called, by how many consumers, etc..)

In other words, SOA should properly "steer" its enterprise IT system. This process is called "SOA Governance". Governance is derived from the Latin term for steering.

SOA Governance

It is hard to find a concrete definition for SOA Governance, as the term heavily depends on a multitude of factors. People tend to define SOA Governance differently.

In simple terms, SOA governance is a set of processes, responsibilities and tools that reinforces good behavior and help avoid bad behaviors. It is all about control. If you design a service for a specific purpose and for a set of consumers, you will want to have assurance that it will only be used for that purpose and by that set of consumers. You also want the service to be available, performing as it was intended for, and secured. Transactions must have integrity, at least to the degree that you originally specified. Most Importantly, you need to make sure defined processes and responsibilities are followed properly. For this you need to adapt proper measurement techniques (to measure effectiveness on the actions taken) in your SOA.

SOA Governance can be divided to two distinct phases:

• Namely design-time governance
• Run-time governance

Design-time governance spans over the entire service development cycle. For example, let's say a requirement analyst is gathering information to create a new service. Design-time governance makes the analyst's job easier by providing all related information on the requirement. Furthermore, it avoids service duplication, providing enough information on existing services and promoting service reuse. Upon properly defining service level agreements, the service will be properly tested and documented.

Runtime governance comes into play, soon after the service is deployed. It monitors operational aspects of a service (service performance bottle necks, who is accessing more, etc.). Unlike design-time governance, most runtime governance functions are automated. Reports generated in this phase are important feedback, for the next service design and development iteration.

To enable governance, software industry responded with two different categories of tools:

• Registries 
• Repositories

Registries and Repositories

A registry is a tool that keeps a list of services with their locations. On the other hand a repository functions as a tool that keeps information on how the services are used, how they interact, who is using the services and why they are used. These tools are considered as key enablers of SOA Governance. Usually these two technologies come together as an "Integrated" Registry-Repository, thus avoiding the need of duplicated data entry and the need to synchronize information. Additionally, it decreases the risk of inconsistencies that may exist between a registry and repository.

In a registry-repository, you can publish information on services that you already use, planning to use and those services that you need to be aware of. Information related to both internal and external services (to you/your organization) can be stored in this way.

Service reuse is the heart of SOA. Before implementing a new service, you can search in the registry-repository for existing implementations. This helps you to use an existing service either as it is or by developing a new service associating the existing service. Furthermore, registry-repositories help you discover associations among services. This helps you to get a better idea of any impacts on changing a particular service.

In SOA Governance, it is important to enforce organizational and domain specific business rules (policies) to validate artifacts before they are published on a registry-repository. Usually most of these policies can be described in (machine-readable) documents such as XML documents. Registry-repository can read such documents to interpret rules found in them to validate against artifacts as needed. Such validations can easily go beyond simple syntax validations. For example, there can be a policy enforced so that WSDL artifacts must only be using "Document/Literal" style for communication. Validation usually improves overall quality of artifacts stored in a registry-repository.

Typically, artifacts in a registry-repository undergoes lifecycle states of create, test, deploy and deprecate. A registry-repository performs the following functions:

• Enforces policies during transitions of the states of create, test, deploy and deprecate.
• Defines "who can access what?" of services. Access to certain services may differ depending on the user, user group or state of the service lifecycle.
• Sends notifications to relevant users once a change to a service artifact has been made.

As more and more services are introduces and reused, it is necessary to keep track of dependencies of each service in an organization. SOA registry-repository makes life easier by in this context, keeping inter-service dependency information as relationships among service information artifacts. For example, such relationships includes but not limited to Contains, Implements, Uses, Depends, etc. A registry-repository should allow defining custom relationships to cater organization-specific requirements.

Service artifacts evolve over time due to reasons such as fulfilling new requirements, yielding to different versions of the same service. A registry-repository should provide versioning capabilities that can enable automatic version control of artifacts stored. Additionally, a registry-repository also should keep older versions of artifacts to allow users migrate smoothly from one version to another.

A SOA registry-repository also need to seamlessly integrate its services with those in other SOA deployments. In other words, a registry-repository should federate with other SOA registries-repositories using open standards, and possibly appear as a single virtual registry-repository.

To implement SOA Governance in service run-time, a SOA registry-repository should provide a software development toolkit (SDK) to develop custom registry client applications and services. In this case the registry-repository acts as a source of operational and configuration data during runtime.

In summary, a registry-repository should provide the following features:

• Record information on services
• Search for an existing service for reuse
• Discover associations and dependencies of a service
• Enforce policies throughout the service lifecycle
• User access control
• Automatic version control
• An SDK for registry-repository extensibility

WSO2 Governance Registry

WSO2 Governance registry is an open source SOA integrated registry-repository. It provides capability for storing and managing meta data related to service artifacts as well as artifacts themselvesThe WSO2 Governance Registry is a fully open source, SOA-integrated registry-repository for storing and managing metadata related to service artifacts and other artifacts. There are two broad categories of artifacts found in the WSO2 Governance Registry.

• Resources
• Collections

A resource (an artifact) can be "anything" from  WSDL documents, XML documentsis any artifact from WSDL files to XML, Word/Excel documents, JPEG Images, etc. Within the WSO2 Governance Registry, resources under a logical entity can be grouped into a "collection" and stored. Every resource you put in the WSO2 Governance Registry becomes a center for social activity.

Eschewing the complexity (and WS-* focus) of specs like UDDI, the WSO2 Governance Registry uses the Atom Publishing Protocol (via Apache Abdera) to offer a standard and a simple RESTful remote interface, which can be accessed easily by custom code, feed readers, and browsers. The WSO2 Governance Registry It has been designed to both to encourage "grass-roots" community around your data and also to allow for IT-friendly governance.

The WSO2 Governance Registry is available under the Apache Software License version 2.0, and can be either used as a complete product or used in combination with components of other WSO2 products. User-specific components, extensions or UIs to the Registry can be easily added as Carbon components.

...

The content repository virtually can hold any type of content. But in order to give prominent support for SOA-type services,   it was is cased as follows:

• Special UI to capture both technical and non-technical details related to the services
• Separate upload UI's for Policy, WSDL and Schema, which are tightly related to SOA type services
• Built-in validation for Policy, WSDL and Schema

...

If you choose the first way and add a service bearing the name "OrderRegistration" with the namespace as org.acme.services, there a resource will be created a resource inside /governance/services/org/acme/services/OrderRegistration with application/vnd.wso2-service+xml as the media type. Similarly, you can upload a WSDL to the system and Governance Registry will automatically create a service resource for you under /governance/services collection. Additionally, if a given service has WSDLs/Schema/policies, Governance Registry will automatically upload them and create associations between related artifacts(resources).

So monitoring/querying of the location /governance/services gives vision of the services registered within Governance Registry. Another option is to enable notifications (e-mail, SOAP, HTTP POST) for this repository location. For advance advanced users, Governance Registry supports writing custom handlers for given media types.

The WSO2 Governance Registry is an on-going project. It undergoes continuous improvements and enhancements with each new release, to address new business challenges and customer expectations. WSO2 invites users, developers and enthusiasts to get involved or get the assistance from our development teams at many different levels through online forums, mailing lists and support options. We are committed to ensure you a fulfilling user experience at any level of involvement with the WSO2 Governance Registry. 

What is new in this Release 

The WSO2 Governance Registry version 4.5.1 is the successor of version 4.5.0 and built on Carbon 4.0.2 base platform. It has several defect fixes included in it. For a list of fixed defects in this release, refer to: WSO2 Governance Registry 4.5.1 - Fixed Issues. 

Enhancements:

• Performance enhancements due to refactoring the Carbon context. (Inherited from new and enhanced Carbon 4.0.2)

Known Issues

For a list of known issues in WSO2 Governance Registry version 4.5.1, refer to the following link in WSO2 Oxygen Tank: WSO2 Governance Registry 4.5.1 - Known Issues.

Community Resources

WSO2 is willing to provide you guidance for any technical issues or questions regarding the Governance Registry product. You can communicate with the WSO2 Governance Registry development team directly using the relevant mailing lists mentioned here: http://wso2.org/mail .

WSO2 encourages you to report issues and enhancement requests for WSO2 Governance Registry using the publicJIRA available at https://wso2.org/jira/browse/REGISTRY. You can also track their resolutions and comment on the progress.

Questions regarding the Governance Registry can also be raised through http://stackoverflow.com. Ensure that you tag the question with appropriate keywords such as WSO2 and Governance Registry so that our team can easily find your questions and provide answers.

For tutorials, articles, Webinars and similar resources, visit the WSO2 Oxygen Tank and search under t he Resources menu.

Support Options

WSO2 also offers a variety of development and production support programs, ranging from Web-based support during normal business hours, to premium 24x7 phone support. WSO2 is committed to ensuring that your enterprise middleware deployment is completely supported from evaluation to production. Our unique approach ensures that support leverages the open development methodology and is provided by the very same engineers who build the products. For additional support information please refer to http://wso2.com/support.  

...