Is JATO J2EE BluePrint Compilance

Srini--

> Can some one explain me how does JATO Framework fits

> or falls in the MVC architecture.

I do not have the time to explain the details of this, but I will respond to

some of your comments below.

> We are doing a ND to J2ee Migration using the IMT. Our

> client is very specific about J2EE compliance. As u

> might know the ND stuff gets converted to equivalent

> Java in JATO.

>

> Ex.

>

> pgRentalPage gets converted pgRentalPageViewBean

>

> The issue is the business logic gets mixed up with

> presentation in the ViewBean (JSP is controlled by the

> ViewBean). There seems to be distinct component for

> DataAccess (equivalent of .sdo in ND) in the migrated

> code. But no distinct component for the BusinessLogic.

>

> I do understand that All IMT does is converting ND to

> J2ee. Is that the reason for not having the Business

> Logic separate? If so, do we have to clean up the

> ViewBean to remove the Business logic to a separate

> Layer (May be a EJB or just a Java class)?

ND never had a formal component for business logic, excepting perhaps EJBs

in version 5. As you should expect, the migrated application represents

what you had before in ND. Most large ND apps had business logic

encapsulated in Java classes or EJBs, and only dispatched to these from the

presentation or controller logic. If that was the case, the migrated

application preserves the distinction.

However, if the original application mixed business logic with presentation

logic, the migrated application will have a similar structure. It is not

possible to for the iMT to decide what is business logic and what is

presentation logic in an automated way. This must be done by a human.

But, let me be very clear, there is no *requirement* in the migration

process to change the design of your application and move to a formal

business logic tier if the original application did not have one. If it's

worth the time and effort for you or your client, go right ahead; however,

the migrated application will run without this redesign, in the J2EE

container of your choice. I also submit that making this design change is

not an obvious "pro" decision. If the original ND application worked well

without this separation, or the migrated version is slated to be replaced,

or some combination of other factors, it may not make sense to invest the

effort into changing the design of the application.

Finally, JATO doesn't provide a BusinessLogic entity per se largely because

we feel it would be pointless. Everyone has their own way of encapsulating

business logic--Java classes, EJBs, stored procedures, Web Services, etc. It

makes no sense for JATO to specify a guaranteed-inadequate,

one-size-fits-all solution.

> Presentation as well business logic in the same bean

> doesn't seem to a healthy way of doing things as per

> MVC or J2EE Blueprint. I understand that this very

> similar to the Swing based application (Event Driven).

First, keep in mind that traditional MVC doesn't work on the Web. For this

reason (and because we've learned some things since MVC was originally

designed), some adaptation of the MVC design is required (and desirable).

Therefore, MVC in JATO is an adapted (and what I would call an enhanced)

version of traditional MVC.

Beyond this, event-driven programming is really orthogonal to separation of

business and presentation logic. Events provide developers convenient hooks

for responding to UI-oriented actions. It's possible to put business logic

in an event handler, dispatch to a business logic tier from an event

handler, or both. JATO does not suggest one approach over another, and

instead allows the developer to choose the right approach for the situation.

In this arena, JATO strives to be pragmatic. There is no one right way to

build an application, or even parts of an application. JATO provides

method-based request handling events for those situations where it makes

sense to encapsulate controller or business logic within the object that

"hosts" the event. On the flip side, JATO provides Command objects for

those situations where it makes sense to encapsulate controller or business

logic in a separate, reusable object. And JATO has nothing to say, pro or

con, about how the developer might further partition the application or

delegate to other logic tiers from either of these locations; rather, it

focuses on making these tasks easier by providing enabling technology.

> Hence, my questions are

>

> 1. Is Just Migrated code a complete J2EE compliance?

The short answer is that an application migrated by the iMT to JATO will be

J2EE compliant, and use a number of well-known J2EE/enterprise design

patterns.

But, let's be clear about the question. Formal J2EE compliance has nothing

to do with Blueprints, partitioning of code, or even use of any given design

patterns. J2EE compliance simply means that an application written to the

J2EE APIs (and the attendant design patterns the API requires) will run in a

J2EE-compliant container. All JATO applications will run in any

J2EE-compliant container, and are thus J2EE-compliant.

As for whether JATO follows the J2EE Blueprints, let me first say that JATO

follows the J2EE design patterns put forth by JavaSoft professional

services, and they consider JATO an implementation of various enterprise

design patterns they've identified. Similarly, the J2EE Blueprints follows

these design patterns, though in significantly--sometimes

radicallly--different ways.

The real question to be answered is this: how much adherence to the full

sphere of J2EE recommendations and APIs do you need to build a successful

application? I assure you that using the J2EE Blueprints as your guide is

not required, nor remotely a guarantee of a successful application.

Compliance to some subset of the J2EE API is a minimal requirement. Where

you fall in between is up to you to decide.

> 2. Does it Follow MVC Pattern. If So how? If not what

> would be the OPTIMAL design change required?

Again, I don't have the time to go into an explanation of how JATO follows

the MVC pattern (and it does)--I urge you to review the forum archives and

the documentation included with JATO for more information. Keep the

following in mind when looking at these resources:

- People incorrectly conclude that because JATO provides various event

handler methods, it mixes an application's business logic with presentation

logic. I've addressed this misconception in detail above, but in summary,

event-driven programming and separation of business and presenation logic

are orthogonal.

- People incorrectly conclude that the JSP is JATO's view tier, when in

fact, JATO's view tier is the union of JSPs and JATO View components. The

two work together to provide a rich view tier that cannot be rivaled in

other frameworks. The JSP acts as the rendering specification, specifying

markup and other rendering properties, and the View components act as

presentation controllers and repositories for presentation-related logic and

data.

- We have found that many people get hung up on a physical separation of

model, view, and controller tiers as a requirement for what they call "MVC".

They see View and Model entities in JATO, but not a Controller entity, and

thus conclude that JATO is not "MVC". This isn't the case. JATO has a

formal View and Model tier, but primarily a logical Controller role. This

is why you don't see a Controller class in JATO. Certain objects act as

controller in a tiered, object-oriented way, depending on the scope of what

needs to be "controlled". Control logic can be spread out among a group of

cooperating objects, or focused on one or two objects, whichever is

appropriate for the situation. This feature is what allows real world

applications to be aggregated incrementally, enables a global JATO component

market, and helps large development teams to work together effectively.

However, it can be misleading for those people looking for a formal

Controller entity and physical separation between it and other tiers.

Todd

Guest at 2007-7-1 16:33:53 >