We live in a service-based culture where it's second nature to pick up the phone and order a pizza for delivery in 30 minutes, or to send a bunch of flowers anywhere in the world. There's an appetite for a similar approach in IT, with systems being able to call on the services of other systems. To work in the most effective ways, these systems need to be as loosely coupled to one another as a customer is to the pizza company. All you should need to know is: how to make the call (dialling the number); how to find the service you want (using the Yellow Pages) and which parameters to pass on (size of pizza, toppings, delivery address, etc.).

In the SAS world, this approach translates into web services that are based on a SAS® Stored Process: code that sits on a server, is registered in metadata, and returns results in the right format to whatever client you want.

Web enabled
A web service is simply a routine that calls other routines using Internet protocols. Of course, one system calling another isn't new: consider that client/server and distributed systems have been around for some time. But making the call through internet protocols is new, and it's the use of these standard and well-accepted protocols that makes the difference.

Here are two examples of how it can work. Supplier A provides materials to Manufacturer B, which uses SAS to forecast its demand for raw materials. By exposing this forecast as a web service, Supplier A can have its systems automatically call the service to see the materials that will be required to meet its service level agreements. Note the lack of human interaction. Meanwhile, Bank C uses SAS for credit scoring customers. The scoring process is implemented as a web service so any application in the bank can check a customer's credit score whatever platform it runs on and wherever it's located.

The services model
A typical web services environment has three main roles:

• Service Consumer - this is the calling system, the part of the architecture that expects results to be returned to it (this is the hungry customer wanting a pizza)
• Service Registry - service providers list what they offer, and service consumers search the registry for available services; more importantly the registry tells the consumer how to bind or use the service (this is similar in concept to the Yellow Pages you might use to find the pizza firm)
• Service Provider - this component actually creates the web service; typically the service provider exposes certain business functionality in their organisation as a web service for other organisations to invoke (this is the pizza delivery company)

Where web services are really coming into their own is within intranets and extranets, where security and control can be tightly maintained. There are other benefits, too. Web services provide an easy way to expose complex processes and functions to distributed systems, while they can extend the lifespan of legacy systems and enable you to gain more value from your niche systems.

So, with a SAS Stored Process driving highly efficient and flexible web services, SAS is once again giving people the power to make better and more informed decisions, and make them faster.

For further information, please visit: http://support.sas.com/rnd/itech/doc9/dev_guide/websrvcs/index.html