.NET Technology: A Competitive Advantage

So what makes .NET and this new framework different from its competitors and warrants its use for this project? Why was .NET even selected by Company ABC over C++, aside from the obvious " time-to-market " advantages? How did the patterns presented in this book help with that? Why are design principles more important now with .NET than they ever have been in the past with traditional Microsoft languages? Finally, all of the questions accumulated from the previous chapters will be answered here. That is why I even went through the trouble of telling you about this product in the first place. Showing a real commercial application's architecture is the best the way to hammer this stuff home from theory to reality. No more simple e-commerce storefront examples, no more "Adventure Works" demos, and no more Microsoft "Northwind" examples. Major apologies to Microsoft because these well-known demo applications are great, but I thought presenting an application that was generating revenue would be even better. So let me begin to answer these questions.

Why is .NET a Competitive Advantage?

When I was contracted by Company ABC to look into converting its existing framework to .NET, my first response was to ask why. I knew several reasons but I wanted to know why they wanted to do this. Company ABC's lead architect's response was "time to market" and "flexibility." It takes only a few demonstrations to realize why this is true. Time to market is important for all vendors , so I'm not going to rehash the obvious. But what makes .NET and its design potential so flexible is exactly what I will be talking about. With C++, you have the means of creating truly sophisticated and robust applications but unfortunately , the investment in time, resources, and money is also great. With Visual Basic, you can decrease this investment with the added risk of possibly poorly designed applications or one that is inflexible to customization. For those Visual Basic programmers who are laughing at this statement, try on .NET for one year, then go back Visual Basic 6.0; enough said.

Microsoft .NET bridged those worlds for Company ABC by providing the technological means for designing a truly robust, flexible, and sophisticated backbone using resources that already exist and without throwing manpower and money at the effort. The flexibility I'm talking about rests in more than the features and Web service creation capabilities that the .NET framework provides. It's about the runtime environment and the languages themselves . Microsoft finally has a purely object-oriented environment to call its own. I think the market misses this with .NET in all of the Web services media it generates. The framework is much more than Web services.

The framework provides a truly object-oriented development environment with XML at the core . However, this also presents a challenge to the existing developers out there, especially those mired in technology without any care for sound design. To borrow a corny phrase from the movie Spiderman , "with great power comes great responsibility." With .NET, Web Services, and simplified distributed and object-oriented computing with XML, it has never been true more than it is today. The design is now more than ever the key.

Everyone talks about design flexibility but I see very few designs that actually feature it. How many frameworks have you seen that were truly simple to maintain? For the customers of Company ABC, this type of flexibility is what they were referring to when answering my earlier "why" question. As mentioned in the product backgrounder, electronic check processing and all of the payment products must easily integrate with existing accounting packages. They must be integrated quickly, and they must be flexible enough to withstand constant change because these accounting packages change almost annually in version, in rules, and in feature set. This does not refer to flexibility only on the front end. For Company ABC, it is even more important that flexibility be seen on the back end or middle tier , as well.

The system that was delivered provided this flexibility, and it did so without sacrificing simplicity. For example, the time I spent transferring the code to those who now had to support it couldn't have been any easier. In fact, I spent only about three days doing code walkthroughs. The rest of the system was picked up through documented designs (using Rose), a simple yet effective architecture, and the documentation generated from comments all throughout the code. The autodocumentation features of Visual Studio .NET alone saved me countless hours. I guess this is a cautionary tale for those who are looking for unethical job security.

Payment processing rules change monthly, and with the myriad of financial processors out there, the change is neverending. For example, NACHA submits rules updates every few months. This means that the financial processors (the people behind the banks) must change how they interpret a checking transaction. These constant rule changes mean the companies running the financial transactions through must also be aware of those changes. The companies that purchase ProductX want to be able to adapt to those new rules, so that software must be flexible enough to withstand this change in all areas of the system. This is primarily one of the reasons you see so many financial institutions adopting .NET. For more proof, go the http://msdn.microsoft.com/vstudio/productinfo/casestudies/ and see the myriad of financial case studies out there featuring .NET.

The payment processing software must be flexible enough on both the front end and the back end to anticipate these changes without requiring a software update from Company ABC. This has presented a challenge to Company ABC and led to the importance of leveraging some of the flexibility and robustness built into the .NET framework (e.g., Web services, Reflection, XML schemas, etc.). In fact, you probably have noticed that most of the patterns presented in this book center around achieving this flexibility. From the data tier and the Poly Model to the Unchained Web Service Factory, building a fungible architecture is the key to success in this business, as it is in most.

Some of new architecture features of the Commercial Framework not supported in the existing COM framework that was to be bridged included the following:

• Dynamic data tier and data model

• Full SOAP 1.1 support

• Multiplatform support through standardized integration

• Full XML schema support

• Asynchronous entry point for .NET AND non-. NET clients

• Remote tracing

• Asynchronous network operations

• Dynamic error-logging control

• Dynamic remote configuration

• Dynamic deployment

• Web services support

  Commercial Framework Vision Statement

  The original vision statement used before risk mitigation for ProductX and the Commercial Framework was something like the following:

  This application is a step-by-step migration of the existing credit card product using the .NET set of technologies. It will eventually include all features from that original product with the addition of several new .NET features. These new features will come from a business feature level as well as an architecture level and will provide Company ABC with a flexible and simple architecture to build all financial products going forward. (See Figure 6.3.)

  Figure 6.3. Commercial Framework conceptual model (major components ).

  

• "Pluggable" business products design

• Simplified financial processor (bank) control

Initially, this product will include a full bridge to the legacy system for those not yet installing .NET on their server systems or on their workstations. This new product will support the existing legacy product using a bridgelike COM Interop layer to communicate with all back-end COM components. This Interop layer will utilize the .NET COM/API Interop layer as part of the new .NET framework in the first release. A full migration of all original features will constitute the second release of the Commercial Product and include full credit card features.

Without using .NET, many of these things would be rather complicated to design and write. Now I just assume their existence in every major framework I build. It's very easy to get spoiled and forget how much effort had to be put forth in order to receive these niceties. Things such as dynamic data tiering are provided by using Poly Models and must be designed. However, leveraging items such as XML schemas and SOAP support make your job all that much easier. Dynamic error logging, dynamic configuration, and remote tracing are all covered in Chapter 2 and all leverage many built-in implementation patterns that the Commercial Framework offers.

Hopefully, you appreciate by now that the .NET base class libraries are not simple "api wrapper" libraries. They have been designed with patterns "baked in," mostly at the implementation level. Base class library features such as asynchronous networking and Web services are all built on the Observer pattern. Delegate patterns are used everywhere, as you saw in Chapters 3 and 4. Loose coupling, adaptors, and factories are all baked into the .NET framework ”some design- and some implementation-focused. Take a look at how some of the libraries were delivered, and you'll see a plethora of best practices that you get to leverage in your code every day.

So let's dive a little deeper into the technology advantages of .NET and what specifically helped Company ABC achieve its robust "poly architecture," if you will. First I need to describe briefly the main modules or features from this product's architecture. These modules are areas of the architecture that were either migrated to .NET or created from scratch.

Table 6.1 shows necessary plumbing for most frameworks that were applied in this case.

Challenge 6.3

Why were Web services so important? What server-to-server protocol was used? Why was .NET remoting not leveraged?

.NET remoting will be a part of the next Commercial Framework release for Company ABC but scalability was more important for electronic check and payment card products, due to the number of transactions versus the performance per transaction.

Table 6.1. Major architectural features of the commercial framework

Service name	Description	Subfeatures	Purpose
Loosely Coupled Web Services	Web services for driving any function within the Commercial Framework. Uses both early bound and late-bound operations.	Interface-based Web Services ” We can abstract all Web Service implementations using traditional interfaces. Unchained Service Factory “ Chapter 4 pattern implementation using .NET Reflection services. Chained Service Factory ” Another Chapter 4 implementation using a more traditional factory implementation.	Abstracts client from Web service implementations using framework features such as traditional interface-based programming and late binding using Reflection.
Service Fa §ades	Used for driving all business objects and driving packet translation.	Service-Based Fa §ades ” Using more general framework encapsulation tailored for Web Services, Product Manager Classes, and Abstract Packets and their translation.	Provides a means of invoking all framework features without having to call the Web service interfaces.
Managed Client Framework	C# implemented helper methods for calling into the Commercial Product architecture from any .NET client, including ASP.NET. Same library can be used for WinForm and WebForm applications. For example, the same client routines were used for both the CRM client and the managed administration client tools for the Commercial Product using WinForms.	Web Service Proxies ” Repetitive Web Service calls made helper methods here a must. Packet Preparation and Poly Model Tools ” Abstract Packet preparation was made universal no matter what type of client was calling into the framework.	Provides the driver for packet preparation and result set operations to and from the product Web services
Unmanaged Client Framework	Same as the managed client services (row above) except for unmanaged clients.	Unmanaged Poly Model Tools ” Proxy and DataSet tools used for sending product service requests from any unmanaged code, including C++ 6.0 and Visual Basic 6.0. Remember you do not need .NET to call a .NET Web service. Custom C++ Unmanaged DataSet ” Representing the DataSet to the unmanaged world Web Service Proxy ” Used for packaging unmanaged requests and sending to the product Web services. This was a SOAP 2.0 client proxy calling into the Commercial Product architecture.	Most financial packages (SAP at the time, etc.) did not support .NET or any form of Web client integration at the front end (except Microsoft CRM). [a]
Poly Model	All classes that make up the data service tier for the product. All implemented using the Poly Model pattern, as outlined in Chapter 5.	Data Access Interface ” Contains all callable data operations that mimic those of ADO.NET. Filter Builder ” Builds the filter used for Poly Model queries. Common Data Operations ” Operations and helper methods used for Poly Model-specific behaviors such as schema retrieval, storage, and dynamic indexing, as shown in Chapter 5. Data Source Implementations ” These are data source-specific implementations of the Poly Model Interface as defined in main Data Access Interface.	Provides a flexible data model, which was needed because payment rules processing and customer data requirement changes were frequently encountered .
Messaging and Message Listening Windows 2000 Service	Wraps MSMQ for sending and receiving messages from a queue. Can be swamped with other durable queues.	Asynchronous Web Services ” Provides an asynchronous Web service for unmanaged clients without an asynchronous proxy, as in Chapter 7. Message Routing Service ” Windows 2000 service used for picking up messages and routing them appropriately through the framework. Messaging Manager ” MSMQ helper operations for sending and receiving messages.	Provides loosely coupled services, especially for unmanaged clients.
Network Services	General networking helper methods used to communicate to payment processors.	General Network Libraries ” This includes queue-based messaging, FTP, sockets, and other network I/O facilities.	Used to send or post FTP files, send streamed strings to any socket server, etc.
FTP Client and FTP Web Services	Fully functional FTP services used for sending ProductX transactions and receiving ProductX confirmations from participating payment processors. Full source code is included with the book.	FTPWebRequest ” Used by the Network Services component for FTP sends and receives. This is a fully implemented FTP client written in C#. It can also run in a Web service-driven environment on the server. FTPWebResponse ” Used by the FTPWebRequest object for processing FTP control codes and socket responses.	Used because some processors that accept ProductX transactions will accept only FTP streams.
Remote Tracing	Exception handling and logging tracing mechanism used for remotely communicating real-time production and debug information to product support. Featured in Chapter 2.	Trace Viewer ” Graphical viewer used for receiving remote traces from a system on a customer's server. This is used by support to dynamically turn "on" tracing and view a real-time status of a customer's remotely installed Commercial Product system. Web Service ” Centrally receives all remote tracing from a remote system. Used for customers using firewalls. Trace Switching and Custom Trace Listener ” Dynamically controlling all system tracing functionality in code using .NET custom trace listener interfaces.	Provides simplified product support, especially for users not directly controlling the production server where the software is installed.
Scheduling Service	Windows 2000 Service that "fires off" scheduled events. All events are run directly from the framework with a service acting like any other framework client.	Schedule Viewer ” Reads scheduled events from the data using the Poly Model. Reads in XML instance data as a packet and uses the router to send it. Schedule Action Router ” Web service client proxy that uses schedule information packets to send to the framework.	Used because most payment card settlements and ProductX nightly processing is done in a background and scheduled event.
Exception Handling and Tracing Framework	Driver for logging and remote tracing during errors, base class for all custom exceptions and exception formatting. Also custom trace extensions make up this set of services.	Base Exception Class ” Self-explanatory and covered in Chapter 2. SOAP Exception Handling ” Self-explanatory and covered in Chapter 2. Custom SOAP Trace Extension ” A programmatic means for capturing SOAP data packets from our Web services for debugging and production support.	Designing the base class was the impetus for driving our remote tracing.
Instrumentation	Simple means of handling custom profiling and instrumentation without the need for any third-party software.	Inline Instrumentation Operations ” Self-explanatory.	We did not have many product-ready third-party options for .NET, so we wrote our own.
Abstract Data Packet	Packet container for any product data packet passed from tier to tier in the framework.	Abstract Packet ” Encapsulates all data passed in the framework and provides the means to serialize, extract, and manipulate that data based on XML schemas.	Implements the Abstract Packet pattern from Chapter 4 and provides a single parameters type for all data passing.
Product Manager	Used for abstracting differences between managed and unmanaged products (e.g., ProductX, ProductY) ” the framework for all products.	Abstract Base Class ” Abstract parent class for the Product Manager hierarchy. Simplifies packet packaging and unpackaging of product-specific data packets and facilitates their routing.	See Chapter 4 for details.
Packet Translator	Used for converting packets to/from DataSets.	Translator ” Standard "contract" to translate packets between an XML schema-driven DataSet to an Abstract Packet and reverse.	Provides a universal means of translating input and output packets.
ProductY	Driver class that drives all payment card processing within the framework.	Product Manager ” Plugs into Product Manager hierarchy and drives all payment card processing. This is the driver object for the Translator and Mapper objects. Translator ” Maps packets to ProductY components using same pattern and interface as Packet Translator Mapper ” Maps the XML schema and Poly Model object to a COM model for the existing ProductY payment card product. This is part of the legacy product bridge, as outline earlier.	Drives payment card processing.
ProductX	Driver class that drives all electronic check processing within the framework.	Product Manager ” Plugs into Product Manager hierarchy and drives all ProductX processing. This is the driver object for the ProductX Merchant, Processor, File, Batch, Record, and Field objects.	Drives ProductX processing.

^[a] Currently, SAP has a .NET Web services toolkit.

Many of the architecture components described in Table 6.1 are discussed here. From a logic flow perspective, the call originates from the left side of the diagram from a managed or unmanaged test client. This is a placeholder class to show that any managed client can be used to call into the framework using one of the Web Service Factory patterns. A Web Service Factory is implemented by the Chained and Unchained Service Factory (Chapter 4) and is the entry point into the framework. Any of the payment products can be executed from this point, using standardized methods to invoke the business component (more on this in the next section). From the Web Service Factory, a call is made to instantiate the correct Service Fa §ade (e.g., PaymentFacade) that in turn uses the Product Manager to instantiate the correct product.

Once the product (e.g., ProductX) is created, it further delegates its logic to the more specific objects. These child or aggregated objects from the Product Manager are business-specific and contain the rules that drive the originally requested action. Any action can be requested, as long as the request is encapsulated using the appropriate XML schemas. For every requested business function, there is an XML schema specific to that area. The only schema that is used for all business components is a schema called the decision schema. The decision schema simply contains the "verbs" (to borrow an old but effective COM vernacular) that are used by the framework to instantiate the correct Service Fa §ade, instantiate the correct product, and invoke the correct method.

A decision schema looks like the following (Listing 6.1):

Listing 6.1 Example metadata-oriented decision schema for routing messages and invoking downstream business objects in the service factories of the framework.

 <xs:element name="DECISION">    <xs:complexType>       <xs:sequence>          <xs:element name="TYPE" type="xs:string" minOccurs="0" />             <xs:element name="ACTION" type="xs:string" minOccurs="0" />             <xs:element name="SERV" type="xs:string" minOccurs="0" />             <xs:element name="SERVER" type="xs:string" minOccurs="0" />             <xs:element name="SUBTX" type="xs:string" minOccurs="0" />          </xs:sequence>       </xs:complexType>    </xs:element> 

The instance data for the decision schema informs the Web Service Factory what the client wants the framework to do. Creating this meta-language for our framework allows me to use one or two entry methods into the system and prevents future Web service signature changes from affecting its clients. The Web Service Factory's job is to read the decision schema's instance data and instantiate the appropriate Service Fa §ade. From there, the packet is translated into something the framework will recognize, and the drum beats on.

When the packet reaches the Product Manager, the framework begins to delegate from the generic to the specific. From this point, the framework elements are used only in support of the specific business objects that drive products residing on top the framework. ProductX is an example of one of those products. ProductX resides within the Product Manager hierarchy, and from its ProductX class it drives the rules that give ProductX its life. The components that support the reusable features of ProductX, such as exception handling, are those for which these patterns are presented. This "plumbing" and the patterns used are what I will cover in the next section. Many of the architecture services covered should be very familiar.

In fact, most of the Commercial Framework consists of roles you typically see in most frameworks:

• Managers (Web Service Fa §ades and Product Manager)

• Factories (Unchained and Chained Service Factories)

• Delegates (Product Manager and Unmanaged Proxy)

• Exception handling and logging (Remote Trace, etc., from Chapter 2).

• Data access (Poly Model)

• Parameter packaging (Abstract Packet and Packet Translator)

• Caching and other optimizations (Caching, Web Service Interface, etc., from Chapter 7)

• And many more