Monday, June 19, 2006

Lightweight java and .net architecture

Lightweight java means java without entity ejb (if need 2pc, we need a “generic” session bean).


Why lightweight Java? – One reason is that ejb is not easy to test. A better reason: ejb is not easy to develop, and, it is not necessary.

To replace entity beans, we need OR mapping (the most popular is hibernate), or, JDBC wrapper, in a less “advanced” situation. Even we use JDBC, there is no “dataset” – always “custom class”.

To replace specific business logic session beans, we need façade design pattern with “business delegates” pattern. Java has build-in dynamic proxy, so, this is easy – it is so easy that it can be done in-house.

Regardless ejb or lightweight, Log4j, or the later (1.4 and later) build-in logging, is always used for logging.

By doing the above, there is a clear separation between UI and business logic, so, it does not matter what UI it will use, Swing or Web. There are some UI level frameworks; they are very useful; however, no need to list them here.

Further, the business logic part can be easily unit tested without using mock objects.

You may say that, no mock object means it is low-tech. To properly "release" the high-tech addiction energy (we all are guilty of it; admit it; we are programmers -- it is our duty to be addictive to cutting edge technologies– we just need to find proper ways to “release” it), I strongly recommend you use cglib. For property level “dynamic proxy”, which also means “AOP”, we need cglib. You may ask why we need property level “dynamic proxy”. The answer: for a lot of things, for example, property level logging, property level security, etc. – sky is the limit. Anyway, at least it is a better excuse than "mock objects" to get into the same cutting edge area.

By the way, in .net, cglib corresponds to Castle’s “dynamic proxy”. Also, in .net, there is no build-in high level “dynamic proxy”, so, in .net, we have to use Castle’s dynamic proxy, even for high level (“façade level”) dynamic proxies.

Since we are in the neighborhood of talking about the high-tech addiction, I want to emphasize that lightweight java does not mean low-tech java: (a) it is still J2EE, because technically J2EE includes servlet-based technologies; (b) it still uses session beans ("generic" ones); (c) it can use cglib, aop. Lightweight java is high-tech, and is cool :-)

OK, enough java. I talk about java, because I want to find another way to talk about .net.

I have been in both java world and M$ world for a while; so, I want to point out two important history items. Apparently, it is NOT known by many people, even in Java world. However, it is still extremely relevant in .net -- history tends to repeat itself.

The first one is about stored procedures. Once upon a time, it was "also” extremely popular in java world. I use “also”, because I certainly know it is extremely popular in VB6 and even now in .net. However, after entity bean and OR mapping, stored procedures disappear.

The second one is about using command pattern as the foundation for distributed computing. In Java world, it was "also" extremely popular, before J2EE and in the early days of J2EE. I use “also”, because I know it is the foundation for CSLA, which is a very popular framework in .net. Before J2EE, IBM had a very ambitious project called “San Francisco project”, it was based on command pattern. In the first a few versions of WebSphere (the flagship app server from IBM), command design pattern was prominent; however, it did not last.

Perhaps .net will not repeat the same route; you never know; no crystal balls; let’s wait and see. Regardless, knowing Java’s history certainly makes it more interesting.

1 Comments:

Blogger survic said...

At 6/18/2006 04:22:06 AM, Vikas said...
Hi Survic,
Can you elaborate on this statement

"The second one is about using command pattern as the foundation for distributed computing. In Java world, it was "also" (I know it is the foundation for CSLA, which is a very popular framework in .net) extremely popular, before J2EE and in the early days of J2EE."

-------------
At 6/18/2006 08:42:05 PM, survic said... (I have to revise the content to make it more like an assay, instead of ranting)

The direct answer:
------------
If you google “IBM San Francisco Project”, you will get a lot of info about it. Also, if you go to Amazon, you can search books, using similar strings. I used it as my reference in designing java projects for quite a while, so, my info is reliable.

Also, you can go to IBM site, and take a look of the documentation of previous versions of WebSphere.

In either San Francisco project, or Websphere docs, you can search for “command patterns”. Then, you can compare it with CSLA’s "workflow class" concept, and CSLA’s "dataportal" concept. Then, everything will be self-explanatory.


More relevant to .net:
--------------

We need to combine CSLA’s propery level usage (i.e. data-binding, validation rules etc.) with Castle’s (or Spring’s) dynamic proxy (Spring only supports façade with interface dynamic proxy; it does not support non-interface dynamic proxy yet).

If you take a look of Castle/Spring, you will see how limiting CSLA’s “dataportal” is. “Dataportal” uses command pattern, with all its advantages and disadvantages.

Its advantages: it is simple. However, note that the fact that it is simple for framework makers means just the opposite to framework users (i.e., “ordinary” application programmers): It is so limiting that framework users must live with a lot of artificial concepts (see below the misuse of “objects are determined by behaviors, not by data”).

The disadvantages:

(a) Limits to 4 (CRUD) methods per class;
(b) to solve problem (a), we need workflow classes, which uses a "pure" command pattern ,and limits to one method per class;
(c) Needs “criteria” and “exists” classes to deal with the fact that "R" routinely needs more methods.

(d) This item is less critical, but still serious: at property level (getter/setter), repetitive code in security checking and rule validation (i.e., those CanRead, WriteProperty, and PropertyHasChanged calls).

You may say: we have code generator; perhaps; however, let’s not use code generators to correct design flaws.

Also, some people are using “objects are determined by behaviors, not by data” to defend (a), (b) and (c). They are implying (or directly claiming) that (a), (b), and (c) are general “features” of OO. However, if you take a look of Castle, Spring, or typical “modern” EJB designs, you will see that we do not need to live with (a), (b), and (c) – they are results of the “command pattern”; not general OO. We should use “façade pattern”, as it is in Castle, Spring, and EJB’s typical design.

This “combination” means a lot of changes in CSLA. However, its “baseline” style can still be CSLA, instead of Castle or Spring, in the sense that it is not a “container”.

Someday, I will post a clean minimalist (i.e., no “container” and no “special” limiting concepts like “4-method dataportal”) framework, with unit tests and working examples. Before that, I am looking for a thing that will leverage the full power of the “custom class” in the age/context of “SOA”: Javascript subset C# to Javascript translator. The good news is that I believe I found it in Ajax framework community.

6/19/2006 10:34:00 PM  

Post a Comment

Subscribe to Post Comments [Atom]

<< Home