Managing registry without a repository?

When it comes to SOA Governance practice, the first thing advocated is having a registry-repository. In almost all the cases, the registry and repository are two seperate entities. They are integrated using some utility to serve the purpose of a good SOA Governance solution.  When Oracle acquired BEA, it knew that with this acquisition it will get some powerful tools of SOA that are classified under Aqualogic series.

AquaLogic Enterprise Repository or ALER is now going to be rebranded as Oracle Enterprise Repository. What about Aqualogic Service registry (ALSR) ? Well, ALSR is nothing but an OEM version of Systinet registry (now acquired by HP). So when BEA was rebranding Sytinet registry, Oracle was also doing the same. Oracle rebranded systinet registry as Oracle Service Registry (OSR). Most of the people will now think that Oracle has redundant registry but it is not completely true. Aqualogic was not supposed to support oc4j servers whereas all products belonging to Oracle breed should support oc4j server. Though Oracle is now looking to come out of this thought process. Replacing embedded oc4j server with weblogic server in jdeveloper is one such example. But how did Oracle manage to have a registry without a repository? The answer is Oracle never had a full SOA governance solution in place because the governance process has to be automated. One cannot claim that he can manage the lifecyle of an asset without synchronizing the changes, that a service is undergoing, across the organization.

To avoid the changes that can occur while moving the assets to a new location, the importance of having a repository in place cannot be undermined. Moving one step further, the repository can have a workspace to facilitate accelerated development of artifacts.

SOA Governance

Any organization willing to implement SOA should already have a plan for its governance. Most people think that SOA Governance is optional and it’s not true. Without SOA Governance it is impossible to reap the true benefits of a full-fledged SOA. Some benefits that are directly related to success of any organization.

“With the widespread adoption of SOA, the challenges associated with SOA projects are emerging. SOA governance isn’t optional— it’s imperative. Without it, return on investment will be low and every SOA project out of pilot phase will be at risk.”

                                                        —Paolo Malinverno

                                                           Gartner, Inc.1

Failure to provide effective SOA governance exposes your organization to serious risks:

• Insufficient knowledge of available services
• General failure to reuse services
• Unnecessary, uncontrolled service duplication
• Resources wasted on services that can’t be reused
• Service sprawl across siloed SOAs
• Ineffective communication of best practices.

   

A good blog on SOA Governance: http://blogs.oracle.com/governance/

Defining SOA

If you ask 5 different people definition of the buzzword “SOA”, they all will come with a different answers. SOA is not something that can be defined in two or three lines. 

“SOA is the architectural style that supports loosely coupled services to enable business flexibility in an interoperable, technology-agnostic manner. SOA consists of a composite set of business-aligned services that support a flexible and dynamically re-configurable end-to-end business processes realization using interface-based service descriptions.”

To be more precise, any SOA must exhibit the following features:

Loose coupling – Services maintain a relationship that minimizes dependencies and only requires that they retain an awareness of each other.

Service contract – Services adhere to a communications agreement, as defined collectively by one or more service descriptions and related documents.

Autonomy – Services have control over the logic they encapsulate.

Abstraction – Beyond what is described in the service contract, services hide logic from the outside world.

Reusability – Logic is divided into services with the intention of promoting reuse.

Composability – Collections of services can be coordinated and assembled to form composite services.

Statelessness – Services minimize retaining information specific to an activity.

Discoverability – Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms.

This is important when the following objectives are to be achieved:

• Reducing overall total cost of ownership (TCO)

• Improving time to market

• Achieving business agility

• Fostering innovation

• Enabling compliance

• Improving the top and / or bottom line

• Increasing customer satisfaction and retention

• Global expansion

SOA Best Practices

Hundreds of Organizations are trying to demystify SOA and each wants to win the race by providing the best possible solution even if the infrastructure becomes heavy in the process.

Here is a good link which clears the air to a large extent:

http://it.toolbox.com/blogs/the-soa-blog/soa-best-practices-17730

Oracle’s breed of products in making SOA a reality are unmatchable: 

http://download.oracle.com/technology/tech/soa/soa_best_practices_1013x_drop3.pdf