• 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

EJBs to replace CGI? - doubtful.

 
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
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?
A. JMAPI
B. Screen scrapers
C. Enterprise JavaBeans
D. Servlets
The correct answers are:
C. Enterprise JavaBeans
D. Servlets"

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?
Thomas.
 
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Maybe what he (Jaworski) meant was Servlets + EJBs can effectively replace CGI. Though I would argue that EJBs are not strictly necessary in this case.
Regardless, EJBs are not in direct competition with CGI. The closest technology that Java/J2EE has to CGI is Servlets.
My $.02
[ January 16, 2003: Message edited by: Chris Mathews ]
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Chris Mathews
Ranch Hand
Posts: 2713
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You 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.
Thats my 2 cents . Correct me if i am wrong
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.


Hi Harish,
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.
Thomas.
 
reply
    Bookmark Topic Watch Topic
  • New Topic