Eduard Manas

Ranch Hand
+ Follow
since May 12, 2002
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Eduard Manas

Hi there,
Regarding to the intial question, my approach has been to split the class and component diagrams in smaller and more manageable diagrams; and I have added most of the VO objects I have used. I know they say to only submit ONE class/component diagram, but I am sorry, I don't agree with them.
Any class diagram with 25-30 classes is going to be far too big and cluttered, not to mention a hell to maintain and update in the future, or attempting to print it out in any standard piece of paper. On the top of that, if you have got developers only working in one use case, you make them swallow a huge class diagram that contains a lot of classes out of context for them.
In the same way I also think that only one sequence diagram for each use case will make far too big diagrams (same reasoning). I have also split them on (more or less) one sequence diagram for user interaction. I haven't added VO on them, although I provide comments saying what VO should be used.
I have reasoned my approach (and it's too late to change it anyway), so if they like it fine, and if not... then I'll have to buy Cade's book to see how it has to be done for the assigment, but my respect for SCEA will have drop considerably.
Just the future will tell...
Does anyone knows whether the logos for SCJP, SCWCD and SCEA are different?
I agree, both BEA Weblogic and IBM Websphere have plug ins for the web server to do the load balancing of the apps servers.
However, what is the purpose of buying expensive and smart load balancers (thinking about CISCO here) if a small and cheap plug in can do the job? Surely there is a catch somewhere! and that catch is that the plug in only does simple load balancing, and you cannot configure it. So if you have a 'smart' load balancer in front of the web servers cluster, this will only have effect on the load of web servers, and the plug in will undo all the 'intelligence' of the load balancer.
I put that question through to both a BEA Weblogic and IBM Websphere administrator course instructor (maybe not the best person to answer that question though). One said simply 'I don't know' and the other said 'if you want more load in one machine, then put two instances of the app server there'. I'll leave with you what intructor said what... the point is that neither had a clue.
Does anyone know?

Originally posted by Bill Morrison:
If we first assume that one or more web servers behind a firewall are responsible for accepting SSL connections from the Internet,

um, that's a good point!, it seems we start to move forward to the bottom of this problem...
I agree Bill, web servers are also in charge of SSL, and in fact this requires a lot of processing power. Take for example a banking application, you don't have much static html in there, but all communication is done via SSL. What is sure is that you don't want your app server wasting processing power on this. It makes sense having a dedicated cluster of web servers doing SSL (probably with encryption hardware) and also some HTML caching.
The question now is should we put the web container in the same box as the web server, or out in the app server? I must admit that my answer is now put it in the app server box!
Let's see what you think. You want a dedicated web server doing SSL and static HTML caching in the DMZ (unsecured network). On the top of that, you don't want your servlets to run in an unsecured network, so you must put them behind the second firewall. I think that it makes sense to put them in the app server box, as this will allow local calls between servlets and EJBs, although I admit you could still have them in another separated box.
At least it makes sense to me!

Originally posted by guy katz:
i can point out that in cade's book he showed a deployment diagram with two web servers including the servlet containers on the same machine as the web servers and another machine for the app server.

I don't have Cade's book but that sounds very interesting!
Does he explicetly say that the web container (servlets) are placed in the same machine as web server? Does he explains why he choose that?

Ideally you would want as many machines as possible everywhere (load balancers, web servers, app servers, database, ...) The only problem is that some times (99.9% of the time!) companies are limited by money, so you have to compromise. I would personally advise having at least two of each.
Take into account that if your only web server fails, it doesn't matter how many app servers you have got behind, no requests will go through. If you chose to only have a static html web server, then you could have many smaller and cheaper machines, so why not having two if you can afford it (or three, or four...). Also, web servers are usually on the first line of fire (after the external firewall), so you may want to have at least two just in case.
Just for the record, most of the literature I've read advises to have the web server in one box, and both web container and ejb container in another.
There must be a compelling reason out there and only few privileged people know why...

Originally posted by Bill Morrison:

My approach to requirements analysis has been to consider the few "clear requirements" in a way that is specifically addressed in the design. Then, to concider the many "unclear requirements" as justification to include flexibility, abstraction, extensibility, etc. A clear requirement deserves an optimized design, an unclear requirement might mean a more resilient design.

Bill, that's an excellent point!
I also agree in that there is no specific requirements for Swing. In my opinion, as long as you have done a good facade layer for the business layer you can potentially put anything you want on top of it, you name it web presentation layer or Swing presentation layer.
However, from a practical point of view, would you develop a Swing front-end as well as a Web front-end just to prove to the customer that your architecture is flexible enough? My answer would be do it **just and only just** if the client asks for it explicetly and understands the extra cost on development, maintenance and extensibility, which will not be cheap.

My approach for the project (unless somebody convinces me otherwise) will be to do a web front-end and point out that a Swing front-end would easily fit in this architecture, but it isn't required (and of course all that has already been agreed with the customer!)
This is the typical discussion that I have seen many times in this and other forums. It seems that most people believe that a Swing front-end is necessary for intranet users.
I personally believe this is non-sense, and I have asked for other opinions in this forum but I didn't get any replies.
Nonetheless, the main arguments in favour of having a Swing front-end are:
1) They understand that the an 'application' implies a Swing front-end
2) They believe that a Swing front-end will give a cut of half the performance of internet users.
As I have said, I don't believe any of the above points is true. If anyone knows any other point in favour of Swing front-end please share!
First of all, more and more 'applications' are starting to be developed in Web front-end, in direct competition to Swing. The benefit of this approach is that you only need a front-end for both internet and intranet users, thus reducing development cost, and increasing maintenance and extensibility. In fact, Sun has recognised this and is working hard on a Web API for screen design called JavaServer Faces.
I doubt that the performance of a swing front-end is much better than a pre-compiled JSP retrieved from an intranet. The only difference is that with Swing you will by-pass the Web servers containing static HTML. However I don't think that by-passing the Web servers is going to give you much performance boost, as the real bottleneck where most of the processing power is needed is in your application servers and database.
The truth is that Swing front-end has never gained momentum. My impression is that they are buggy, slow and hard to maintain. The only benefit of Swing over HTML front-end is drag-and-drop, which is rarely needed.
Anyway, that's my opinion and I am looking forward to hear from others.
I know that the spec says that the container must take care of all references to other EJBs when serializing.
So my answer would be yes if you had the reference to B directly in A, because the container **must** do it.
What I'm not so sure is if the reference to B is in a helper objects of A. My feeling is yes, as the container will apply recursively the same serialization algorithm (which takes care of EJB references). But not sure...
Han Ming,
I don't know in the US, but in the UK few employers will give you a job just on the basis that you are certified (if any!). They just hire you from your CV and knowledge, and if you are a certified J2EE architect that's just a bonus, but nothing else.
I take the certification as a personal achievement and as an 'excuse' of learning/specialising in new technologies. Who would start studying day in day out after work without a clear objective at the end of the road? I wouldn't.
From my point of view I don't think it is worth repeating the certification just with the idea that it will give you jobs, because it won't!
My advise would be repeat it only if you feel like in two years time. If you don't, don't worry as Sun says they won't remove your 'Sun Certified Enterprise Architect' title.
The rational is that in that way Sun earns more money!
Another discussion point is to whether deploying the WARs in a different machine than the JARs. In other words, whether to have the server container in the same JVM as the EJB container.

Originally posted by Chris Mathews:

I highly discourage this. In almost all cases it is better to co-locate the Web and EJB Tiers. Otherwise, every call to an EJB will be a remote call and this will greatly affect performance of your system.
[ April 06, 2003: Message edited by: Chris Mathews ]

I agree that a lot of the literature says that, but I think the point of having the session facade layer is that you only need to make one remote call to the application server, thus I don't see that's a problem!
I think (unless I'm missing something), that to decide what approach is faster you first need to know what communication mechanism between two machines is faster , either to send a HTTP message or a remote RMI/IIOP message?
I'll explain myself. Let's say we have two machines named A and B. On the first scenario we have Apache (web server) and Tomcat (web container) in machine A, and Weblogic (EJb container) in machine B. In this scenario servlets from machine A will communicate with Weblogic by using remote RMI.
On the second scenario, we have Apache in machine A, and Weblogic (web container and ejb container) in machine B. Apache forwards all non-static requests to the web container in machine B by using HTTP. Servlets will communicate with EJBs via local calls (thus the session facade is still good but not that important!)
The reason why I think this would be interesting to know is because in some cases you may need all the machine power for your business logic (in machine B). So a posible solution to this problem could be to take your servlets out of that machine and put them somewhere else.
Does anyone agree?
Thanks for your comments guys!
First of all I also agree that Web servers are ideal to put them in a DMZ and serving static html. In fact, that is the typical DMZ organisation: an outer firewall only allowing traffic on ports 80 and 443, then the web servers, and then the internal firewall only allowing traffic from the web server.
What I also understand is that if you have a lot of static html (like in an online newspaper, for example) then you need to do something to get all that html to the Apache server.
However, if you don't have too much static html, like in the petstore or in a flight reservation system, I don't see the point of doing that. What you generally would have is the static html inside the WAR, and you then deploy the WAR in the application server (not the web server).
What I assume is that Apache will cache all static html on the fly... or maybe not! I don't know just I think it would be the logical think to do. If that's true, then there is no need to separate the static html from the war, even if the amount of static html it's big, as the first time that it's requested it will be cached in the web server.
Does anyone know?

PS: By the way, this question is related to the Part 2 assigment.
What I don't understand is why some people in this and other forums say that you need to use Swing to 'ensure' that the response time for operators will be half the time of internet users. I think most (maybe over 85%) of the processing time will be spent on the application server, thus the overhead of going through the web server is negligeble! I even think that an intranet web based application would be faster than a Swing application.
Hi everyone,
I am sure that most than one will say that this is a trivial question for an architect... which is great, because I'll have more chances of somebody helping me!
Assume you have a typical architecture with three machines, two smaller ones where you have web servers on it (with Apache), and a more powerful one where you have the application server (either Weblogic or Websphere). For simplicity your application is Sun's Petstore.
Your application is packaged in a single EAR, containing several JARs and one WAR. The WAR contains all your servlets, JSPs and static html code. You deploy the EAR in the application server.
Given this architecture (which I think it is quite common), the only use I can see of the web servers is to proxy HTTP requests to the application server, and caching the static html code. As the static HTML in the WAR, I don't see the need of directly putting it in the web server.
If this is the only role, then surely you don't need very powerful machines at all for the web server. I'd say you could make it with just a couple of good Pentium 4s running Apache on them.
* Does anyone agree with me?
* Does anyone knows any other practical use of the web server in this architecture?
* Does anyone thinks it is better to deploy the WAR in the same machine as the web server, thus requiring a more powerful machine here, but releasing the pressure in the application server?
Thanks in advance
As I understand it (but again security is not my 'favourite' subject) a reverse proxy is the same as a normal proxy, but instead of monitoring outgoing traffic (ie from your network out) they monitor incoming traffic (ie from the outside in).
Having said that I don't see why reverse proxies cannot do load balancing by putting a little bit of intelligence in the proxy.
I think I agree with you here, the ejbLoad should not be correct, as it can only be called when you are already in the 'Ready' state, thus strictly speaking it cannot 'bring' you there , because you already are!
Correct answers should be ejbCreate/ejbPostCreate and ejbActivate