Hi,
I spent last few months working over an interesting scenario where there was a requirement of

1. Getting rates from various carriers (FedEx, UPS)
2. Booking a shipment etc.

I short using the APIs exposed by various carriers and use it so that the proposed system may consume the information uniformly.


Following is a brief commentary on how WCF was used to make the system highly scalable (both horizontally and vertically) .
the high level architecture looked like:-

WCF Architecture for Regal




The interesting part of architecture was that each carrier used a common interface. Hence the consumer of the exposed service was only bothered about dealing with a standard set of entities without worrying about the complexities involved in calling and consuming APIs of each carrier.
We deployed the services on TCP(using configurations) and exposed the common interface to the client (which in our case can be WEB application or Windows service) along with a ProxyHelper class which creates channels on demand and keep it in cache (Dictionary) for further use.
Even the Data layer was exposed as WCF service.
By exposing each layer as WebService we made sure the architecture is highly configurable and scalable without comprimising on other aspect.

Another interesting part was reading EDI (Electronic Document interface) which i will be blogging soon in my next series of blogs.

Reviewing Ruby on Rails !!

I am a great fan of rapid application development techniques and lately had a chance to revisit the various frameworks which allow the same. Though I am a .net developer and Silverlight enthusiast, my findings below are without any prejudice and I will like to hear from you if you have something to add or you have altogether a different viewpoint.

During the above research, I was also inclined to determine what factors lend towards a platform to make it fit enough to use it.

Below are few major ones:

1. Rapid development:

2. Facilities provided:

3. Database Interaction:

4. Major Architecture Paradigm followed:

5. Supported UI:

6. Learning curve:

7. Delta between what is already known and what we must acquire to start using the framework:

8. Best Suited for scenarios:
Ruby (Ruby on Rails)

My encounter with Ruby has mostly as Iron Ruby-- port of Ruby which runs on Microsoft platform proclaiming Iron Ruby as Dynamic Language.(http://silverlight.net/learn/dynamiclanguages.aspx)

My first candidate was Ruby (RoR, to be specific.). I like Ruby as a language and like to use it as a Proof of concept for most of the complex algorithms I tend to use while programming.

While Ruby provide great features like "duck typing" and lambda expressions, the thing which I liked most in RoR is intelligent use of Design Patterns, without even bothering the end users of the framework to be concerned about it. By doing that all the "Good Practices" are embedded deep into the architecture during development inherently. Compare this to Microsoft CAB and SF (now known as Prism, in which things get quickly dirty if the developers are not comfortable with the design pattern aspect).

The design patterns like MVC, Scaffolding definitely have a mileage over just plain website of ASP .net.

You may argue (as one of my friend insisted) that ASP .net also have "scaffolding like" features and Visual studio is very capable enough to have a data driven website running within few hours flat(using famous datasets etc). However, the solution generated by Visual studio lacks the architecture which is demanded by any professional application. (Read n tier architecture, TDD design, etc).

The scores along with arguments were

1. Rapid development: Score - 9. I was able to create a working website (MVC implemented along with database in SQL LITE) in 1 hour flat. I must admit I was just plain amazed by the sheer power of RoR framework which generated the directory structure and the code with few simple commands.

2. Facilities provided: Score - 8. Ruby on Rails is intended to emphasize Convention over Configuration (CoC), and the rapid development principle of Don't repeat yourself (DRY). Compare this to N tier Microsoft architecture where services (WCF services) are essentially doing the same task (mostly to delegate to the layer which actually does the task). DRY is essentially something which is missing in most of architecture.

Here is a demo:

Layer


UI


Business Layer


Data Layer


SP / DataBase

Functionality


GetData and bind to grid. Make a GetData Call to BusinessLayer


GetData and filter based on business logic . Make a GetData Call to DataLayer


GetData. Make a GetData Call to SP / database.


GetData

















Read the BOLD text and you will realize that we are repeating ourselves and then also think that how many times we have seen this architecture!!! I am sure your answer will be MOST OF THE TIMES. :D

I idea is not to eliminate the calls but there has to be a way in the framework which will do the plumbing work wherever repetitions are required, if any.

"Convention over Configuration" means a developer only needs to specify unconventional aspects of the application. For example, if there is a class Sale in the model, the corresponding table in the database is called sales by default. It is only if one deviates from this convention, such as calling the table "products sold” that the developer needs to write code regarding these names. Generally, this leads to less code and less repetition.

Consider another example where you specify a database column as:

Name Varchar(50) Not Null.

Then in the UI also you end up writing the same code implementation in form of RequiredFieldValidators. Etc. The logic for field’s validation is scattered on UI as well as Database. The idea is to keep the logic at single, unambiguous place without tight coupling of layers.

3. Database Interaction: Score – 8. Ruby again does fairly well in this aspect as well. For example, using the ActiveRecord module of Rails, the developer does not need to specify database column names in class definitions. Instead, Ruby on Rails can retrieve this information from the database.

From .Net perspective we must use an ORM (Object relational Modeling) tool to achieve the same, and as ORM tools are third party, each ones have their own pros and cons. Some of the great ones I have worked on are LLBL gen (http://www.llblgen.com/defaultgeneric.aspx) and Genome http://www.genom-e.com/.

4. Major Architecture Paradigm followed: Score - 7

· MVC

· Convention over Configuration (CoC),

· Don't repeat yourself (DRY).

· Scaffolding

· Duck typing

· Extensibility: Apart from standard packages, developers can make plug-in to extend existing packages.

· Missing features are: Plug and play functionality (read IOC: inversion of control / Injection Pattern) required so much by almost every professional application. Most of the other patterns like Command etc required by windows apps are missing and must be implemented by hand.

5. Supported UI: Score- 10.Great UI support with excellent support for AJAX. Framework generates all plumbing code required at client side to make AJAX call and the server responding to the request, automatically. Compare this to ASP .net AJAX in which a lot of code is still required to be written for AJAX call. Also most of this code is repetitive both in architectural and business sense.

6. Learning curve: Score – 5. The learning curve associated is very steep. Agreed it may be very easy to build a website but when it actually comes to implementation and tweaking of “conventions”, Ruby may require a great deal of inside “know –hows” of how actually RoR works and other details of “Design patterns” Like MVC, AJAX etc.

7. Delta between what is already known and what we must acquire to start using the framework. Score – 4. There is a HUGE gap for .Net developers. For a Vanilla website developer the intricacies of the RoR may be just to demanding as it expects a great deal of architectural knowledge from them. For instance: A website developer may ask that I do have a MVC (as in ASP .NET aspx page and its code beside .cs / .vb file, NOT to be taken as new MVC .net framework) then why create whole separate classes for these and what are the benefits.

8. Best Suited for scenarios.

· Small to medium websites requiring quick User responsiveness.

· Applications may be deployed over various web servers and not confined to IIS.

My personal verdict for RoR was - It’s great when used for small to medium website like applications. Also the programming paradigm which Ruby follows still requires a very steep learning curve from .net programmers.

In next blog I will be writing about my previous and current project learning’s and architecture (in .Net world) used which implemented the paradigm laid down by RoR and Ruby. I will be blogging on The Castle Project (http://www.castleproject.org/) and the good stuff it brings along. I will be also talking about how .Net (3.5 and 4.0) scores over each of the above in its all new avatar.