COM Components in a J2EE World

Discussions

General J2EE: COM Components in a J2EE World

  1. COM Components in a J2EE World (4 messages)

    My company has moved forward with using the J2EE architecture on most of our development efforts. We do mostly B2B selling market research reports to customers. J2EE has worked very well for us so far. However, we are beginning to look at building some applications that require a high level of user interaction, validation and the like. As far as server-side architecture, we believe J2EE is definitely the answer for us because we have a multi-platform environment. It seems like building the client part of our applications as (D)HTML with JSPs though may not always be the answer. My main concern is that we will end up writing a lot of validation code in JavaScript or we will end up doing a lot of round tripping to our server to accomplish the same thing. I would like to consider other options that provide a more robust client architecture.

    The options I am currently looking at are as folows:

    1. COM components interacting with XML delivered data and maybe talking to servlets or something.

    2. Applets talking to Servlets.

    3. Java clients using WebStart.

    4. HTML Component architecture in IE 5.x and up.

    These are the only options I am aware of other than the standard HTML/JavaScript/JSP model.

    I know the COM/J2EE integration may sound taboo to a lot of you, but I believe COM provides a little more robust client component architecture that integrates well with both the web browser and the desktop environment. All our customers are required to use IE 5.x and up so we know their operating platform is Windows. And, I found the development to be much easier than my other options while at the same time proving a richer client experience than HTML/JavaScript/JSP. The challenge here would be integrating into our existing server architecture because we are not going to just suddenly get rid of WebLogic and a bunch of Sun servers.

    I would like to come up with an evaluation criteria for each of these options and then build an identical proof of concept with each option to make our final decision on what to use.

    Please tell about any experiecnes you have had in this area, especially in COM/J2EE integration because this is a very new area for me.

  2. Charles,

    what i understand is that u r not innterested in implementing a thin client interface (browser) for ur app, but client which either is a ActiveX/COM client or an applet hosted within the IE. at the server side u still want J2EE in the form of servlets/EJB.

    well its not a bad architecture as long as u know what u r doin and ur client are ok with idea of using only IE(ActiveX). also u can completely do away with the servlets here and let ur clients(COM/applet) communicate directly with EJB components(thats one option). EJB are a better option for implementing ur business logic considering the features an app server provides in handling the beans.

    but at the same time the good thing is that ur talkin bout XML based communication between ur client and servlets and the servlets then talking to EJB(thats another option). so if tomorrow u decide to implement a thin client interface(JSP/Servlet) for ur app u can re-use the servlets already written, depending how well u have designed n coded them. u might wanna keep this thing i mind.

    well all said n done i think thin clients are always a better option for server-side application. its gives u complete control of the app in terms on any update, changes n modifications. also depending on ur design u always have an option of porting ur app to other cient apart from the browser.

    unfortunately thats the only inputs i can give, i have no experience developing COM-J2EE(integrated) applications.

    hope this helps

    kapil
  3. Read about "CAS" the COM - EJB bride, recently introduced by Sun. This enables you to call EJB from COM developed in VB or VC++.
  4. Thanks for your input. I'll check it out on their web site.
  5. Thanks for your input. I'll take it into consideration.