Case Study: TraxStar Technologies

For TraxStar, its ability to quickly develop enterprise-class vertical solutions is what keeps the company ahead of the competition. By using the RemObjects SDK, TraxStar successfully transformed their underlying n-tier framework from one that was stateful and poorly equipped for handling a large number of concurrent users to one that is fully stateless and highly scalable.

I have to admit it. I absolutely love the RemObjects (RO) SDK. I've been a die-hard Delphi developer since version 1 and I can honestly say that very few software products and companies have been as nice to work with as RemObjects and the RemObjects team.

Challenge

Early in 2003 I was faced with having to make some tough decisions regarding the evolution of an already mature and advanced n-tier application framework. This framework is the basis for TraxStar's two vertical market solutions: StaffTrax and QATrax. Originally based on DCOM and MIDAS, our customers were, for the most part, satisfied with the performance of these applications. Installation, deployment, and security, while not overly difficult were frustrating at times (using DCOM over HTTP).

Years had passed, the internet had evolved, TCP and HTTP became widely adopted, and more importantly, best practices for n-tier application development had also evolved. TraxStar faced the challenge of having to re-architect its technology in order to support larger groups of users over more varied network configurations. Our solutions simply didn't scale that well, and provided less than optimal performance in lower bandwidth situations. This was primarily due to the fact that we did not originally design a stateless middle-tier and at the time the notion and application of using pools of objects was still relatively immature.

Selection

While evaluating the alternative third-party remoting solutions on the market (Asta, kbmMW), I found myself coming back to the RemObjects web site and newsgroups time and time again. I found RemObjects' promise of providing an open and flexible remoting architecture to be very compelling. This was the product that looked like it would let me do things my way, without a lot of fuss. Additionally, as we knew that .NET was in our future, RemObjects early stated commitment to .NET, made the choice that much easier.

Of particular importance to this project was RemObjects' rich support for object pooling, multiple channels, and variants. These were the key features that helped us to quickly move from a stateful to stateless architecture and that would allow us to scale up as needed. We have plans to support clusters of servers in the future and we should not have to change a thing to deploy multiple application servers in a clustered server configuration.

As an added bonus I liked the fact that RemObjects makes it trivial to add compression and encryption to the remoting layer to any application.

Development Experience

Even though my first experiences with RemObjects was as a beta-tester, these early sessions proved to be extremely fruitful and productive. I was very impressed with the lighting-fast and thorough responses to each and every design or implementation issue we raised throughout the beta period. I'm not exaggerating when I say that the company is totally committed to product excellence and keeping their customers happy.

Re-implementing the application servers' API couldn't have gone smother. RemObjects provides all the data types you need, and comes with an excellent RAD "Service Builder" tool that makes API implementation a snap. Adding object pooling to our application server was quote straightforward and I believe RemObjects is the only remoting library that provides several pooling options right out of the box.

As we had done some "interesting" things with variants, the RemObjects folks were kind enough provide a very comprehensive set of variant: binary conversion helper routines. These routines can solve a lot of problems when converting from MIDAS. In hindsight, adopting RemObjects was the easy part of our conversion process, taking a stateful application server and making it stateless was much harder.

Based on the ease of creating RemObject-based servers, we decided that this was a good time to break out some of the original application servers functionality into a separate global singleton server. This behind-the-scenes application server runs on the same machine as the database server, and has allowed us to deploy our new 100%-stateless application server on multiple servers, in a clustered configuration. In addition, both of our application servers are deployed as Windows Services. All this, combined with RemObjects' excellent object-pooling support, gave us the ability to scale that we needed.

Conclusion

After almost one year, I still find myself impressed with RemObjects and the significant improvements that it's made to TraxStars products and development process.

Our flagship product, QATrax is currently in use by Hewlett Packard, Nokia, and General Dynamics. We have several months under our belt using RemObjects in some very demanding production environments and I am happy to report that it works perfectly day in and day out.

I'm very excited about all the wonderful new products and capabilities outlined in the RemObjects ROadmap. I like the fact that product is constantly evolving and continues to offer developers new and novels ways to tackle any remoting challenge while never sacrificing quality or completeness.

RemObjects is a very elegant, flexible, and easy to use framework capable of meeting any remoting challenge. It has proved itself time and time again and has provided an exceptional ROI to TraxStar.

For further information: www.traxstar.com

Technical Environment

• Database Server - Borland Interbase 7.0 and 7.1
• Operating Systems - Microsoft Windows 98, 2000, 2003, and XP
• Hardware Platform - Intel Pentium and XEON both single and multi-processor
• Number of concurrent users - 10 to 100+

© TraxStar Technologies — reprinted with kind permission.