If you haven’t implemented Internet applications yet, you may find yourself doing so soon. They’re everywhere, and with the strategic importance of B2B and the growing power of Web Services Definition Language (WSDL), you’d better be ready when they land on your doorstep. Here’s a guide to ramping up with the technology and tools, along with training suggestions for your staff.

The challenge
Chances are you’ve been hearing plenty about Web services and Internet applications. Aside from the usual alphabet soup, vendors have been promising the holy grail of seamless business application integration since before the term “dot Net” ever left the Redmond campus. Well, as usual, the bad news is that Web services don’t yet provide anything that’s truly seamless, universal, or plug and play. But the good news is that an Internet application can help to automate and integrate your B2B systems, and it might be easier than you think.

There are a couple of environments in which Web applications really shine. To begin with, the term itself is nearly synonymous with automation. If you’re looking to improve productivity by automating processes such as inventory control or purchasing, an Internet application is probably in your future. Likewise, if you’ve been tasked with integrating two (or more) disparate systems, such as EDI and an XML-based supply chain system, you should be looking to Web services to accomplish your goal.

The reason why Internet applications are so successful in these specific arenas is that the technology has accomplished the core of its original goal, which was to provide a platform- and protocol-independent means for a large number of systems to communicate quickly and accurately. With that said, if you think rolling out an Internet application might be in your future, there are a couple of questions you’ll want to ask to be sure:

  • Will the application need to be flexible/customizable in the future?
  • Do you anticipate additional situations in which you’ll need a similar Web application?

The answers to these and related questions should get you pointed in the direction of either a third-party application or a custom Web application to meet your needs. Generally, if you have a strict set of circumstances in which you will be rolling out the application and you don’t expect them to change, you might look into a third-party app. For example, if your company, which runs MAS-90, has recently acquired a company that runs Great Plains, and your challenge is to allow order entry from the MAS-90 system to update inventory in the Great Plains system, a third-party app will probably fit the bill.

However, take the example of a client who recently decided to purchase a new accounting system and now needs to tie inventory control and order processing to a major retailer’s legacy EDI system. In this case, the amount of customization needed will be significant, and it’s likely that a wide range of other systems will also be connected to the new accounting package in the future. In this case, a custom Web application is probably the best solution. Either way, you should take some time to get familiar with the tools you’ll be rolling out.

The technology
The alphabet soup of Web services has been covered pretty extensively around the Web, so there’s no need to go into an in-depth examination of XML or SOAP here, but you can read up on them at many of the locations listed in the Resources section at the end of this article. One term that may need some further explanation is WSDL, but, before getting to that, I’ll need to take a closer look at the application framework of a Web service. Generally speaking, the application framework provides the development tools you will use to create and implement your Web application. The application framework may or may not be platform independent and it may be as complex as .NET or Java or as simple as PHP.

Chances are, the best framework for the task at hand is going to depend largely on what tools you already have available. One of the great benefits of Web apps is that they are platform independent, so you can use what’s easiest. If you look around the server room and see dozens of machines running various flavors of Windows 2000, and your development team is itching for an excuse to use .NET, your path is clear. Likewise, if your IT department is staffed with die-hard UNIX/Linux users who would never even consider .NET, you might want to look at using Java, C++, or Python as alternatives. As mentioned earlier, it’s even possible to create an application framework in a scripting language such as PHP, something I’ve recently done for a client who will be rolling out its Web application to Fortune 500 customers in coming months.

Once you’ve looked around at the options and determined the application framework you’ll use, it’s time to define the service you will provide. This is where WSDL comes in. Without going into too much detail, XML is used for data handling, SOAP binds the XML data to whatever protocol you choose, and WSDL interacts with the applications on either end of the transaction to correctly deliver data to the application in a way that the application can understand. In a nutshell, that’s what you’ll be implementing when the time comes to roll out your Web app. So what do you need to do to get ready?

Rollout
Actually, the first two steps of the process are what I’ve already covered: define the need and focus for the Web app to determine the application framework you’ll use for implementation. Once that’s done, you’re already well on your way. All that is left is the nuts and bolts. First, you’ll need to work through whatever data mapping will be necessary to get your application up and running. This could be fairly simple (for example, connecting two data stores containing similar types of information) or very complex (such as integrating and automating an entire supply chain management system based on a combination of existing legacy applications).

When your data and XML experts have the data-mapping step in hand, you’ll need to determine the transport protocol you will use for information exchange. This will most likely be HTTP or HTTPS but could also be SMTP or something else entirely. You’re protocol independent as a result of SOAP, so use the right tool for the job at hand. Finally, be prepared to spend some time interpreting the XML data for each application in your transaction. WSDL provides an XML-based framework for this, which should result in a fairly comfortable development environment.

The last but arguably most important step in rolling out your new Web app is training. Presumably, one of the main reasons to use an Internet application is to significantly change the day-to-day operations of one or more of your core systems, either through automation or integration. If that’s the case, the best way to see the ROI you were looking for in the first place is to make sure that the staff using the new system understands both why the changes were made and how to make the most of them.

Resources
And speaking of training, here’s some further reading to get you and your staff ready to implement your new Web application: