SpiderLogic.com

SpiderLogic.com

By: Bill Witt & Vibhu Srinivasan

Spider Architecture Series

Enterprise Application Framework - Options in .NET Today

Overview

The purpose of this document is to provide the SpiderLogic approach towards implementing a service-oriented architecture on the .NET platform.

The following diagram shows the major building blocks within a service-oriented architecture.  This document will drill down into each of these building blocks and discuss the pertinent issues and approach taken by SpiderLogic.


The Technical perspective

The picture looks the same whether it is .NET, Java or C++. What gets plugged into the various boxes differs. Shown below is how Microsoft views the various layers

 

However even within a technology stack e.g .  .NET, there are so many options, it is often unclear which is the best alternative in a given situation. The sections ahead explore the various options in the different tiers available today.


Service Interface Layer

 This tier typically has all the business objects that clients interact with. In a smaller system, clients directly interact with these backend components creating dependency between the two layers.  A good rule of thumb in design is that the layer below should have no knowledge of the layer above (abstraction). e.g. your data access layer should not know about the business domain layer.

In an N Tier application, each tier should be as decoupled as possible from the other parts of the system to enable. This concept introduced the concept of - “Service Interface Layers”.

The main options today in distributed application are:

  1. Remoting

  2. Web Services

  3. Com +

  4. Asynchronous messaging – MSMQ

  5. HTTP- XML

Remoting:

.NET remoting enables you to build widely distributed applications easily, whether application components are all on one computer or spread out across the entire world.

It is a layer above inter-process communication and clearly separates the client and server component.


Remoting can be used if you want your method calls to
  1. Cross AppDomain boundaries
  2. Cross process boundaries on local machine
  3. Cross machine boundaries on a LAN or WAN

Remoting is the safest to use in across app domains. The default remoting option automatically creates the channels and sinks and the developer does not have to worry about the various options available.

It is easy to switch one communication protocol with another and to change the serialization format without affecting the client or the server. At the same time there are a number of versioning issues. Clients connecting to server activated objects do not have any control over the version that will be activated. The same issue is true for client activated objects. Events and callbacks create performance implications. Both the synchronous and the asynchronous methods can create create problems e.g.server waiting for a response from all clients causing delays.If systems are stateless then remoting is a good option.

If it is stateful (example Client-Activated Objects), a load balancer may throw this out to a different server instance. Servers cannot be automatically started if Client Activated Objects are used. Remoting does not provide distributed transactions, Role bases security and no object pooling out of the box. Remoting infrastructure does allow you to add these features risking the knowledge of the implementer to do these things right. It is a good solution for deploying across App Domain boundaries and using the default channels.  This was reemphasized by Microsoft during PDC 2003. However if the purpose of the application is to provide a framework for integration with other systems, then Web Services are a much better option and are explained in the next section.

When indigo comes out remoting will be supported through the indigo infrastructure. This will help overcome limitations of .NET Remoting like assembly sharing with clients and extend the many benefits of Indigo to developers requiring Remote object semantics. It will however be tough to migrate applications if developers have written custom channels. Other regular remotable applications can easily be ported as an Indigo service by changing a few lines of code.

Web Services

The w3 consortium defines web services as –

“A standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks”

The original definition of a webservice had this notion that it is possible to look up service providers using a UDDI registry and can then use WSDL as a way to identify and then communicate directly with these services In reality the UDDI registry as a generic lookup service is far from reality . Like architecture, webservice  is an overused terms. Companies are using the term webservices for regular XML over HTTP, Stored procedure calls exposed over HTTP,  so on and so forth.


Webservice in the mean while has emerged as a strong tool for B2B integration, in corporations for disparate systems to talk to each other.There are various implementation available today like APACHE – AXIS and .NET web services among others. In .NET it is very easy to create asmx files that can be deployed to IIS .  However a web service is totally stateless. So it is not a viable option if state needs to be kept between client calls. Interoperability is still an issue. There are still data type issues where it is questionable if a java web service that has many elements can talk to a .NET web service. SOAP headers don’t still look the same. The same holds true for XML to object translations. An Object tree serialized to XML using XML serializer in .NET may not work out of the box when read by a java application.


There is no event notification mechanism. Webservices today have to use a poll mechanism which turns out to be expensive

Microsoft, IBM and other partners (nearly are still defining the Web services specification to provide interoperable protocols for Security, Reliable Messaging and Transactions in loosely coupled systems that build on top of the core XML and SOAP standards.


The following specifications are still being worked on  - Messaging Specifications SOAP WS-Addressing WS-Eventing,   Security Specifications WS-Security WS-Trust WS-Federation , Business Process Specifications BPEL4WS, Reliable Messaging Specifications WS-ReliableMessaging , Transaction Specifications WS-AtomicTransaction WS-BusinessActivity  by companies like Microsoft, IBM and BEA systems As you can see the list is long and is not complete.  Even the metadata specifications are being agreed upon. The WS-I consortium is still working through these specifications


The following best practice design guidelines should be followed

Web Services should be used by default in building N Tier systems for defining Service Boundaries.They are simpler to implement and use, they offer the broadest possible reach to client platforms, and ASP.NET Web services client proxy code can be invoked from code run in a sandbox under the default security policy.

Enterprise Services

Enterprise services are a new word for COM+ declarative programming model. Enterprise services are in the namespace System.EnterpriseServices. You can still do all you do in Com+ using this namespace. However there is a price paid in the translation that goes between the .NET and Com + environment. Another disadvantage is that DCOM is the wire protocol underneath. However Com + is not an add-on and comes installed with Windows 2000 and later.


Are the following issues are critical to your application?
Then Com + is the only available option.

Don’t use it unless you are working with existing com + components or if you have a yes to more than three items above.

 

MSMQ 

  Asynchronous messaging has been a standard communication paradigm for many years now. IBM MQSeries, Sonic MQ, MSMQ are some available options The main features are

Hence MSMQ does have its own place if both you have control on both the client and server have a hold on defining the contract.

IIS – HTTP – XML

This is where it all started and is still a viable poor man’s integration alternative.

Data Access

Introduction

Software systems are inherently incomplete without data in them.  Historically databases have grown from mainframe systems to relational databases to object databases like Versant and Poet. Databases tend to have much longer lifespan than products that use them. Developers and designers typically tend to do very less to improve the relational design. OO developers and database administrators typically tend to have conflicting views on relational design

Typically there are three distinct kinds of software projects

Depending on which one of the categories your project falls, there can be different issues that need to be resolved for the data access layer.


For e.g. GUID as primary keys in tables can be easily done for the second and third options. If there is an expert DBA available there will be a focus on the usage of stored procedures, referential integrity, triggers etc. Referential integrity should be controlled at the database level. Referential integrety  forces developer’s to write test code easily and will avoid sudden surprises that may come up when the system goes live.


Stored procedure usage has been debated time and again by the OO community. A general guideline is to use stored procedures for simple CRUD processes or if there are complex joins that are best maintained in a  stored procedure. In many projects the database already has stored procedures that have been developed over the years. A good migration strategy could be to use them as is in the beginning and define a long term plan to slowly move the business rules to the business layer in the code.


The next section discusses options for accessing  data using ADO.NET

ADO .NET

ADO.NET provides quite a few options today for database access.

.NET provides three options for drivers for database access. Native .NET driver, OleDbDriver and ODBC driver

Native drivers are available for SQL server and Oracle from Microsoft. For other databases there is a need to use third party native drivers or OleDb / ODBC drivers.

The .NET Framework Data Provider for OLE DB uses native OLE DB through COM interop to enable data access as shown the picture below. Native drivers are the most efficient way to access data.

 

 .NET provides data layer interfaces in the system.sql namespace. Example are IConnection, ICommand etc. But the data access code cannot directly code to interfaces. There is a SQLConnection and SQLCommand for native Sql server, OleDbConnection and OldDbCommand for the OleDbdriver. The implementation classes also have more to it than strictly implementing the interfaces.

If the database changes from SQL Server to MySql it is not strictly a change in the driver as it is in the case of Java.  The data access code has to change too depending on the driver.

This is a flaw in the way ADO.NET functions today and hopefully this issue will be addressed in the future releases of .NET

Options for accessing data.

To work with the data .NET provides Datareaders and datasets.

Data Reader and Data Sets

Data readers are read only, forward cursor and are provider very high performance. Datasets are in memory copy of table and provide a disconnected way to work with data. They carry the relationship between the tables and also the metadata information along with them. They track data changes in batch.

Datasets are serializable by default. The tools are too simple to use and hence developers tend to push the entire table to users including the relationship between the tables. The metadata about the tables are never required in most cases. The default serialization format is XML and hence it is expensive  However Datasets should not be discounted totally. They can be used for reporting apps where there are no rules to implement. There are also useful for smaller web applications when the UI is just a view to the database and useful in short lived interim applications.

In N Tier apps it is a good design principle to not use datasets to pass data between the various layers. Many applications use datasets at the data access layer alone. It is also much easier to just work with readers and POCO’s (Plain old C# objects) for passing data between different layers.

OR Mapper

Microsoft will be releasing Object Spaces in the System.Data.Objectspaces namespace in the next release of .NET. Objectspaces will put to rest the debate on OR Mapping. This will be a robust OR mapping API that will be in par with implementations like Top Link and Hibernate in java.

Regular objects can be persisted to the database using a persistence manager. No interfaces have to be implemented nor any class to be inherited to make an object persistable.

 

It will be an easy migration path to go from regular POCO’s / data readers to Object spaces than it will be from datasets to object spaces.

Note: WilsonORMapper an Object spaces implementation by a .NET developer called Paul Wilson is a good place to start to learn Object Spaces

 

Arch4Net Mapper

SpiderLogic has a basic implementation of a data access mapper which is based on previous experience. This is built into the Arch4Net SpiderLogic toolset. This mapper is built on a simple one table, one mapper paradigm and provides  options for doing CRUD operations.

Arch4Net toolset

Arch4Net toolbox is a set of common utilities. The following are in the toolbox now.

A Lightweight OR mapping layer based on experiences from a number of OO projects A file watcher utility A search service that works with Microsoft index server. A security service that allows to set up users and roles using Microsoft .NET proposed architecture.

Conclusion

There is no "one right solution " to any problem at hand. Each option you pick will have pros and cons.  However it is important to weigh the options available today with a view on where technology is going. Experience is  an important factor in picking a solution over another. The "team factor" is probably the most important factor that should influence the decision making process. Can your project team deal with the choices being made? Are you willing to invest in training the team?

Microsoft recently published a number of articles on  software architecure, which can be used as a starting point to start making the choices in a project.This article covered only the service layer and the database layer for the most. In the next one we will look some of the other components that make up a typical project.