Porting a web-app from win/COM world to Jsp/Tomcat...

[Dag Sunde]

I've been charged with the task of porting a small web-application
from its current incaration as asp-pages using COM components for
the business-logic to a cross-platform solution where the owner
can choose where to run it (Windows/Linux/xxx)

I will probably choose an Apache/Tomcat combination, and implement the
business logic as servlest and port the asp-pages to jsp.

But! One of the existing COM components in use is imlemented as an
"Out-of-process" server ie. an "ActiveX EXE". This component have
a GUI, and is called by the other components to store data, etc.

This GUI shows in realtime the different transactions, logged in
users, etc. for the benefit for the system operator on the server.

Can you give me some hints on how to implement this using Tomcat
as a servlet container? Because as far as I know, There is no
possibility of putting a visible face on something running under
control og TomCat?

So far I have come up with the following solution:
Browser --> Tomcat Servlet --> RMI --> Stand alone Java App w/gui

Does this sound feasible?

TIA...

 

[jan V]

Can you give me some hints on how to implement this using Tomcat

as a servlet container? Because as far as I know, There is no
possibility of putting a visible face on something running under
control og TomCat?

I don't see why not. I've never done this, but I can imagine a Servlet
popping up a Swing GUI like any other Java code can... If Tomcat really did
prevent this, I'd love to know how and why...

So far I have come up with the following solution:
Browser --> Tomcat Servlet --> RMI --> Stand alone Java App w/gui

Does this sound feasible?

While the separation of concerns in this architecture must be attractive,
the last two parts may be a decoupling step too far for what you need. One
(big) advantage of your current architecture is that you could let the
system adminstrator run the monitoring GUI remotely... that's a big deal.

 

[Dag Sunde]

I don't see why not. I've never done this, but I can imagine a Servlet
popping up a Swing GUI like any other Java code can... If Tomcat really
did
prevent this, I'd love to know how and why...

You were right!

A servler *is* able to show a GUI. I Just added a Frame, and showed
it on the server. Now, I just have to make some kind of Singleton
out of it, So the GUI is shown when the first request hit the servlet,
but that it stays open and is reused without loosing its information
between calls to the servlet.

While the separation of concerns in this architecture must be attractive,
the last two parts may be a decoupling step too far for what you need. One
(big) advantage of your current architecture is that you could let the
system adminstrator run the monitoring GUI remotely... that's a big deal.

To be able to run the monitoring GUI remotely *is* actually a prefered
solution, so maybe I should drop the "GUI-in-Servlet" already, and go
for RMI on the last step.

 

[jan V]

While the separation of concerns in this architecture must be attractive,

deal.

To be able to run the monitoring GUI remotely *is* actually a prefered
solution, so maybe I should drop the "GUI-in-Servlet" already, and go
for RMI on the last step.

If you've already got RMI experience, of course use RMI. I needed an
architecture like yours a while back, and I opted for serialization of
objects plus plain TCP/IP. Nowadays, I'd like to try to do the same using
RMI... but the key problem is getting your protocol right. You need to
completely forget how the two ends talk together, and concentrate fully on
what is going to be communicated, and when. During development, I used proxy
objects to hide the fact that there would be a comms "gap" in the final
version. This was a great help in debugging, because when you hit a problem,
you can run the system using proxies which fake the comms gap.. so you can
trivially answer questions like "is the problem in my comms, or is it
protocol related?"

I used UML Sequence diagrams to design my protocol, and didn't proceed to
code until I was 300% sure my protocol would give me all I needed.

 

[Dag Sunde]

If you've already got RMI experience, of course use RMI. I needed an
architecture like yours a while back, and I opted for serialization of
objects plus plain TCP/IP. Nowadays, I'd like to try to do the same using
RMI... but the key problem is getting your protocol right. You need to
completely forget how the two ends talk together, and concentrate fully on
what is going to be communicated, and when. During development, I used
proxy
objects to hide the fact that there would be a comms "gap" in the final
version. This was a great help in debugging, because when you hit a
problem,
you can run the system using proxies which fake the comms gap.. so you can
trivially answer questions like "is the problem in my comms, or is it
protocol related?"

I'm used to Corba/IIOP, so I think this would be the best solution for me.

I used UML Sequence diagrams to design my protocol, and didn't proceed to
code until I was 300% sure my protocol would give me all I needed.

Wise move.

Thanks for all the input, Jan...

 

[pkriens]

Did you consider using an OSGi environment? The advantage is that you
can easily add servlets but you are not resticted by the servlet life
cycle model. Additionally, the service registry allows you to decouple
the different components so it does not become monolithic. Tomcat is
available as Http service, as are other web servers. Also for example
derby (Java SQL application) is available as bundle.

There are several open source implementations and the set of bundles is
growing rapidly at the moment. Apache is now also adopting OSGi for
several projects and have an incubator for an OSGi Framework called
Felix/Oscar. Take a look at

http://www.eclipse.org/osgi
http://www.knopflerfish.org
http://oscar.objectweb.org/
http://incubator.apache.org/projects/oscar.html (aka Felix)

The OSGi environment basically allows you access to all the services of
Tomcat but provides a very convenient life cycle management
environment. You can install/start/stop/update/uninstall applications
without ever having to restart the VM. Very convenient.

If you want to know more, contact me offline.

Kind regards,

Peter Kriens

 

[Paul Cager]

But! One of the existing COM components in use is imlemented as an
"Out-of-process" server ie. an "ActiveX EXE". This component have
a GUI, and is called by the other components to store data, etc.

This GUI shows in realtime the different transactions, logged in
users, etc. for the benefit for the system operator on the server.

What about replacing the GUI with web-based access to this information
(i.e. display the information as a web page in the administrator's
browser)?

Paul

 

[Dag Sunde]

Did you consider using an OSGi environment? The advantage is that you
can easily add servlets but you are not resticted by the servlet life
cycle model. Additionally, the service registry allows you to decouple
the different components so it does not become monolithic. Tomcat is
available as Http service, as are other web servers. Also for example
derby (Java SQL application) is available as bundle.

There are several open source implementations and the set of bundles is
growing rapidly at the moment. Apache is now also adopting OSGi for
several projects and have an incubator for an OSGi Framework called
Felix/Oscar. Take a look at

http://www.eclipse.org/osgi
http://www.knopflerfish.org
http://oscar.objectweb.org/
http://incubator.apache.org/projects/oscar.html (aka Felix)

The OSGi environment basically allows you access to all the services of
Tomcat but provides a very convenient life cycle management
environment. You can install/start/stop/update/uninstall applications
without ever having to restart the VM. Very convenient.

Never heard about this before.

I will dive into the links you posted, and try to absorb it... (Not an
easy task on a friday afternoon... ).

Thank you for the tip.

 

[Dag Sunde]

What about replacing the GUI with web-based access to this information
(i.e. display the information as a web page in the administrator's
browser)?

That is actually a good idea, and i have thought about it. Just use
java's logging facilities, and put a web-interface on the logs.

Problem is... Customers (and managers) are a conservative lot, and the
resistance is usually great when you suggest doing things different
then they were before...
(Especially when 'before' have been working without a hitch for years).

But... It is duly noted in my little book,and I will probably try
to get acceptance for it, to keep my options open.

Thanks...

 

[j-integra_support]

If you would rather reuse as much of your current ASP/COM
infrastructure as possible (thus cutting costs and timelines), then why
not use the J-Integra suite of products to connect your new Java apps
to your exisiting ASP/COM apps?

J-Integra for COM: Connect Java/J2EE to ASP/COM
J-Integra Espresso: Connect J2EE to Microsoft .NET

For free evaluations and multiple examples, goto
http://j-integra.intrinsyc.com/.

Shane Sauer
J-Integra Interoperability Solutions
http://j-integra.intrinsyc.com/
When Web Services are not enough

 

[Dag Sunde]

If you would rather reuse as much of your current ASP/COM
infrastructure as possible (thus cutting costs and timelines), then why
not use the J-Integra suite of products to connect your new Java apps
to your exisiting ASP/COM apps?

J-Integra for COM: Connect Java/J2EE to ASP/COM
J-Integra Espresso: Connect J2EE to Microsoft .NET

For free evaluations and multiple examples, goto
http://j-integra.intrinsyc.com/.

eh...
<quote>
...cross-platform solution where the owner
can choose where to run it (Windows/Linux/xxx).
</quote>

What I meant with cross-platform was that it should
be able to run on multiple platforms. That is for example
a single Linux server running Tomcat. With a Java/COM bridge
you will still need a windows machine to run the COM components...

But thanks for the input...