Now that we are well past the hype of Web Services, what can they do for your company? Before we answer this question, let’s clarify what Web Services really are.
One traditional definition states that they are any service available over the Internet using a standardized XML messaging system and not tied to any operating system or programming language. In the early days this was true, but the definition has evolved over the past decade. The World Wide Web Consortium (W3C) defines Web Services as a software system designed to support interoperable machine-to-machine interaction over a network. Gartner defines them as “a software component that can be accessed by another application (client, server, another Web service) through the use of generally available, ubiquitous protocols and transports (HTTP).”
The important concept is what’s not included in these definitions, terms like “Internet” or “Web.” Instead, they focus on words like “software”, “protocols”, and “network”. What this means is that you don’t necessarily need the Internet or the Web to use Web Services. You can use Web Services as a tool to non-intrusively connect applications within your own network and to allow your applications developed over the years by different developers and in different languages to communicate without intimate knowledge of each other’s programming environment. The interactions are machine-to-machine and based on business logic, data, and processes. This is what they can do for your company, and for many companies, using “web services” internally may be an area of big payback.
So, exactly how can an internal Web Services implementation be accomplished? Many have asked, and have been confused by a bewildering assortment of answers. There are many ways to implement Web Services and the level of difficulty depends on your company’s individual needs, so you have flexibility.
The architecture (SOAP or REST), number of Web Services, and security requirements of the applications could influence your solution choices. Many commercial applications provide some tools to assist with building, deploying and/or accessing other Web Services. They also provide built-in Web Services to make it easier to access and/or update the data and associated statuses.
Let’s look at two application-to-application (A2A) scenarios to help gauge where your company stands. One scenario is a legacy Order Management System (OMS) that needs to transfer some invoicing data to a commercial accounting application. In this case, there won’t be any Web Services provided by the legacy OMS, they will have to be built. There also may not be any Web Service tools provided by the accounting application, so again they will have to be built. The solution could involve running an internal web server on the network and developing small web applications that can perform the required task of transferring and transforming the invoice data from the legacy OMS to the accounting application.
Another scenario is a commercial enterprise resource planning system (ERP) that needs to communicate some order pick and pack information to a commercial warehouse management system (WMS). In this case, there may be Web Services provided by both the ERP and the WMS to accommodate this process. Both may also have the tools available to not only provide the Web Services, but also to consume them. Most of the time, if the commercial products offer Web Services tools; they host or provide the Web Service, but don’t provide tools to consume other Web Services. This part of the solution is commonly addressed by coding.
One solution that can address both scenarios is to implement a non-intrusive integration middleware software package offering provider and consumer Web Services capabilities. Most integration middleware software packages support Web Services, but there are important differences between them ranging from ease- of- use to costs to consider.
An ideal middleware solution would enable communication between all of your applications by way of non-intrusive simple software configurations and the creation of business processes to perform the Web Services tasks which would completely replace coding a solution. The integration package may even offer adapters to some of these commercial applications which can help to speed the implementation process.
If you’re looking at Web Services and wondering what they’ll do for you, a good starting point is integrating your internal applications because you can get to Web Services without the Web.