Servlet-engine-to-servlet-engine passthrough (WebSphere Commerce to Tomcat)

[Alan Bates]

Hi all. I was able to complete the previous portion of my project (Apache to Tomcat communication)

The next step is to enable a servlet in WebSphere Commerce to communicate with an identical Servlet running in Tomcat. (They were both built from the same source)
I need WebSphere Commerce's RequestServlet to act as a pass-through between Tomcat and WCS's underlying resources. Apache will instruct WCS via HTTP Header and the RequestServlet will access underlying resources (JEE resources, database, etc, etc) and act as an HTTPProxyServlet to Tomcat, which will actually serve the request back to Apache from its own page.

(example goal)
For instance, a copy of foo.jsp resides in Tomcat as well as in WebSphere Commerce. foo.jsp makes a call to a DB table to retrieve "bar" Apache's virtual host makes a request for foo.jsp from WCS, but sets a flag in the HTTPHeader. WCS's RequestServlet is wrapped with a switch that will look for that Header flag. If it is not set, it operates as normal and when time comes to serve a page, it replies directly to the calling client. However, if the header is set (the header contains Tomcat's socket) WCS's RequestServlet will access its resources as normal, but when it comes time to serve a jsp back to the calling client, it will stop processing, delegate that task to Tomcat, and pass whatever information is necessary for Tomcat to be able to serve the page as if it were running locally to WCS....so basically, can I turn WCS's RequestServlet into a bridge between Tomcat and WCS's underlying resources?


I read a post from 2003 on theserverside that contained the following as a reply to a fairly similar question:

The most straightforward form of servlet-engine-to-servlet-engine communication is to have your first servlet invoke the remote servlet as an normal HTTP client, for example using the java.net.URL and java.net.URLConnection classes.

But that is as much information as I can find. Does anyone have any experience in this area? Does anybody have a Tomcat to WebSphere Commerce connector that they'd be willing to share? ...research material??

[Bear Bibeault]

HTTP is HTTP -- it doesn't matter what container is being used.

If you're going to do this sort of thing often, you may want to consider exposing the functionality as web services.

[Jimmy Clark]

Alan, as indicated, it seems like you are distracted by the brand names of the web servers. The quote that you posted clearly outlines the easiest way to implement communication between two servlets.

As to why you have two "identical" servlets running and want to use both of them is another design issue.

[Alan Bates]

Frank Bennett wrote:Alan, as indicated, it seems like you are distracted by the brand names of the web servers. The quote that you posted clearly outlines the easiest way to implement communication between two servlets.

As to why you have two "identical" servlets running and want to use both of them is another design issue.

(I also modified the language of my original post to clarify)
identical was the wrong word for me to use.

The end goal is this:
I want to be able to have a developer make changes to a JSP without having to run all of the bloat that is associated with WebSphere Commerce....along with the fact that I want to be able to keep all of the business logic secure. I rely on WCS for access to all of the JEE resources, but I'm trying to decouple the JSPs from that server. We still use WCS for our test, qa, and production servers, so heavy modification of resource invocation can't really be done (because we will eventually deploy to those servers)

I know I can get the HTTP Header down to WCS. I'm pretty sure I can get the header to pass back to Tomcat. The issue I'm trying to put into words and the crux of the matter is: I don't want the servlets to "call" one another. The communication cannot be through code, because I need WCS to think that Tomcat's Servlet IS the local servlet and use WCS' RequestServlet as a bridge between Tomcat's JSP and the underlying JEE resources encapsulated by WCS.

I can't have the local servlet invoke the remote servlet. The local servlet IS the remote servlet running in a separate servlet engine.

[Jimmy Clark]

It sounds like your Presentation-tier and Business-tier are tightly coupled and all jumbled together in a single server environment.

And it sounds like you want to move the Presentation-tier components, e.g. JSPs, to a different web server, possibly on a different node.

Now, you say you want trick Websphere Commerce Server into "thinking" that the Tomcat web server is it's own web server.

Even if you can manage to get this to work, it is an extremely questionable design and will introduce a nice chunk of associated risks.

A cleaner option would be to re-engineer the application so that the business logic code can be invoked remotely from any client, i.e. JSPs and servlets executing in Apache Tomcat web servers. Whether you can get IBM products to play nicely in this fashion is another discussion

Good luck!

[Alan Bates]

Frank Bennett wrote:It sounds like your Presentation-tier and Business-tier are tightly coupled and all jumbled together in a single server environment.
And it sounds like you want to move the Presentation-tier components, e.g. JSPs, to a different web server, possibly on a different node.
>Right, right, and right - but this abstraction is not currently intended for deployment purposes. This would be ONLY for development at the moment.

Now, you say you want trick Websphere Commerce Server into "thinking" that the Tomcat web server is it's own web server.
>That's the essential behavior I want, but really, I just want Websphere to act in "Controller" and "Model" capacity, but delegate off to Tomcat for "View"ing capacity and have Tomcat be able to understand the request from WCS as more than gibberish. I want WCS's RequestServlet to act as a secretary lol and I want Tomcat to be like "Oh, ok. You want me to serve up foo.jsp to x-forwarded-for. I can do that"
The "thinking" comment I made was merely my attempt to explain the problem

Even if you can manage to get this to work, it is an extremely questionable design and will introduce a nice chunk of associated risks.
>I'm not sure where those risks would be. This is for a new Development environment. It won't be mirrored in any other environment, let alone exposed to the outside world. Please elaborate. ...The only risk I can see arising would be having to maintain the switching of the WCS servlet from acting as a RequestServlet to an HTTPProxyServlet...but I was hoping that could be handled in configuration settings and maybe an HTTPProxyServlet adapter class that would only be deployed to the test server

A cleaner option would be to re-engineer the application so that the business logic code can be invoked remotely from any client, i.e. JSPs and servlets executing in Apache Tomcat web servers. Whether you can get IBM products to play nicely in this fashion is another discussion
>Yes, there are much cleaner options and I agree with those options as optimal. But, there's "optimal" and "I want to keep the job they just gave me" ...just trying to explain that yes I know these are tightly coupled, but I didn't couple them and I don't have an option to fully untangle the Christmas lights at the moment. It's a bit bass ackwards but I think they're in a wait and see mode on whether I can get this POC to work before they decide whether or not they're going to go on with a full-on refactor....which is what I want of course!! It'd mean stability for the foreseeable future for me

Good luck!
>I'll finish that thought - "You're gonna need it" lol

Yeah...the client is using WCS to host their entire MVC architecture. Models are EJBs. The RequestServlet is acting as the Controller and JSPs are the Views. I'm thinking someone got sold to by IBM a while back and the thing grew so large that they're looking for some relief from the bloat. This POC that I am working on is ONLY to set up a Development environment...but it might quite possibly result in a re-architecture, which would be most advantageous for me.

[Jimmy Clark]

In order to make this work, it looks like you need to be able to create your own RequestServlet instance and configure
and/or programatically get the WCS to use this instance instead of the WCS one. This will be tricky grasshopper
IBM support staff will most likely not help you with this type of effort.

Another thing to consider: A JSP file is much more than a static HTML page. You need to also consider the Servlet Container functionality
of the web server. Typically, in an MVC implementation, there is an intimate relationship between the Controller and the View. You are attempting
to disturb this relationship, use caution.

In regards to risks, security risks in particular, the communication between an external web server and a commerce server typically requires
strong security mechanisms. If this set-up is only intended for development, then your development environment is going to be very different
than production, QA, testing, etc. There is a risk associated with this as well in terms of possible redundant development efforts, wasted testing
cycles, etc. Ideally, your development environment should resemble production as much as possible. This type of trickery is going in the wrong direction...
Are you going to magically disable all of the security mechanisms of the application for this new development environment?

Whole things smells like a "shot-in-the-dark" solution created by a non-technical manager trying to compensate for a poorly designed system.

Your job is to implement this, rather than convince them that there are much better strategic solutions that will work and be more
efficient in the long run. Ah, just thinking about it has given me a headache ...

Re-read first paragraph above for hint

[Alan Bates]

...that response was right up the alley with what I was looking for. I was kind of figuring that the answer to this question was going to be something along the lines of "Not technically possible because of {x}", "Sure! use {y} technique", or "never done it, but {z} might get you started down the path"

Frank Bennett wrote:In order to make this work, it looks like you need to be able to create your own RequestServlet instance and configure
and/or programatically get the WCS to use this instance instead of the WCS one. This will be tricky grasshopper
IBM support staff will most likely not help you with this type of effort.
>(first part) yeah...that's the trick (at least I FINALLY feel like someone out there has an understanding of what we're trying to accomplish, without regard to whether it is misguided or not....most of the replies to my posts have been academic in nature "You shouldn't do that" or "refactor refactor refactor" ...and those people obviously are independently wealthy, have their own company and make all strategic decisions for their organization lol)
>lol...we know that IBM won't help with this. IBM is a soulless, capitalistic parasite (oh...wait....I guess WE'RE soulless, capitalistic parasites too then...touché IBM...touché)


Another thing to consider: A JSP file is much more than a static HTML page. You need to also consider the Servlet Container functionality
of the web server. Typically, in an MVC implementation, there is an intimate relationship between the Controller and the View. You are attempting
to disturb this relationship, use caution.
>I believe this is spot on. It could get really messy in there...I had a short conversation with a buddy of mine and his suggestion was an RMI or CORBA solution but those are terms you read about in history class...no practical experience with that here

In regards to risks, security risks in particular, the communication between an external web server and a commerce server typically requires
strong security mechanisms. If this set-up is only intended for development, then your development environment is going to be very different
than production, QA, testing, etc. There is a risk associated with this as well in terms of possible redundant development efforts, wasted testing
cycles, etc. Ideally, your development environment should resemble production as much as possible. This type of trickery is going in the wrong direction...
Are you going to magically disable all of the security mechanisms of the application for this new development environment?
>agreed. That's why this concept is possibly off the mark. What you stated IS our goal, and to that end this concept has been devised....but we're concerned that it isn't technically possible to accomplish these tasks and meet that goal. I was thinking if we could somehow rip the WCS servlet apart to the point that it acted to service Requests but only acted as a proxy for Responses, we *might* have a shot at wiring something up. The major technical issue that I see that raised an immediate red flag is how to jump the session information from WCS to Tomcat (or Glassfish, etc, etc) and somehow provide a mapping in the "new" Servlet engine

Whole things smells like a "shot-in-the-dark" solution created by a non-technical manager trying to compensate for a poorly designed system.
>It is a shot-in-the-dark, but it's the only shot that I could see that might fit the bill for what they wanted. I knew it would be a hack job, if it could be done in the first place

Your job is to implement this, rather than convince them that there are much better strategic solutions that will work and be more
efficient in the long run. Ah, just thinking about it has given me a headache ...
>yes and no. At first glance, it's obvious that there are better strategic solutions than my proposal - but they would be more in line with long-term strategic decisions: Better workflow management, segregation of application layers, etc, etc, etc...The thing is that if I could get something like this to work, I would save the company quite a bit of money...nearly 7 figures in the department's annual budget goes to cover the seat licenses for RAD for developers who never need to use it for anything other than stupid simple jsp alterations like modifying jstl hooks.....and the RAD Eclipse plug-in locks us into a very specific implementation of Eclipse, which IBM never updates. The whole thing is a headache, but it's been in place for a long time. I'm sure that at the point that the decision was made to go with this architecture, it was a very slick solution. It's just that everyone has been in "today" mode rather than "tomorrow" mode and it finally got to the point where the size and complexity of the ecomm site has become way too cumbersome and expensive to continue this architecture long-term. They kind of asked me to step in (I'm cheap lol) and TRY to come up with a solution that could be a stop-gap while the directors have their committee meetings and budgetary meetings and we can come up with cost justification for funding to refactor the whole thing. But for some reason, (and I'll NEVER understand it) ..business people tend not to consider total cost of ownership of a solution...they just look for how costs are going to hit this year's budget.

Re-read first paragraph above for hint

[Jimmy Clark]

In order to make this work, it looks like you need to be able to create your own RequestServlet instance and configure
and/or programatically get the WCS to use this instance instead of the WCS one.

Alternatively, you possibly could do this using a second web application deployed in WCS. Instead of attempting to to code the "product" application to
go outside WCS, code it to communicate with this second (proxy) web application within the WCS environment. Then code this web application to
commuicate with the Tomcat-based GUI. You still have the challenge of getting out of the WCS, but it may be easier to do this with an application instead of a single object.


WCS ---------> WCS PROXY WEB APP |--------> TOMCAT WEB APP


TOMCAT WEB APP ------>| PROXY WEB APP --------> WCS