Part II - EJB talks to existing system

[Cindy Li]

Would anyone help on this?
How does an EJB (or container) talk to an existing system, which is built on html,CGI and Oracle?
Can EJB talk to that database without going through the existing system? Especially if an entity bean is to be created in the container from the tables in the database, how does persistence work in this case??
What is the protocol to use, RMI or IIOP?
Thanks,

[walter wang]

then u dont need use EJB to talk with CGI- ORACLE system
since this system alreay could handle URL request
you could use just send http request , you could send http request
through sessionbean, servlet, jsp, HttpConnection .....
how it helps

[manoj pillai]

You could implement an entity bean for the external system by using DAOs. As walter has pointer out, http connection is what your DAO will need to use to access the data from the external system.

[Cindy Li]

Does it mean that I should use BMP,and DAO to embed http request/response?
Since the persistence doesn't occur directly between Eejb and database, Will performance be an issue?
Should I deploy the bean twice as read only and r/w bean?
Thanks,
Li Xin

[manoj pillai]

Yes BMP with DAO is what you need to model it as an Entity Bean. There are patterns to improve performance in such kind of situations - eg., Dirty Marker interface.

[Dhiren Joshi]

Is this interface a purley http based interface .? Thats what I had got from previous posts.
If so can we use a JAX-RPC with EJB statelessBean as the service end point which connects to the backend. In this way the session bean can handle transactions also .. ?
Any suggestions

[Aanand Joshi]

I think intent is to reuse existing legacy system By creating entity bean, we are re-inventing the functionality that already exists in the legacy system. In my opinion, stateless session EJB should be used as a "wrapper" with HttpConnection interface to talk to existing system. It can be implemented using Web-Service paradigm.
Any counterviews/flashes gladly accepted.
regards

anand

[romeo juliet]

As Anand mentioned, I think SLSB is the way to go.

SLSB -> DAO -> HTTPConnection request to FFMS

FFMS - frequent flyer mileage system
SLSB - stateless session bean


I'm designing the system assuming that the new system would interact with FFMS only to retrieve read only data. The second paragraph of Background of the assignment doesn't say anything about updating the FFMS. Any thoughts!

- Roger

[Chi Nguyen]

Hi

I'm designing the system assuming that the new system would interact with FFMS only to retrieve read only data. The second paragraph of Background of the assignment doesn't say anything about updating the FFMS. Any thoughts!

I have the same thought with you on this. Because logically, a customer cannot modify his/her mileage. So read only data make sense here

[edited to replace the CODE tag by a QUOTE tag to solve horizontal scrolling problems on the page - Phil]
[ June 08, 2004: Message edited by: Philippe Maquet ]

[Dhiren Joshi]

I am assuming there must be a milage system in place which updates the user mileage through batch or otherwise.
This update/batch is reading data right now from a Legacy system and if that moves to an Oracle based DB ,should we implement some mechanism to update the data as well ... ? The FFMS system is already Oracle based so either it must have some way of updating the mileage ..



Also why do we need a DAO in between the SLSB .. ? There is no DB access done here it is simply a connection to the FFMS which is purely HTTP based. No update can be done only read only I assume ...

any thoughts... .

Dhiren

[Roger Chang]

There are a few issues involved...i am confusing tooooooo...
Maybe i go too far

My assumption:

1) Mile System must be updatable.
2) We cannot touch FFMS source code but have to interface it, hence, webservice is not feasiable.
3) Transaction context must be somehow propagated to FFMS.

The only way i can think about is to use HTTPConnection and get
response back... Tell if transaction over the other end is successful
based on return HTML... then commit/rollback transaction in EJB according..

Any comments??

[Dhiren Joshi]

1. Mileage is update .. I never thought about it that it could be done thru the same FFMS HTML based interface ... Possibly assume the mileage is getting updated via the same interface currently then it can be merged with the new design using EJB.
Propogating of ttransaction context I would think its more like calling the interface with EJB method in a transaction context which is calling the FFMS.

Why webservices can not be used ... WebServices is not for the connection between EJB and FFMS ... I never implied it that way. I am saying that develop the EJB as an EJB service endpoint. One minus though the callers transaction context cannot be used but this is not really required in the design or is it ?

making EJB service endpoint ..it will be a transparent architecture for the GUI client and J2EE client.

Any comments ?

Dhiren

[Roger Chang]

Well, i think the FFMS can be updated from web based method call

One may use a SLSB with DAO that calls FFMS via HTTPConnection and parse
HTML that returned from FFMS to tell if update is successful.

This approach provides possible replacement of FFMS laster (DAO can be
easily plug-in). This DAO somehow simulates the behavior of transaction
propagation(possible with security context propagation as well)....that
is, if returned HTML is a failure page, transaction
roll back otherwise commit. Major drawback is, one has to hard code the
return HTML....well, I know this approach is pretty stupid, but it works..

As for the webservice endpoint, I am not sure about the EJB specification
version supposed to be used in SCEA... ... are we going too far if using
EJB 2.1?...


Any comments?

yakiy

[Chris Beels]

2 thoughts on this:
1. It seems odd that people are openly discussing parts of the assignment.
2. All of these answers are way more detailed than you need exam-wise.

[Java Chela]

I think purpose is not to rewrite the fuctionalities provided by frequent flyer mileage system, but to reuse it. Whatever technology we use, we will be getting html as response. For indivudal users it is okay, but for travel agents, the client is a Java (Swing) client. How do we show the html in Java client? Are we gonna parse html code or write/use some peice of code that displays html in a Java(Swing) Client.

Am I missing something?

Thanks.
Chela

[Java Chela]

I think purpose is not to rewrite the fuctionalities provided by frequent flyer mileage system, but to reuse it. Whatever technology we use, we will be getting html as response. For indivudal users it is okay, but for travel agents, the client is a Java (Swing) client. How do we show the html in Java client? Are we gonna parse html code or write/use some peice of code that displays html in a Java(Swing) Client.

Am I missing something?

Thanks.
Chela

[SAFROLE YUTANI]

Originally posted by Java Chela:
I think purpose is not to rewrite the fuctionalities provided by frequent flyer mileage system, but to reuse it. Whatever technology we use, we will be getting html as response. For indivudal users it is okay, but for travel agents, the client is a Java (Swing) client. How do we show the html in Java client? Are we gonna parse html code or write/use some peice of code that displays html in a Java(Swing) Client.

Am I missing something?

Thanks.
Chela

The FFMS is basically a web server running CGI/Perl, so it must be accessed from a HTTP/TCP-IP context, which means that you can only receive HTML data back from the web server. Knowing that, you have no choice but to parse the HTML and extract the customers mileage data. Once you have the data, you can return a object that nicely contains the mileage info, which then can be used in a JSP (for the customer client) or a Swing application (for the Travel Agent).

The entire process of accessing the FFMS web server should be performed via a Stateless EJB. That will make it easy for both types of clients to access the FFMS data.

Customer Web Client
-------------------
Web Browser -> Servlet -> Business Delegate -> SSB -> DAO -> HttpConnection -> CGI/Perl FFMS Web Server

Travel Agen Client (Swing App)
------------------------------
Swing Client -> Business Delegate -> SSB -> DAO -> HttpConnection -> CGI/Perl FFMS Web Server

Of course, when the response comes back from the HttpConnection, the DAO must be aware to parse out the mileage data, then return an object containing the data.