Service Registries : WSIL & UDDI

Often there is a confusion on what is WSIL and what is UDDI, what is the difference between them, as on a high level, both seem to be the same.

Both Web Services Inspection Language(WSIL) and Universal Description, Discovery, and Integration(UDDI) specifications address the same task of Web service discovery. And both contain only references to WSDL's, but do not contain documents themselves.

If both serve the same purpose, why two different specifications..?

UDDI

The UDDI specification addresses Web service discovery through the use of a centralized model.

UDDI compliant registries serve as central hubs where service providers and service requestors come together and satisfy their needs.

There are, however, few flaws in the UDDI business model that prevents it from taking off (at least today) the way it was intended:

1. Not all records in the UDDI registries are really existing. There are instances where a service is registered in the UDDI, but the actual implementation do not. Infact, in an  independent research carried out by SalCentral, it is found that 2/3rd's of the service entries in the UDDI's are actually not existing. Also, there are situations where the entries are duplicated with different names. There is no proper moderation to these registries.
2. No Quality of Service(QOS) is guaranteed to the services registered. How can you trust a service registered in the UDDI by some service provider, and use it by giving your data? Though some implementations provide digital signatures for this, this is not in the standard spec for UDDI.
3. Also, UDDI requires the deployment and maintenance of a some infrastructure, thus increasing the cost of operation.

WSIL

This is where WSIL just fits in.

WSIL decentralizes the centralized model of service publication within a UDDI registry and distributes them such that each service provider itself can advertise its Web Services offerings. The service descriptions can be stored at any location, and requests to retrieve the information are generally made directly to the entities that are offering the services.

The primary difference between both is that the Web Service "find" no longer goes directly to a centralized UDDI registry. Instead, the "find" is sent directly to the service providers from the requestors. If the service provider is maintaining the service advertising, he would always have the latest and greatest, non-duplicated, trusted(based on the service provider) service offerings. Thus the centralized, un-moderated registry is now a decentralized, moderated registry distrsibuted over the web.

WSIL defines an XML based language by which services can be advertised to interested consumers.

Which is better?

It completely depends on the situation.

UDDI is more advanced to WSIL in terms of the capabilities it provides. If your use case doesn't require advanced functionality offered by UDDI(some impl. like OSR provide approval mechanisms for publishing, digital signatures, etc.), WSIL is the option.

If the use case is that the data needs to be centrally managed, UDDI is the option.

Note that each of these technologies are complimentary to each other.

inspection.wsil document

All the services are advertised through WSIL using a fixed document called inspection.wsil

Once an inspection document has been created, a consumer needs to be able to find it. Consumers would only need to ping a URL such as http://<host>:<port>/inspection.wsil to discover the file's existence for retrieval.

Creating a WSIL Connection in Jdeveloper

Jdeveloper has an inbuilt WSIL wizard, which lets you create a WSIL connection very easily.

Go to Resource Pallette --> New Connection --> WSIL

 

Give the inspection.wsil location(normally in the root of the managed server), managed server's credentials

That’s it!!!

Now, You may refer to all the webservices deployed to this host through this connection.

Thanks for going through my post, feel free to provide a feedback!

Some technical stuff on it

My other post on SOA briefs you what SOA is all about in a very generic, real life scenario.

Now, lets talk some technical stuff here.

There's no standard definition for SOA, it is just a methodology followed, and each one has his own definition for it. The best I feel is

SOA is an architectural style of building business applications using loosely coupled services, that act like black boxes, that can be orchestrated in a particular fashion to attain a specific business functionality.

SOA aims at a greater alignment between your business and IT infrastructure.

For a service to be a candidate in a SOA Application, it has to adhere to certain principles, otherwise called SOA Principles

Below are the principles each individual candidate in a SOA Application has to satisfy, as defined by Thomas Earl

1. Standardized service contract – Services adhere to a communications agreement, as defined collectively by one or more service-description documents. Services express their purpose and capabilities via a service contract. The Standardized Service Contract design principle is perhaps the most fundamental part of service-orientation

2. Service Loose Coupling – Services maintain a relationship that minimizes dependencies and only requires that they maintain an awareness of each other.

3. Service Abstraction – Beyond descriptions in the service contract, services hide logic from the outside world. This principle emphasizes the need to hide as much of the underlying details of a service as possible.

4. Service reusability – Logic is divided into services with the intention of promoting reuse. The principle of Service Reusability emphasizes the positioning of services as enterprise resources with agnostic functional contexts.

5. Service autonomy – Services have control over the logic they encapsulate. significant degree of control over its environment and resources.

6. Service statelessness - Services minimize resource consumption by deferring the management of state information when necessary

7. Service discoverability – Services are supplemented with communicative meta data by which they can be effectively discovered and interpreted. For services to be positioned as IT assets with repeatable ROI they need to be easily identified and understood when opportunities for reuse present themselves.

8. Service Composability – Services are effective composition participants, regardless of the size and complexity of the composition.

Any technology component that adheres to all these principles would be a candidate to be used in SOA, and the best software component that we could think of that satisfy all these features is a Webservice, and morevoer it is highly evolved, widely supported, and more that anything, ease of use. It has become the defacto standard for realizing SOA.

 The main goal of SOA is to connect disparate systems. In order that these disparate system work they should talk to each other seamlessly. SOA gives it a way of doing it thru ESB (Enterprise service bus) that acts like a reliable post office which guarantees delivery of messages between systems in a loosely coupled manner.

By organizing the enterprise IT around services instead of around applications, SOA helps companies to achieve faster time-to-service and respond more flexibly to fast-paced changes in business requirements.

It aims at building systems that are extendible, flexible and fit with legacy systems.

Hope this gave you a better understanding of SOA and its principles. My next post aims at introducing you to the Service Component Architecture which realizes all the SOA principles

Thanks for going through my post, feel free to provide a feedback!

Service Component Architecture(SCA) - Its all about assembly

We've been repeatedly saying that SOA is neither a technology nor a specification, but just an architectural approach in designing enterprise applications.

If that’s true, then how is it realized?

Is it with the help of services that follow those so-called SOA principles, and integrating them in a custom-fashion.

Yes, you may do that, but that becomes really difficult as the application and the number of underlying technologies grow

For this, you may require a standard way of assembling such things so that it simplifies and standardizes the overall lifecycle of the enterprise software.

Service Component Architecture is exactly that.

Similar to SOA, there is no standard definition to SCA. Some of the definitions that I would like to share are below

"Service Component Architecture is a specification that defines how various enterprise pieces are created and assembled together as modular components to increase IT sustainability and flexibility"

"SCA is a unifying framework for standardizing and simplifying the development, deployment and management of atomic service components"

"SCA provides a model for composing applications that follow SOA principles"

In simple terms, its like a platform on which you develop your SOA applications in a more standard, easier and flexible manner.

SCA is first started with a collaboration of major IT vendors under OpenSOA group, and later handed over to OASIS.

Anatomy of SCA

The SCA Assembly Model consists of a series of artifacts, which are defined by elements contained in XML files.

Following figure depicts various artifacts of SCA

 

The basic components of SCA are:

1. Composite : It is a single unit of deployment, irrespective of the complexity of the application.
2. Component : It is the unit which provides the business logic for the application. A composite contains multiple such components.
3. Services : Act as entrypoint to each of these components. Not all services can be accessed directly from outside the composite. Only those exposed to outside world specifically can be accessed directly. Those that can be accessed by outside world are called Promoted Services / Exposed Services
4. Reference : As the name suggests, is a reference to some implementation, either external to the composite or within it.
5. Wires : It is with wires that the components or services are bound/connect to each other
6. Properties : SCA leverages its implementation to provide customizations to the components through properties, which actually extend the standard functionality.

Apart from these, SCA also defines the non-functional requirements such as policy enforcement, QOS, etc.

Hope this post gave you a clear understanding of SCA.
In my next post, I'll go explain how Oracle has leveraged these concepts, on its implementation of SCA, the Oracle SOA Suite 11g.


Thanks for going through my post, feel free to provide a feedback!

Mediator in Oracle SOA Suite 11g

Mediator, as the name implies, mediates the message flow.

SOA is all about message flows between disparate systems, and mediators play an important role in this.

It forms the communication layer between the services, thus providing a kind of service virtualization and decoupling between the interacting services.

It basically intercepts the message flow between the services and offer various capabilities as listed below

1. Message Routing : This is the ability to channel a request to a particular service provider based on the message. You may define rules to select the target service among the available services based on the content in the message(static routing) or based on an external rules engine(dynamic routing)

2. Message Validation: Messages can be checked against a schematron file to check its validity. This helps in invoking the target services only with the right message(as each and every invocation in an enterprise is costly)

3. Message Filtering : You may filter the messages based on its content

4. Message Transformation : This is the ability to convert the structure and format of the incoming service request to the structure and format expected by the service provider.

Transformation is one of the key capabilities of the Mediators.

Mediators are also a way to change the interaction patterns, i.e. you can convert a message call from sync to async, a 2-way to a one-way, etc.

Mediators are a way to enable Event Delivery Architecture in your composite. They have the capability to publish an event as well as subscribe for an event.

However, mediators form the communication layer only within a composite. If the interactions go across composites, Enterprise Service Bus comes to the rescue. We'll discuss about ESB later.

Logical Grouping - Partitions in SOA Suite 11g

In order to logically group your composite application deployments, SOA Suite provides a feature called partitions.

This way, it will be a lot easier to manage deployments, grouping them based on certain logical criteria.

You can perform bulk life cycle management tasks at a single go. Ex, start/stopAll, undeployAll, etc.

You always deploy a composite to a partition. SOA Suite provides a default partition named default.

Note
There won't be any warning if you are trying to deploy the same composite in more than one partition using JDev. However, you will have a warning when done using EM.

Having the same composite in more than one partition may sometimes cause unexpected results.For example, say you have an inbound fileAdapter that checks for any new records on a file. On new record arrival, you never know which instance of the composite(either from first or second partition) is actually started

Creating a Partition

Rt click on soa-infra --> Manage Partitions

 

Create a new Partition in the next screen

Selecting a particular partition for your composite is done during deployment.

There are 3 ways of selecting the partition(which are a part of deployment)

• Using EM
• Using Jdev
• Using Scripts

Using EM

Click on soa-infra, then click on the SOA Infrastructure dropdown to go into deployments

 

Using Jdev

In Jdev deploy wizard, you have the option to select the partition to which you want to deploy the composite

- Ravi Kiran