This is the first article in a multi-part presentation of how users can take advantage of Dart’s architectural designs to create powerful solutions while limiting the amount of code that is needed. The first presentation will focus on Dart’s philosophy with respect to product development and an overview of how that philosophy has translated into a product line that we believe is second-to-none. The next article will be an introduction to Dart’s architectural approach and how our design decisions will help you build applications for today’s needs while preserving the flexibility to scale as your requirements change. This will segue into the final article discussing Dart’s helper objects and how they create flexibility and scalability for your applications. Following this series, Dart’s staff will continue publishing periodic white papers in response to customer requests and technical developments, especially as you transition to the .NET Framework.
The PowerTCP components have evolved over the past seven years based on four towering pillars: the Architecture, the Samples, the Documentation, and Customer Support. These pillars are held together by a philosophy based on the concept of “Solution.” The challenge of creating software development component “Solutions” is that no two people are ever designing the exact same application. While a component can be used to accomplish a specific task, this component is just part of a larger picture, and what the larger picture may be is an infinite possibility. The scope of this picture not only encompasses the actual application, but the development environment, the operating system, the software developers, the organization, the business problem, the organization’s customers, and the environment that dictates how the organization can operate. Thus, every variable must be accounted for with respect to architecture, samples, documentation, and support.
To create the “Solution” from the design perspective means not just exposing the functionality of a lower-level API through ActiveX, which is common with protocol components, but to approach a protocol from the perspective of how a component based upon that protocol will be used in a business solution. This approach requires visualizing how a component will be implemented in a small development house and a large multi-national enterprise. Within these organizations will be advanced software developers who could write their own ATL or .NET components and developers who just know rudimentary Visual Basic. The environments could be purely Microsoft-based or a mixed Microsoft-mainframe shop. The requirements could include responding to 16 million queries a day or a simple HTTP-based back-end to an application. An organization’s customers can demand round-trip SSL security or just a black box that works. All of these requirements must be accounted for in a product because every customer expects the solution to their problem. Such a “Solution” outlook places heavy emphasis on scalability, flexibility, optimization, and ease-of-use.
The architectural approach needed to provide this level of functionality was a pure object-oriented model that abstracted data and connectivity. We believe that the data traveling across a network is just as important as the connection. By just placing the focus on the protocol, we would be doing a disservice to software developers, as they would be forced to write code to manipulate, organize, and store the information. The solution was to create an abstraction based on data consisting of objects that describe information and collections for holding those objects. Along with those objects, we implemented real-time searching capability, allowing a developer to conduct a search on the data as it arrived.
So much of modern-day software development is about using complex data, and to provide the necessary solution required modern-day development architecture. Certainly, such an approach will have its critics. Some have argued that the object-oriented model creates unnecessary complexity, and the role of components is to relieve that burden. In fact, many network component companies prefer a flat model that is similar to a traditional Windows API, and provide that API functionality with properties, methods, and events. We felt that an object-oriented model could be created that would provide the needed flexibility at a small cost to ease-of-use, and when needed there was no reason we could not provide “shortcut” methods that would encompass a standard use-case scenario. The goal of a component is to reduce cost and provide functionality, and for a “Solution” based component, this means providing support for both connectivity and data. This decision proved to be one of the defining moments in Dart’s history as the PowerTCP architectural model has enabled organizations to create solutions that would otherwise not have been possible with a component or would have required substantially greater investments to complete. Developers are given the flexibility to take Dart’s powerful data/formatting objects and use them throughout their applications after a network transfer has occurred or use the data/formatting objects to build their complex structures before they are sent across a network. For example, the recursive Message object from the Mail Tool can be manipulated separately from the communication code and passed to the needed code when all the messages are ready. Likewise, PowerSNMP for ActiveX abstracts the actual SNMPMessage from the transfer code of the component, enabling a programmer to actually build an SNMP message and use it with a TCP client component to send the packet over TCP instead of UDP. This architecture has also enabled our own staff to enhance the product line by adding SOAP support to various objects. In fact, this model is so effective that Microsoft has based their .NET Framework on a similar object-oriented approach, including the connection-data abstraction.
In support of the architecture are the samples. There are two prevailing philosophies to sample design. The first is to provide simple samples in support of a product demonstrating how a specific function or property is used. The “Solution” approach requires a much more comprehensive and sophisticated process. While some software developers only require basic samples, protocol implementations are a magnitude greater in complexity for most developers as they are not accustomed to the subtleties and rules governing network communications. To provide the optimum support for all levels of developers Dart decided to leave the simple samples to the Help documentation and alternatively include complete applications as samples so that customers can build on top of the included applications for their solutions. Instead of finding several lines of code demonstrating how to send an email or process a MIB, Dart created full-blown applications such as a Bulk Mailer, an ASP Hotmail-like Web client, a variety of full-blown FTP clients, an SNMP Manager, a MIB Viewer, a complete Web Server, an FTP Server, an SMTP Server, an HTTP-based Auto Update utility, emulation-based screen scraper, and many more applications, while including simple samples in the documentation. These applications not only serve to demonstrate a variety of protocol-based solutions, but have proven to be a wonderful educational tool for all developers. Better yet, Dart will often create the same application for several different development environments so if a developer is interested in moving to C++ or Delphi they can study how a similar process works across development environments.
Documentation is often one of the most controversial elements of a software product, as there never seems to be enough information for the customers. To provide as much documentation support as possible for Dart’s customer-base, the “Solution” approach requires a two-tiered strategy. The first part of the strategy is to make the documentation a living, breathing document. What that means is that the documentation never becomes static, but instead a process is put in place to constantly provide clarification based on customer feedback. If users have a difficult time implementing a capability or complain that an explanation is confusing, the comments are directly provided to the staff responsible for maintaining the documentation and changes are immediately implemented. The second part consists of providing background primers in the documentation to educate developers about protocols without having them decipher cryptic RFC papers. While the PowerTCP components eliminate the need for RFC knowledge, more advanced applications require a deeper levels of understanding and our goal is to provide that understanding in the shortest possible time. Documentation is an ongoing process and Dart will continue to respond to our customer’s needs.
The final part of the “Solution” approach is customer support. As mentioned earlier, components can be used in an infinite number of ways and every software developer expects Dart Communications to have their solution in mind. This concept extends to support. A developer could have a simple usability question or a concern about a potential bug. The application could be for internal corporate use or a commercial product used by thousands of people. The internal application may have important needs, but not urgent, while a commercial application may require immediate turn-around for any potential problem. For all these different needs, Dart has customer support options. ISV support provides a guaranteed five-day turn-around for a reported problem. This means that we will elevate your issue to a top priority, even if that means pulling development staff from other projects. Your application may be mission critical or can affect thousands of people and you need to make sure that any component that is part of a solution will be treated with extreme urgency. Support also includes different levels of code review. Our staff has years of development experience with protocols and will provide feedback on the most efficient architectural or coding approaches to match your solution requirements. Dart makes sure that support options are available to match the specifications of your project.
Developing products based on “Solutions” is the cornerstone of the Dart philosophy. From this philosophy emerge the pillars on which stand the PowerTCP components. The focus on the Architecture, the Samples, the Documentation, and Customer Support has enabled Dart to bring you the best protocol components available today. Future articles will delve deeper into our architectural model to demonstrate how abstraction in an object-oriented setting can be used to develop scalability and flexibility along with an exploration or the PowerTCP helper objects that have been developed to circumvent the limitations of higher-level languages like Visual Basic.