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
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?
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?
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.
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
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.
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
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.
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
Originally posted by Parag Doshi:
Tomi,
What you said makes a lot of sense and its not bullThe 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
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.
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
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
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]
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
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.
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).
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
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.
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 ]
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.
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
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?
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
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
Originally posted by James J Xu:
Parag,
Thanks for reply. Would you want to show Action in component diagram also?
James
If you try to please everybody, your progress is limited by the noisiest fool. And this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|