• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

My WAF or their WAF?

 
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have read some posts where some folks are architecting their solution based on the pet store WAF. what does that mean? do they copy over the architecture as is...i.e WebAction, EJBAction, RequestProcessor etc? or do they make changes in name, behavior etc..i.e FBNAction, FBNProcessor?
Is it alrite to show that I have liked the WAF architecture and modeled my project based on WAF?

Any thoughts, insight would be helpful..

Parag
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If we use architecture similar to WAF, it seems no Business Delegate is used in Web-tier components. Should it be ok?

Thanks.
 
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Using Pet Store WAF structure should be ok, but we must remember that Pet Store is local architecture approach. If web server and application server reside in different machines, we must use distributed architecture.

There's an example of "extended" Pet Store architecture with distributed approach (here). First I was thinking to follow that but now I've started to feel that Event/Command route to EJB tier is too complicated for such a small app (my assignment)... I'm thinking to use simplified version of this example: just one route to EJB tier via Business Delegate: no EJBFactory or CommandFactory. Any thoughts about that? Am I going to wrong direction?

Tomi
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tomi Tuomainen:
Using Pet Store WAF structure should be ok, but we must remember that Pet Store is local architecture approach. If web server and application server reside in different machines, we must use distributed architecture.

There's an example of "extended" Pet Store architecture with distributed approach (here). First I was thinking to follow that but now I've started to feel that Event/Command route to EJB tier is too complicated for such a small app (my assignment)... I'm thinking to use simplified version of this example: just one route to EJB tier via Business Delegate: no EJBFactory or CommandFactory. Any thoughts about that? Am I going to wrong direction?

Tomi




Tomi,
I went through the extended version which uses the CommandEvents,EJBController etc and I also feel that there are too many layers of complicity involved there. But, I had a question on your chosen path. In your simplified version, does the BusinessDelegate (BD) talk one-on-one with a SessionFacade? if it does, then it might also be duplicating every method call in the sessionfacade (SF) and to add more functionality, in the future, the SessionFacade (and the business delegate) would get bloated too. Am i assuming correct?

The reason I assumed that the BD talks to the SF is because in the case of non-web app, the BD might be living on the client tier (right?) and in case of the web app, it might be living on the web tier(right?). so, to communicate with the ejbs, it needs to talk to SD for every remote call. If this is true, I am wondering how would tbe DB and SF's interfaces look if more modules were added to the system, unless, we have BD-SF pairs per module.

any thoughts? or maybe if u elaborate more on ur design approach, it might answer some of my questions..

parag
[ August 04, 2004: Message edited by: Parag Doshi ]
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In WAF, is Web Controller kind of business delegate in web tier, while EJB Controller the session facade in EJB tier?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:
In WAF, is Web Controller kind of business delegate in web tier, while EJB Controller the session facade in EJB tier?



James,
Looking at figure 11.9 on http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/app-arch/app-arch5.html

it seems that the EJB Controller is similar to the web tier Front Controller. It is used to get the proper Command Helper (which I think is similar to the business delegate) that communicates with the session facade. So, the EJB Controller also uses the Session Facade indirectly.

I am not sure which Web Controller you are referring too in the WAF. There are 2 controllers shown in that figure, Front Controller and EJB Tier Controller.

Its interesting to see that the web tier has 2 different paths, one is where the "view helpers" use the Business Delegate to get the view related data and the second is the event based EJB calls which the front controller makes on the EJB Controller. So, yeah, the web tier uses the business delegate but only for data retrieval purposes, i think.

Both the business delegate and the command helper use the Session Facade to meet their needs.

Parag
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok, here are my thoughts...

Originally posted by Parag Doshi:

In your simplified version, does the BusinessDelegate (BD) talk one-on-one with a SessionFacade? if it does, then it might also be duplicating every method call in the sessionfacade (SF) and to add more functionality, in the future, the SessionFacade (and the business delegate) would get bloated too. Am i assuming correct?



According to the BluePrints: "When the Business Delegate is used with a Session Facade, typically there is a one-to-one relationship between the two." So this is ok, BD still has it's role. It reduces coupling between tiers and may implement caching. But it might also make sense to have one to many relationship: one BD accessing several facades (session beans).



The reason I assumed that the BD talks to the SF is because in the case of non-web app, the BD might be living on the client tier (right?) and in case of the web app, it might be living on the web tier(right?).



Right. SL performs lookup and BD minimizes coupling for the client, so these components must reside wherever the client is.



so, to communicate with the ejbs, it needs to talk to SD for every remote call. If this is true, I am wondering how would tbe DB and SF's interfaces look if more modules were added to the system, unless, we have BD-SF pairs per module.



I'm thinking we could have one BD accessing several SF. My architecture is something like Cade's but I've added some components from J2EE patterns: Front Controller, View Helper, Business Delegate, Dispatcher. Looking at Dispatcher View and Service To Worker sequence diagrams helped me a lot. Actually the architecture is taking better shape now when I started to work with my sequence diagrams and I'm forced to think in detail how requests will be handled.

Hope that gives you some ideas... And please correct me if I'm talking bull here!

Tomi
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:


I am not sure which Web Controller you are referring too in the WAF. There are 2 controllers shown in that figure, Front Controller and EJB Tier Controller.

Parag



Parag,
Go to http://java.sun.com/blueprints/code/jps132/docs/index.html
and download the sample code and detailed docs for Petstore example.
You will see Web Controller which is between Front Controller and EJB Controller.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


Parag,
Go to http://java.sun.com/blueprints/code/jps132/docs/index.html
and download the sample code and detailed docs for Petstore example.
You will see Web Controller which is between Front Controller and EJB Controller.



Thanks James. I downloaded the pet store application, but I couldnt find the architectural document in the download. I went through the link you sent me and it takes me to the index page of the petstore. I couldnt see any diagrams there. Could you please point me to the architectural diagram webpage?

Thanks
Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:


Thanks James. I downloaded the pet store application, but I couldnt find the architectural document in the download. I went through the link you sent me and it takes me to the index page of the petstore. I couldnt see any diagrams there. Could you please point me to the architectural diagram webpage?

Thanks
Parag



Parag,

Here is the link to the detailed architectural document of petstore.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1.pdf

Good luck.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


Parag,

Here is the link to the detailed architectural document of petstore.
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/sample-app/sample-app1.3.1.pdf

Good luck.



Thanks James. java.sun.com is down, so couldnt get to the url I will look at the arch when i get my hands on it.

Parag
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


I'm thinking we could have one BD accessing several SF. My architecture is something like Cade's but I've added some components from J2EE patterns: Front Controller, View Helper, Business Delegate, Dispatcher. Looking at Dispatcher View and Service To Worker sequence diagrams helped me a lot. Actually the architecture is taking better shape now when I started to work with my sequence diagrams and I'm forced to think in detail how requests will be handled.

Hope that gives you some ideas... And please correct me if I'm talking bull here!

Tomi



Tomi,
What you said makes a lot of sense and its not bull The only concern I have with having 1 BD talking to many SF is that, the BD interface would have all the methods of each SF interface, as it would be calling a different SF depending on the request. That way, you have effectively reduced the SF interface by dividing it into different smaller SF's, but your BD still remains a bloated interface. unless, the BD is made more smarter than just "delegating" method calls over to the SF.
The BD could logically group the SF calls into more coarse methods instead of having 1-1 method mapping with the SF.
I, too, dont want to add multiple layers of EJBCommand objects unless it becomes necessary to have that kind of abstraction, but, am also trying to figure out a good balance between the BD and SFs. Because I am having difficulty coming to terms with a BD knowing about customer profile mgmt and also about itinerary mgmt..it just doesnt add up..

ur thoughts?

Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:


Tomi,
What you said makes a lot of sense and its not bull The only concern I have with having 1 BD talking to many SF is that, the BD interface would have all the methods of each SF interface, as it would be calling a different SF depending on the request. That way, you have effectively reduced the SF interface by dividing it into different smaller SF's, but your BD still remains a bloated interface. unless, the BD is made more smarter than just "delegating" method calls over to the SF.

Parag



If one BD talks with multiple SF, we will have multiple entry points into EJB-tier. Could we use one SF as main entry point in EJB-tier and then this SF delegates calls to other SF if it is necessary?
Thanks.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


If one BD talks with multiple SF, we will have multiple entry points into EJB-tier. Could we use one SF as main entry point in EJB-tier and then this SF delegates calls to other SF if it is necessary?
Thanks.



James,
You have a valid point. But, the instant you do that, you convert your SF into a EJB Tier Controller, thats what the above figure shows. They have a single entry point in the EJB tier and it acts as a controller and send request to the SF in the system. We are trying to figure out a way to remove all these extra layers from the business tier, unless, they are necessary.
I feel that a system has many sub modules and its not a good idea to have one SF for the entire ejb tier..I would be more comfortable with multiple SF dealing with its set of entity/session beans. For example, I could have a AccountManagerSF, ReservationSF, FulfillmentSF etc, each devoted to its sub module. Thats my thought of the system. I am now in the thought process of figuring out whether I need similar sets of BD for each SF. For example AccountManagerBD-->AccountManagerSF, so on and so forth. Or I could have BD which work across SFs and not tied to a specific SF. That way, the BD would be smarter and not just a dumb "delegator".

this topic is still open for discussion..so please throw in your ideas in the mix !

parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:

I feel that a system has many sub modules and its not a good idea to have one SF for the entire ejb tier..I would be more comfortable with multiple SF dealing with its set of entity/session beans. For example, I could have a AccountManagerSF, ReservationSF, FulfillmentSF etc, each devoted to its sub module. Thats my thought of the system. I am now in the thought process of figuring out whether I need similar sets of BD for each SF. For example AccountManagerBD-->AccountManagerSF, so on and so forth. Or I could have BD which work across SFs and not tied to a specific SF. That way, the BD would be smarter and not just a dumb "delegator".

parag



Parag,
I think if SF talks with just single entity bean or session bean, this SF can be simply a regular session bean and needn't to be SF, like AccountManagerSF may just use CustomerEJB and nothing else, so this AccountManagerSF could become regular stateless bean.

James
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
If one bean like Customer is used by different modules within ejb tier like AccountManager and Reservation, in component diagram should we draw dependence line between AccountManager and Customer, Reservation and Customer respectively?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


Parag,
I think if SF talks with just single entity bean or session bean, this SF can be simply a regular session bean and needn't to be SF, like AccountManagerSF may just use CustomerEJB and nothing else, so this AccountManagerSF could become regular stateless bean.

James



James,
Lets for a minute assume that the AccountManager module speaks to 3 entity beans, Customer, ContactInfo, Address etc. So instead of the BD exposed to these 3 entity beans, a AccountManagerSF would manage the relationship btw these 3 entities. Again, this is just an example, I was just trying to put a thought across that there can be multiple SFs in a system based on its complexity.
And yeah, SF can be either stateful or stateless, depending on requirements. Its main job is to be a facade to complex relationships btw entites and session beans, doesnt matter what its implementation type is (ie. stateful or stateless).

Parag
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag,

I'm not sure which relationship is better between BD and SF: one-to-one or one-to-many. Maybe we could go for one-to-many and let designers/coders do the refactoring if things get too bloated :roll: .

Anyway, I don't think we should worry about one-to-one relationships in general. BluePrints gives a plenty of good reasons for using BD so it won't be just a dummy layer. Also I think BD should always connect to SF even if SF would use a single entity bean. Each layer has it's purpose and it's important that the architecture is consistent.

Tomi
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tomi Tuomainen:
Also I think BD should always connect to SF even if SF would use a single entity bean. Each layer has it's purpose and it's important that the architecture is consistent.

Tomi[/QB]



Tomi,
I don't agree with that BD always connect to SF. In Petstore source code, it seems SignOnEJB (stateless session bean) is used directly by client rather than going through one extra SessionFacade.

James
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:

Lets for a minute assume that the AccountManager module speaks to 3 entity beans, Customer, ContactInfo, Address etc. So instead of the BD exposed to these 3 entity beans, a AccountManagerSF would manage the relationship btw these 3 entities. Again, this is just an example, I was just trying to put a thought across that there can be multiple SFs in a system based on its complexity.

Parag



Parag,
Actually between Customer and ContactInfo, Address, etc, here we can use composite entity pattern rather than using a SF to manage their relationship.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


Parag,
Actually between Customer and ContactInfo, Address, etc, here we can use composite entity pattern rather than using a SF to manage their relationship.



James,
What you say is true, but I also came across this statement in the CompositeEntity design pattern at the java sun site (
http://java.sun.com/blueprints/corej2eepatterns/Patterns/CompositeEntity.html) :


Instead, to avoid the complexity of designing and managing inter-entity relationships, consider using a session bean to help manage the relationships among entity beans. In our experience, we have found that the Session Facade pattern helps us to avoid this problem and provides a better way of managing entity-bean-to-entity-bean relationships.
So, we recommend avoiding entity-bean-to-entity-bean relationships as a best practice and to factor out such relationships into a session bean, using the Session Facade pattern (see "Session Facade" on page 291).



this was mentioned in reference to the composite entity and its dependent objects being entity beans rather than plain java objects.

Anyway, not to drive the conversation away from the main topic of BD and SF,I feel that SF is still going to be an entry point into the ejb tier on most of the occasions.

parag
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tomi Tuomainen:
Parag,

I'm not sure which relationship is better between BD and SF: one-to-one or one-to-many. Maybe we could go for one-to-many and let designers/coders do the refactoring if things get too bloated :roll: .

Anyway, I don't think we should worry about one-to-one relationships in general. BluePrints gives a plenty of good reasons for using BD so it won't be just a dummy layer. Also I think BD should always connect to SF even if SF would use a single entity bean. Each layer has it's purpose and it's important that the architecture is consistent.

Tomi



Tomi,
yeah..even I agree that we shouldnt worry about one-to-one or one-to-many relationships. we would need business delegate-session facade communication for most of our requirements though not sure how brainy will my BD be
The only thing worth mentioning is that the other option which blue prints (pet store app) have used is the concept of web controller (as James has mentioned) and ejb controllers, both communicating via event objects. Just trying to figure out the value add of these extra layers instead of directly using the BD-SF pair.

James - I think the reason the SignOnEJB directly connects to the SignOnEJB instead of going thru the business delegate is becuase its use extends beyond the WAF.so, it does not use the business delegate or any of the controllers to access the session bean. Its treated as a pluggable independent component which can be used in other J2ee application which may not use the WAF.


parag
[ August 05, 2004: Message edited by: Parag Doshi ]
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Tomi,
yeah..even I agree that we shouldnt worry about one-to-one or one-to-many relationships. we would need business delegate-session facade communication for most of our requirements though not sure how brainy will my BD be
The only thing worth mentioning is that the other option which blue prints (pet store app) have used is the concept of web controller (as James has mentioned) and ejb controllers, both communicating via event objects. Just trying to figure out the value add of these extra layers instead of directly using the BD-SF pair.

James - I think the reason the SignOnEJB directly connects to the SignOnEJB instead of going thru the business delegate is becuase its use extends beyond the WAF.so, it does not use the business delegate or any of the controllers to access the session bean. Its treated as a pluggable independent component which can be used in other J2ee application which may not use the WAF.

This brings me to another interesting question. If I want to implement the fast lane reader pattern in my non-web app, then would the DAO also reside on the client tier? The fast lane reader combines a view helper and a DAO to retrieve read only data instead of using a ejb.
Or, would it use its business delegate to retrieve the data via the SF. If it did that, it wouldnt be a fast lane reader anymore.
Another option is that the BD talks to the DAO (both on client tier) and gets the job done.

Too many options

parag
[ August 05, 2004: Message edited by: Parag Doshi ]
 
Ranch Hand
Posts: 215
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I have a basic question. Do we need to include framework (WAF) classes in our design or just core classes?
I think frameworks should be pluggable. What if one decides to use some other framework as Struts? Architecutre should be independent of framework used.
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by D. Rose:
Hi,

I have a basic question. Do we need to include framework (WAF) classes in our design or just core classes?
I think frameworks should be pluggable. What if one decides to use some other framework as Struts? Architecutre should be independent of framework used.



Rose,
The approach I am taking is to include only the core classes in my class diagram, because as u mentioned those are my core architecture classes and has nothing to do with the implementation framework. I am including the WAF classes in my seq and component diagram (as its followed by everyone here and also illustrated in Cade's book). I know there should be a co-relation between the class diagram and its component diagram. To show the relationship, I will also be sterotyping the classes with <<entity>> <<session>> tags wherever appropriate.


hope this helps..

Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:

This brings me to another interesting question. If I want to implement the fast lane reader pattern in my non-web app, then would the DAO also reside on the client tier? The fast lane reader combines a view helper and a DAO to retrieve read only data instead of using a ejb.
Or, would it use its business delegate to retrieve the data via the SF. If it did that, it wouldnt be a fast lane reader anymore.
Another option is that the BD talks to the DAO (both on client tier) and gets the job done.

Too many options

parag

[ August 05, 2004: Message edited by: Parag Doshi ]



Parag,
I think both web-client and rich-client could share the same DAO component which resides in EJB-tier. Meantime, just using stateless bean as both client's entry point to access this DAO. This approach should acheieve similar performance as fast lane reader pattern.

James
 
Tomi Tuomainen
Ranch Hand
Posts: 86
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:

This brings me to another interesting question. If I want to implement the fast lane reader pattern in my non-web app, then would the DAO also reside on the client tier? The fast lane reader combines a view helper and a DAO to retrieve read only data instead of using a ejb.
Or, would it use its business delegate to retrieve the data via the SF. If it did that, it wouldnt be a fast lane reader anymore.
Another option is that the BD talks to the DAO (both on client tier) and gets the job done.



I wouldn't put DAO in any client. Database would be directly open to internet (or at least intranet) which sounds very dangerous . I think all database connections should be created via EJB tier. I don't believe we would gain much performance even if web client would connect directly to database. We certainly would lose container services (connection pooling, transaction management) and would suffer in manageability, maintenability and flexibility since we would have database-specific code in our clients.

I think direct connection to database from a client is ok for a very small app (when EJB container is not used anywhere). But again... this is just my opinion. :roll:

Tomi
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Tomi Tuomainen:


I wouldn't put DAO in any client. Database would be directly open to internet (or at least intranet) which sounds very dangerous . I think all database connections should be created via EJB tier. I don't believe we would gain much performance even if web client would connect directly to database. We certainly would lose container services (connection pooling, transaction management) and would suffer in manageability, maintenability and flexibility since we would have database-specific code in our clients.
I think direct connection to database from a client is ok for a very small app (when EJB container is not used anywhere). But again... this is just my opinion. :roll:

Tomi





Tomi,
Good point. That clarifies things for me. It makes more sense to go the BD-SF way on all points except where the BD needs only a stateless service to be performed. In that case, it would be BD-SLSB.

Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In component/sequence diagram, if we don't follow WAF or Struts framwork, don't put events/actions in it and just simply use some components from J2EE patterns such as Front Controller, View Helper, Business Delegate, Dispatcher, should it be ok?
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:
In component/sequence diagram, if we don't follow WAF or Struts framwork, don't put events/actions in it and just simply use some components from J2EE patterns such as Front Controller, View Helper, Business Delegate, Dispatcher, should it be ok?



Thats the route I am taking. I am not using WAF or Struts, though my web tier looks similar to theirs, but I have my own named components.

Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Parag Doshi:


Thats the route I am taking. I am not using WAF or Struts, though my web tier looks similar to theirs, but I have my own named components.

Parag



Parag,
Thanks. Do you use any Actions/events components, or these are detailed impl and we can just describe them in design docs?

BTW, I am not familar with Struts and could you provide any web links?

James
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:


Parag,
Thanks. Do you use any Actions/events components, or these are detailed impl and we can just describe them in design docs?

BTW, I am not familar with Struts and could you provide any web links?

James



Yes James. I am showing the Action/Event classes in my seq diagram. I think that the seq diagram shows the implementation view of the flow of messages between the diff components in the system. I would also explain these components in the design document.

As for Struts, there 2 links should give you a good starting point :

http://struts.apache.org/

http://struts.apache.org/userGuide/



Thanks,
Parag
 
James J Xu
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Parag,
Thanks for reply. Would you want to show Action in component diagram also?

James
 
Parag Doshi
Ranch Hand
Posts: 317
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by James J Xu:
Parag,
Thanks for reply. Would you want to show Action in component diagram also?

James



James,
I havent decided about that yet. I am still at the seq diagram stage. Although, as of now, I think I will show the Action class (maybe only the base class) in the component diagram and attach a note stating that there can be many specialised Action subclasses residing in the same tier.

Parag
[ August 11, 2004: Message edited by: Parag Doshi ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic