web vesus Client tier tier for JSP's

[Dhiren Joshi]

Which tier do the JSP's go in component diagram.
What goes in the client tier if the JPS's go in web tier.? Is it left almost emtpy ?
Thanks
Dhiren

[Ramon Gill]

Hi Dhiren,
Cade doesn't mention tiers in his diagrams. He goes from left to right showing JSP's, Controller, Session, etc. Why not do this?

Ray

[Dhiren Joshi]

Ray,
Following AJ and other posts . I went ahead doing tiers for my component. It seemed cleaner. Also Harish Ramachandani did Tiers and got full marks.
From all those posts I got the concept of doing Tiers in component makes demarcation easier and cleaner diagrams.
But now I am confused where to put the JSP's.
Some one suggested presentation but then what goes to client tier then ... ?
Pretty confused now..

Thanks
Dhiren

[Joseph Zhou]

Hi Dhiren,
Things simple . The client tier is the web browser. This is based on SunTone Architecture Methodology, I think SCEA based on it too.

[Ramon Gill]

Hi Joseph,
Can you confirm that your presentation layer also include Controllers (Servlets), Service locators, Business Delegates and DTO's ?

I understand why people use tiers in the component diagram, but I'm confused as to how an application client (non-web) would fit. Would it look the same as a web client apart from JSP's in the client tier being replaced by client screens? Or do you lump eveything as a 'client' in the client tier, and link it to its own controller in the presentation tier?

Ray

[sankha das]

Ray,
Joseph was right in saying jsp's reside in the web/presentation tier. For web-client, yes the browser is the client. For the TA's, you can represent the client tier with a desktop sorta system. You can rightly depict its controller and the Business Delegate in the presentation tier and everything else fits in place. Service Locators could be either Web-tier ServiceLocator or EJB tier ServiceLocator depending on the service and your caching requirements. DTO's will obviously be a part of the business tier. Hope that helps.

Thanks
Sankha Subhra Das

[Joseph Zhou]

Hi Ray,
Thanks Sankha answered most of your questions for me. The application clients can be looked as the same as web client now with Web Start, the only different is it doesn't need UI info, based on this, I think a different Controller is required. I may drop some consideration about RMI/IIOP turnneling through HTTP etc. any comments?

[Dhiren Joshi]

Can I comfortably assume the JSP's to go in the presentation tier.

Can you confirm that your presentation layer also include Controllers (Servlets), Service locators, Business Delegates and DTO's ?

I am confused though how the controllers go to presentation.. Shouldnt that be in the web tier.. ?

For the TA's, you can represent the client tier with a desktop sorta system. You can rightly depict its controller and the Business Delegate in the presentation tier and everything else fits in place.Service Locators could be either Web-tier ServiceLocator or EJB tier ServiceLocator depending on the service and your caching requirements. DTO's will obviously be a part of the business tier

I understand the client for TA and its controllers being in presentation tier but its not clear how the same applies for web client.

Also do I need to show DTO in sequence as well as component or showing in sequence diagram is acceptable and just adding a note for component will do.


Can some one please explain.
Thanks
Dhiren

[Senthil Rajendran]

Hi Dhiren,

Based on what I read as tips by SCEA passouts and other books
this is what I have done

1. Client-Tier package - Has two more packages
1.1 Web-UI package
1.2 Java-UI package

2. Web-Tier package

2.1 Web Package
Filter,front controller,Request Processor,HTML Actions,Events,Web Controller

2.2 Application Web Package
Filter,front controller, Business Delegate

2.3 Common
Service Locator (will be used by both the clients to hit application controller)

3. EJB-Tier package - has EJB Contoller, EJB Action and EJBs.

4. EIS-Tier package - has database and external systems.

[Ramon Gill]

Hi Senthil,
Great explanation. Makes a lot of sense.

One thing though. I was wondering whether the client application would still have its own controller, as well as a controller in the web tier.

Also, what books are you referring to?

thanks,
Ray

[Senthil Rajendran]

Ray,

If you browse through the below "SUN" links you can find contradictory opinions. in the second link they advise to use the same controller for different types of client and in the first link they advise to have seperate controller. I just wanted all my objects to be cohesive, so I have used 2 different controllers.

Application client is not going to generate any events so I deceided not to use a web controller there.

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1078111

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/client_tier/multiple_types/index.html#1028399

BTW Ray I have got a question Have you depcited "Ticket" in any of your models ? is'nt it a part of the domain model ?

Thanks,

Senthil

[Ramon Gill]

Senthil,
I don't have 'ticket' in any of my models. I was thinking of having 'Booked Seat' linked to Segment.

So for the java client, you don't have a complete MVC model on the client? I was thinking of a controller on the Client tier and a controller on the web tier.

Ray

[Joseph Zhou]

Hi Ray,
You are right. If drill down a little bit in application client, we need a controller there. it take responsibilities like next page selection, generating pages from templetes etc.previous the web tier controller did.
I think a Itinerary object is a ticket, it linked all until 1 or more seats(the status of a seat is "booked"). On other side, we have a list of Flight objects for "categories", each linked with a specific set of seats with status either "booked" or "available".

[Annie Zhang]

Originally posted by Senthil Rajendran:
Ray,

If you browse through the below "SUN" links you can find contradictory opinions. in the second link they advise to use the same controller for different types of client and in the first link they advise to have seperate controller. I just wanted all my objects to be cohesive, so I have used 2 different controllers.

Application client is not going to generate any events so I deceided not to use a web controller there.

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/web-tier/web-tier5.html#1078111

http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/client_tier/multiple_types/index.html#1028399

BTW Ray I have got a question Have you depcited "Ticket" in any of your models ? is'nt it a part of the domain model ?

Thanks,

Senthil

In the first link (2nd version), if you add the "protocol router" and take it as a controller, then these two documents are consistent.

[Annie Zhang]

Originally posted by Senthil Rajendran:
Hi Dhiren,

Based on what I read as tips by SCEA passouts and other books
this is what I have done

1. Client-Tier package - Has two more packages
1.1 Web-UI package
1.2 Java-UI package

2. Web-Tier package

2.1 Web Package
Filter,front controller,Request Processor,HTML Actions,Events,Web Controller

2.2 Application Web Package
Filter,front controller, Business Delegate

2.3 Common
Service Locator (will be used by both the clients to hit application controller)

3. EJB-Tier package - has EJB Contoller, EJB Action and EJBs.

4. EIS-Tier package - has database and external systems.

I guess this applys for the petstore, since the functionalities for the
web clients and application clients are different, so they can use different
approach, i.e, the web client uses WAF framework (web controller, ejb controller etc.), while application client(admin) uses its controller and talks to the business delegate which talks to the facade, etc.

For the assignment, the web clients and travel agents have basically same functionalities. I guess it makes senses to have a business delegate and facade to be used by both. However, I don't know how the WAF approach to call the business delegate and facade.

Can anyone please explain this?

Thanks,
Annie

[Senthil Rajendran]

Annie,

Both my clients talk to the same Application Contoller (which will be implemented as a Stateful Session Facade)in the business tier.

Since they are two different clients, they tend to have different behaviour and implementations in the web tier.

Protocol Router is going to indentify the appropriate contoller based on the header information and route it...just to avoid direct coupling its going to act as a mediator, But again I will be having 2 different contollers. I dont forsee any great usage of Protocol Router in this scenario since my contoller is not going to process the request, it will be done by Request Processor

Senthil