How to become a B2B hero

Here's your blueprint for designing and building winning business-to-business extranets.

By Barry Nance, Network World Global Test Alliance
Network World, 02/26/01

Your boss just told you that you will be representing your department in the company's new supply-chain e-commerce extranet. You're initially delighted. The project will be interesting, highly visible and great on your resume.

Then, after a moment's reflection, you're less sure. The existing network must remain unaffected. It'll be your job to ensure other development staff don't choose technologies that make this extra-net unreliable, slow or expensive.

How we did it Using Visual Basic and Oracle Version 8i relational database, and a combination of Active Server Pages, BEA Systems' WebLogic 5.0 application server and Java 1.1.7B code, we developed the client and server sides of two business-to-business order-fulfillment environments. As the need arose, we used additional development tools, such as Visual C++. Click here for more...

Oh, and one other thing: You're to tell your boss what kind of pipes you select, their sizes, any hardware you'll need and how that hardware should be configured.

Whew! At the end of this project, you'll either be a hero or a hobo. Because hobos aren't a large segment of Network World readers, we came up with ways to conquer the challenges of building a supply-chain network.

We created a mock automotive manufacturer and then simulated two common extranet scenarios for it: a link to a mission-critical vendor, an auto parts supplier; and a link to a less-critical one, an office-supply vendor. We had three goals: create a reliable network link, both hardware and software; ensure appropriate security; and ensure data integrity.

Is a leased line (T-1 or other data rate), frame relay or Internet-based VPN the best way to conduct transaction-based communications with another company? That depends on how important the link is to your business. Our simulated auto manufacturing facility would lose money by the minute if it couldn't procure its auto parts. Not so for replenishing office supplies.

For the critical link, a pair of leased T-1 lines offered maximum availability. We tried two load-balancing tools, Microsoft's Windows Load Balancing Service and Lightspeed Systems' Total Control for E-commerce IPMagic, to switch instantly to the second leased line when the first failed. Both performed well.

Using leased lines from two telephone companies let us guarantee 99.9% uptime. At about $1,800 per month for each leased line, plus $18,500 in set-up costs, this approach is expensive, but it'll give you the assurance that your supply lines stay open.

We found an equally effective and less-expensive solution in using a pair of frame relay links provisioned by different telephone companies. Costs ran $24,500 for set-up and $850 per month thereafter. However, we preferred leased lines because it used simpler hardware and allowed us and our business partner to buy DSU/CSUs from different vendors (see Figure 1). Despite the obvious cost savings, we eschewed an Internet-based VPN because it adds administrative complexity, unreliable performance and slightly higher security risks.

Figure 1: Click for larger image ( 48kGIF)

Ordering office supplies was a different story. We created a low-bandwidth VPN between our business and the simulated office supply companies. For paper clips, we could weather Internet traffic jams.

Agreeing on acceptable service levels and deciding who would be responsible for monitoring the link with the auto parts vendor were important steps in our project. To maintain 99.9% reliability, we devoted each T-1 link (1.544M bit/sec) to auto parts requisition transactions, with no e-mail or voice over IP on the wire. Because it's reliable and easy to configure, we chose Lucent's VitalSuite to monitor the WAN.

Negotiating with a business partner to use TCP/IP should be easy. It's pervasively popular and eminently routable. Nonetheless, we didn't want our lab experience to be too smooth. We stipulated that our auto parts vendor used an AS/400 and IBM's SNA.

For our initial approach, we concluded the best solution to the disparate transport layer problem was to design our application with IBM's Advanced Program-to-Program Communications (APPC, also known as LU 6.2) to send and receive transactions. Despite our best efforts to complicate matters, the design and administration of the APPC link turned out to be child's play.

The only real difficulty was designing the automated dialog to be fault-tolerant of sudden connection outages, so we could guarantee each order would arrive at its destination. Our solution was to consider each transactional group of messages as an atom, meaning the application processed only complete transactions. Configuring a pair of Cisco 4700 routers, one at our auto assembly plant and another at the auto parts vendor's site, to convey the SNA packets across the WAN link, was also painless.

We rejected the idea of using a relational database as an interface between the auto manufacturing plant and the parts vendor. Although inserting orders and confirmations in a database shared between business partners would be easy, each partner would need to send a trigger over the WAN to alert the other of a newly inserted order or confirmation. Why not send the entire transaction instead of just the trigger?

In another database-oriented approach, partners would poll the database periodically for new, unprocessed activity. But polling wastes a lot of bandwidth. We also rejected the idea of database replication because both business partners needed updated data and we couldn't designate a single database owner as responsible for this.

The homegrown SNA link to the AS/400 worked well, but we wanted to investigate a method that would limit our application programmers' involvement in making network connections. After all, they're not network experts. We chose to contrast our homegrown SNA solution with Microsoft's and IBM's messaging middleware tools, and we discovered the messaging tools proved to be a better approach. The middleware assumed most of the network delivery work and required less programming labor.

In separate tests, we replaced our homegrown SNA link with Microsoft's Message Queue Server (MSMQ) and IBM's MQSeries (see Figure 2). These tools guarantee message delivery, which make them appropriate for transaction-based automated dialogs, and they convert between data formats as necessary. Although both performed well and were reliable in the lab, we found IBM's MQSeries gave us the best overall network link between our Windows NT servers and the business partner's AS/400.

MQSeries was simpler to set up than MSMQ and required virtually no ongoing administration. With a version that runs on nearly every operating system, it was also more platform-neutral than the NT-specific MSMQ.

B2B checklist Answer our list of questions to find out how to position your extranet. Click here for more...

Conversely, using MSMQ, which Microsoft bundles with Windows NT Server 4.0 Enterprise Edition and Windows 2000 Server at no extra charge, was complicated by the need to install and configure three other components - Microsoft Transaction Server, SNA Server and SQL Server. MSMQ stores queue information (but not the messages themselves, which reside in memory-mapped files) in SQL Server. We chose to use another optional component, Microsoft's COM Transaction Integrator (COMTI) for CICS, to provide transactional access to the auto parts vendor's AS/400 computer. COMTI consists of a set of development tools and run-time services that treat SNA transaction and business logic as COM components that run in a Windows DNA environment.

We used Transaction Server to ensure transactional integrity and manage a pool of database connections. SNA Server established and maintained the link to the AS/400 computer. The result required a considerable programming effort. More importantly, from a networking perspective, we found that MSMQ, Transaction Server, SNA Server and SQL Server burdened us with additional administrative chores necessary for maintaining three applications. However, they performed quickly, and were robust and reliable in the configuration we created.

Lack of security was IBM's MQSeries' major disadvantage. We needed to ensure that data flowing through the link was encrypted, the transactions were authenticated as originating from approved sources and data integrity was verified. A third-party product, Candle's MQSecure, gave us these attributes for MQSeries, whereas we relied on built-in security features and NT's access control lists (ACL) for MSMQ.

Messaging middleware security Candle MQSecure's and Microsoft Message Queue Server's approaches to security are quite different. To hide message contents and preserve message authenticity, MQSecure uses RSA's RC2 technology, while MSMQ uses Microsoft's own Crypto API. Neither offered the aged, moldy Data Encryption Standard (DES) or its more recent incarnation, Triple-DES. Click here for more...

Using RSA's RC2 technology to encrypt our messages, MQSecure-protected MQSeries messages were encrypted from the sending application to the target application. Messages were completely unintelligible with Sniffer and, because MQSecure encrypts the user ID portion of each message, spoofing a bogus message (inserting a fake message onto the wire) appeared impossible. MQSecure's authentication of the message's source also ensured nonrepudiation. Validation of the received message ensured it was unaltered.

MQSecure offers two levels of security, "channel" and "application." Channel security protected data only during its travels across the network. Application security additionally protected the data while it resided in the MQSeries message queues. We used both levels in the lab, which gave us end-to-end security for our transactions.

For Microsoft's MSMQ, we relied on the product's built-in security features and NT ACLs. The product gave us good security, producing over-the-wire messages that were unreadable on Sniffer's display and message queues that were inaccessible until we entered an authorized NT Server logon ID and password.

On an NT Server machine, we used Windows Explorer to set up ACLs for our message queues. For files and directories, MSMQ created at installation time, these permission keys kept unknown users from reading or sending messages to a queue, and they additionally kept unprivileged users from sending messages to a queue. Anyone authorized to administer rights and permissions on NT Server can administer MSMQ. We used MSMQ's Explorer interface to create message queues, assign priorities and monitor the delivery of messages. We also configured MSMQ to log events, such as rejecting a password or opening a queue, in the NT Server Security Log.

MSMQ used the Microsoft Crypto API to encrypt and digitally sign the messages in the queues. Like MQSecure's RSA-based encryption, the Crypto API preserved the confidentiality of message queue entries, while the digital signatures prevented the spoofing of counterfeit messages. Selecting encryption and digital signing features was a matter of clicking checkboxes on property sheets displayed by the MSMQ Explorer.

MSMQ also offers what Microsoft calls Independent Clients - a separate, unencrypted messaging facility that relies on local queues instead of network communication. Avoid this feature if security is a consideration.

Before we began encrypting our business-to-business network link with MSMQ or MQSecure, we discovered via the Sniffer that the format of the network messages could make understanding their contents slightly more difficult. The binary, proprietary transaction dialogs we designed had the side benefit of being somewhat more secure than our XML-based automated conversations. To decode a binary message, a hacker would have to analyze carefully which bytes of a network message belonged to which data fields. In contrast, our XML-based dialogues looked like plain English in the Sniffer displays. Thank goodness for middleware security.

As for the office supply extranet, we decided it didn't need any additional security beyond that inherent in each VPN. We used Cisco Secure PIX 506 Firewall devices to create VPN links to our simulated office supply vendors. The Cisco units' HMAC SHA1 algorithms provided more than adequate authentication and encryption services for the network tunnels through which we requisitioned our paper clips. The units also acted as firewalls between us and the Internet.

During network design of our auto supply link, we attempted to identify all points where the network could fail and then planned redundancy. With a total of eight routers and DSU/CSUs, four at each site, we built redundant network data paths. We used a standby pair of routers and DSU/CSUs for each of the two parallel T-1 WAN links to our auto parts vendor. The fallback mechanism for the interfaces to the office supply vendor consisted of having VitalSuite monitor VPN and T-1 links and page us when a link failed.

As we created and tested our extranet links, we also put VitalSuite to work looking for application performance problems and providing utilization data for capacity planning purposes. VitalSuite's reports and graphs let us keep a vigilant eye on critical factors such as bandwidth usage and server CPU utilization. It worked equally well in this capacity for the auto supplier links and the office supply VPN.

When the links we've described here go into production, we're confident our bosses will declare our entire team to be heroes. Eating beans by the railroad tracks won't be in our future.

Nance is the author of "Introduction to Networking," 4th Edition and "Client/Server LAN Programming." Nance is also a member of the Network World Global Test Alliance member. He can be contacted at barryn@erols.com.

For more Test Alliance information, including what it takes to become a member, go to www.nwfusion.com/alliance/.