a question concerning Jaworski's Test:
"Suppose that the business logic of an existing application is implemented using a set of CGI programs.
Which Java technologies can be used to implement the CGI programs as a Java-based solution?
B. Screen scrapers
C. Enterprise JavaBeans
The correct answers are:
C. Enterprise JavaBeans
Technically it is possible to replace CGI by EJBs, but it probabely/maybe would not match the customer's needs nor budget.
Having used CGI up to that time
- all clients send http requests, probabely with name/value pair parameters appended after the question mark, and
- all clients expect html or at least http answers as byte streams.
Replacing the CGI programs by EJBs would make it necessary to rewrite or at least heavily change all client software. Instead of sending a http request (byte array) and receiving a http byte stream the clients now would have to lookup a JNDI reference to the EJB's home interface, narrow and cast to an object realizing the EJB's remote interface, and then call [hopefully parameterized] methods of this EJB object. This is a pretty different approach, and therefore this requires totally rewriting the client's code too. If the customer has been asked and has agreed, this is fine, really. But can this be expected to be the normal case?
What do you think?
If no, such a doubtful answer should not be expected in the real and not in a mock test?
Regardless, EJBs are not in direct competition with CGI. The closest technology that Java/J2EE has to CGI is Servlets.
[ January 16, 2003: Message edited by: Chris Mathews ]
Originally posted by Michael Borgwardt:
Servlets are not "the closest to CGI", Servlets are a CGI implementation in Java. Remember: CGI is nothing but an interface specification for the communication between a HTTP server and programs it executes to react to certain HTTP queries.
The Servlet API does not implement the CGI Specification. There is a one-to-one relationship between almost everything in the CGI Specification but that still does not make it an implementation.
Originally posted by Harish Prabhu:
... can use a servlet to intercept the current client requests and then the servlet can forward those requests to the EJB and get the EJB response and send it to the CLient in the format it expects.
yes, that is one way you can do it. This way passes control from client in client tier to servlet in web tier (web container) to EJB in EJB tier (EJB container) [probabely to data access tier or database in data/EIS tier] and back to EJB tier to web tier to client tier. This is the J2EE syle providing the easiest scaleability. On the other hand there are a lot of discussions about performance gains.
There are also some other architectures posible:
- client tier to servlet in web tier (in web container) to JavaBean (also in WEB container, not EJB) to database ...,
- client tier to servlet in web tier (in web container) to database directly via JNDI ...,
i.e. both last ways missing encapsulation and clearly separated tiers, scaleability (some deny ...), manageability and flexibility.