Thinking big with Microsoft Message Queue, VPN and XML

By Roy Hoobler 01 Jul 2002 | SearchWebServices

Digg This!     StumbleUpon     Del.icio.us

Roy Hoobler has been involved with Internet programming from 1995 and developing Web businesses and "niche" market sites since 1996. In 1997, he completed his MCSD certification and worked for a large consulting firm primarily focusing on Intranet and Extranet applications for fortune 1000 companies. In early 1998, seeing the potential of how business would be conducted on the Internet, Roy joined Net@Work Inc. (www.netatwork.com) where he designs (and still codes) business and cutting-edge e-commerce applications using a wide range of technologies, including XML.

Roy Hoobler moderates our Enterprise Developer Forums -- Post your question for Roy.

E-commerce projects can be grouped into three types: Large projects with a lot of resources and developers, medium projects having limited resources and a couple of developers on the team and small projects usually strapped with bare-bones functionality. However, this need not be the case. Over the last year, a lot of thought has been given to getting more done with less time and money. For small and medium projects "thinking big" can actually save money and get the project completed faster.

Overview of the project
Earlier this year we had a project for a simple e-commerce Web site with two requirements that made it unique. Of course, XML helped us meet these requirements. For this project, customers could order from three separate stores on the same Web site (for delivery purposes). Once the order was placed, it needed to be forwarded to the correct physical store. The second requirement was that orders were to be forwarded from the Web site and automatically printed on a receipt printer inside the store.

This was not a very small project. I'd classify it as a medium project with a small budget. In the past, many small systems used email and plain text messages. This of course is very inexpensive but the least secure, reliable, or reusable method. Even for the smallest project, better alternatives exist.

For this project, building a small messaging system using XML was considered and approved. Building this type of application seemed impossible to do on a small budget but Microsoft Message Queuing solved the problem. The XML-formatted message (sales order) can be processed in a number of different ways so the client can build more components in the future. The client application could change or be replaced as the business grows but the Web server messaging component does not need to change at all. The server component could even be used with an enterprise level application, sending the message to a Biztalk server or other EAI software.

Underrated Microsoft components
MS Message Que and Remote Access software is built into the operating system of Windows 2000 Server. Message Que can work with Active Directory or on stand-alone machines. However, some functionality is limited when used as a stand-alone machine (the biggest drawback is a lack of auditing). For our application, Message Que was setup on the Web server and on a PC at each location -- without Active Directory support. When a customer places an order on the Web, an XML message is created and the server tries to send the order directly to the Que on a computer sitting in the correct physical store. If the store is offline, MS Message Que saves the order in an outgoing queue on the Web server. When the store comes online, it is delivered within five minutes. Using the "transactional" setting on the clients, delivery is guaranteed.

These messages need to be secure and security needs to be considered from the beginning. Again, building a custom security API, or purchasing a 3rd party vendor's product usually cannot fit into a small or medium budget. Using Remote Access (a VPN connection), the PC at each store is securely connected to the Web server. Windows 2000 Server has a connection wizard with several options to setup the connection. To set things up correctly, you may have to select "Allow Remote Access" in the Wizard (not "VPN" as one might think). Remote Access works very well, as stores connect online, they can also see each other in the Network Neighborhood. MS Message Que requires that the computers communicating be on the same network (or in the same Work group). In this situation, the XML order messages are being transferred as if everyone were on a local network, encrypted by the VPN.

Order processing in XML
An order is first placed in a local database on the Web server. Some customer information is placed in the database, but not the credit card information. The credit card information is only submitted by a secure 'Post' on the last page of the checkout. At the end of the checkout process, our COM component creates an XML document of the order from a few database queries and passes the document to the message queue that sends the order to the physical store.

As stated above, creating a sales order XML document from the order leaves the system very flexible. Customer receipt emails are currently generated from the XML using XSLT and a separate notification email (without customer information) is sent to the main office. Once the XML message is received in the queue at the store, it is saved as a file to a directory and a customer receipt is created via a XSLT transformation and printed. We didn't encrypt the XML files any further but secured the directory where they are stored as much as possible. The next two steps will be to import these orders (possibly in real time), into the store's Point of Sale system, or place the customer information into a small CRM application.

Message Que versus other middleware
Why not use Web services or other middleware? Using message queuing instead of Web services allows the stores to be offline. The Web server actually pushes orders to the clients and sometimes the clients will be offline. Web services, are mainly a 'pull' system, allowing clients to request information. Using another middleware package for a simple system such as this would again be out of scope since these are generally big applications that cost quite a bit of money. Building a small custom (and reusable) middleware component was definitely the right way to go in this situation.

Building small components that pass messages between themselves is a good technique that a lot of other systems are using. From this simple application, I can see the benefit of implementing components with messaging support because they can be used more independently. Overall, it took about three weeks to implement the Message Que and VPN. Using XML/Messaging will allow us to reuse these components on the next project, whether or not is a Web e-commerce application.

The next small or medium e-commerce project we do, we will keep in mind the Message Que application. If the project budget is rather small, maybe we will have a "think-big" session and see what other technologies can be used. Some other possibilities to use message queuing include sending orders to the payment processor, sending email, or possibly finalizing the order in the database. Once you understand how the technology works, it is not very complicated and gives the client the most for their money.

For More Information:

• Read Roy Hoobler's other articles and product reviews.
• For insightful opinion and commentary, read our Guest Commentary columns.
• Tired of technospeak? The Web Services Advisor column provides a clear understanding of Web services.
• Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
• Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
• Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
• Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary