Web Services exposed!

For a long time, there's been a lot of noise about web services and service oriented architecture. These have been two buzzwords that just about every large software vendor is talking about and promoting. Unfortunately, the number of successful deployments of either of these is fairly limited in the country. This is possibly because most people are still not very clear about the concepts behind web services and service oriented architecture. Even if they understand the technology, they face a roadblock on implementing it. That's why, this time, we decided to let you experience the best of both worlds. We've broken this story into two parts. The first part explains what web services and service oriented architecture are all about, in simple terms, and with examples. The second part takes you through the actual steps to follow for publishing a web service using a variety of tools. This is also more in tune with the spirit of web services. They're supposed to help an organization combine the business logic with technology to truly leverage IT for better business. We'll also give you both business and technology perspectives to web services, so that you can leverage them better.

Having said that, let's now try to understand what web services are really all about. For this, it's important to understand how the IT setups have evolved in every organization. The IT setup in an organization isn't built over night. It takes many years of hard work. Unfortunately, as it's come up over many years, it has many heterogeneous systems and applications. As long as these systems and applications work independently, they're fine, but the world is not so simple. There are many times when it's critical that different systems talk to each other. To take an example, a bank has many different applications for its various functions, like loans, deposits, credit cards, ATM, etc. Now suppose that the bank needed to find out the credit rating of a customer before offering him/her a loan. The bank would obviously avoid giving a loan to a customer with poor credit rating. In this case, the loan application needs to pull out credit rating data from the credit card application. As both applications support their own proprietary methods of handling data, getting them to talk to each other becomes a very difficult task. The field of Enterprise Application Integration, or EAI deals with such challenges. It allows different applications built on completely different applications to talk to each other. For a long time, this job was done by technologies like CORBA, DCOM, etc. Anybody who's worked with these technologies will tell you how difficult it is to use them. That's where web services come into the picture.

Understanding web services

A web service would allow both the loan and credit card application to talk to each other, irrespective of which platform they're running on. It would do it using a set of open standards. Today, the most widely accepted web services standards are from W3C. So basically, what happens is that the credit card application exposes its customer credit rating data as a web service. As this is based on open standards, anybody a developer can use it to integrate it with the loan application. Not only that, but other applications can also use this web service. So essentially, the organization has just developed reusable code. This saves a lot time, money, and effort.

Let's take another example. Suppose there's a manufacturing firm that's running an ERP package. This ERP package maintains the inventory levels of the organization, among other things. What if the organization wanted a way to inform its suppliers about shortage of raw materials the moment it happens? One way would be to allow the suppliers to access the ERP system directly to pull out this information. This however, would be a major security risk as you would also be exposing company confidential information to them. The other is to figure out which supply chain management package is each supplier running and then try to integrate them with your ERP. This would prove to be a mammoth task, especially if different suppliers are running different SCM software. The best way out is to expose your inventory level data as a web service. This standard information can then be -picked up by all your suppliers and integrated with their SCM applications. This example can be taken in another way. Suppose that your organization's top management wanted to find out critical information from the ERP system no matter where they are.

The biggest benefit of doing this is that you've just saved yourself the cost of recreating software every time you need to do application integration. For organizations who are already overwhelmed with hundreds of applications, this can be a real life saver. Once a web service has been created, it can be used by any other application.

Understanding SOA

A services oriented architecture is an application that's been built by taking data from multiple web services. It's a complete shift from the traditional way of developing applications and therefore requires a different level of thinking. In fact, if you look around, you'll find examples of SOA all around you. If you have a DVD player, then it will accept any DVD movie you want to watch. That's because the formats and standards for both the DVD and player have been defined. It's not as if you need a different player for every DVD you buy. Unfortunately, in the traditional software applications, tight binding takes place making them inflexible. In the SOA world however, there's loose coupling between different applications. It doesn't matter which platform, software or hardware is the application running on. As long as it's able to expose a web service, it can be integrated with other applications.

The challenge now is to find out what kind of web services do you really need to expose? Let's go back to our ERP example. Suppose you wanted your management to know about significant variations in any of the data provided by the ERP system. For instance, the moment there's a drop in production, you want your production floor manager to know. The moment there's a huge drop in sales target achievement, your sales director needs to know. The moment there's a major shortfall in collections, you'd like your commercial director to know. Further still, you want them to find out about this no matter where they are and on the device they're using. If it's a cellphone, then they should know via SMS. If they're using a smartphone or PDA, then they should be informed by email. If the managers receive this kind of critical data on time, then it can really prove to be beneficial for the business. All this can happen if the ERP system can expose this data as standard web services. This data can then be fed to a unified communications platform to deliver the right information to the right person at the right time. Such kinds of solutions have started emerging. Avaya for instance, has tied up with SAP to offer this kind of functionality. Similarly, there are many other successful examples that are available online of SOA and web services. An airline exposing its reservation system as web services for travel agents for instance. Likewise, a bank exposing its key customer names and telephone numbers to a call center, whom its outsourced some work to. The call center can then integrate this web service with its own CRM application easily. Likewise, there can be hundreds of examples where SOA can prove beneficial. It ends where your imagination does.

The critical requirement for SOA and web services to be successful is that organizations must be in a position to expose certain parts of their applications as web services for others to use. For that, they must invest in certain technologies. Unless this investment shows concrete returns, it will not happen. In the pages to follow, we've given some examples of how to publish web services on various platforms, which include WebSphere, ASP.Net, and Java.