When one of the top global banks was looking to aggregate foreign-exchange orders and pricing for trade, it ran into troubled waters.

It identified two key problem areas. First, the internal-pricing application and the external trading processes that it was looking to integrate were based on different platforms and technologies. How would the two systems talk to each other?

Second, the bank’s employees who had to use the new trading solution were spread over several countries and used many different combinations of hardware and software. How would the employees’ systems recognize the information processed by the new application?

The bank was not prepared to throw out its legacy systems and invest in new ones to meet its business objectives. Nor could it get its thousands of employees to use the same configuration of computing systems.

Instead, it partnered with HCL, an IT provider with a global delivery presence, to draw up a Service Oriented Architecture (SOA) based on Web services. Web services allowed the bank’s legacy internal processes to talk to the external processes without having to re-write its legacy application. By exposing the trading process as a Web service, it also enabled its employees to access all data that the new application processed. Thus, it derived the benefits of integration and interoperability.

What’s Web Services?

As companies grow, they acquire more and more pieces of software (operating system, enterprise applications, desktop applications, Web-based applications) and hardware (servers, desktops), and deploy them across multiple geographic locations. The chances are minimal that the configurations of these systems will match perfectly. Companies also have a need for their internal systems to talk to the external systems of their customers, partners and suppliers.

Any next-door geek will tell you that getting these disparate systems to talk is complicated since different application solutions are based on different development technologies (.NET, Java), programming languages (Visual Basic, C/C++) and operating systems (Unix, Linux, Windows, Mac). They may use various communication protocols such as HTTP, SMTP, RPC and RMI Remoting.

Companies usually resort to Web services for such integration and interoperability. Web services is a standard that describes how applications can communicate with each other, regardless of the technology they use, the devices they are deployed on and the location of those devices.

If an application is Web services enabled from day one, it is ready to communicate with disparate applications (legacy or future). These disparate applications can re-use the business processes, inject input and extract output from the Web services-enabled application. All this happens without the former applications knowing anything about the platform, technology and language used by the Web services-enabled application.

For example, if a company develops a Web services-based CRM application, other processes of that company’s business — accounting, sales, marketing — can also use the information generated by the CRM service without having to re-write any of the code for their purpose.

Breaking out of the in-house scenario, Web services plays well on the Internet too. A classic example is that of Amazon.com, whose shopping cart process is Web services enabled. Website portals wanting to offer one-stop shopping at Amazon.com from their site, can use this Web service without writing a single line of code for a shopping cart. It doesn’t matter whether the website is written in ASP, Java or PHP or is running on Windows or Unix.

Rarely would companies have the capability to implement a Web services-based solution by its in-house team. After all, that may not be the company’s core competence. Service providers, on the other hand, are setting up centers of excellence that offer consulting and solutions around Web services.

What should customers know about Web services?

What should they ask their service provider about implementing a Web services-based solution?