Discussions

General J2EE: Rich clients/.net front end J2EE Backend

Bookmark and Share Get thread feed

  1. Rich clients/.net front end J2EE Backend (4 messages)

    • Posted by: Ryan Pape
    • Posted on: December 15 2003 22:09 EST
    Interesting article I stumbled upon at
    http://msdn.microsoft.com/netframework/using/building/windows/analystreports/richclient.aspx

    with such notables as
    "Consider using a Windows Forms .NET rich client in conjunction with a Java/J2EE back end when a native Windows look and feel or tight integration with desktop productivity applications is a requirement. "

    Which may not be a bad idea. Does anyone have any practical experience doing this? What about the Java Desktop Network Components (JDNC )..are they a viable alternative yet?

    I have a real application that needs to be hit with both a web application (JSP/Servlet/), a remote application (web services?), and a third enterprise application that could potentialy exist solely as web application or as a rich client.

    What kind of experiences are people having with real world "rich" clients talking to a J2EE backend (Java or otherwise)?
    Reply to this

    Threaded Messages (4)

  2. RIA, Flash Remoting, OpenAMF[ Go to top ]

    Macromedia has been a strong advocate of "Rich Internet Applications"

    http://www.macromedia.com/resources/business/rich_internet_apps/

    http://www.macromedia.com/resources/business/rich_internet_apps/examples/

    With Macromedia's Flash Remoting technology, you can build a Flash application that communicates with J2EE or .NET

    http://www.macromedia.com/software/flashremoting/

    I've been participating in an open source project called OpenAMF. OpenAMF is a free alternative to Macromedia's Flash Remoting Gateway.

    http://www.openamf.org/

    See also:

    http://www.theserverside.com/home/thread.jsp?thread_id=19255

    http://www.theserverside.com/home/thread.jsp?thread_id=18661
    Reply to this Reply to original

  3. Flash Remoting--time to glue it all together[ Go to top ]

    It seems that the technologies and strategies for creating the rich client app continue to become more sophisiticated and faster to develop with.

    The concern I have is that the time it takes to write the "glue" to connect the rich app to the backend is disproprotionately time consuming and tedeious.

    Does anyone have first hand experience doing this by interfacing with session beans?

    I certainly see areas where flash remoting and other rich client technologies are clear winners. The area I am most unclear about is somewhere between a deploy-anywhere RIA and an app primarily design to run in the corporate environment that could make native calls to the J2EE server. I suppose if remoting was easy enough, one could always use it as the application in question will often end up running somewhere where it was not originaly intended.
    Reply to this Reply to original

  4. Flash Remoting-- or WEB Services ?[ Go to top ]

    The concern I have is that the time it takes to write the "glue" to connect >the rich app to the backend is disproprotionately time consuming and tedeious.


    If you use WEB services or CORBA you dont have to write the "glue".
    From my experience WS implementation takes less time than CORBA.
    But performance could be an issue with WS.
     
    > Does anyone have first hand experience doing this by interfacing with session >beans?

    I even have some examples on WEB (C++ AND C sharp rich clients):

    Enterprise JavaBeans interoperability examples

    I also have integrated a J2EE system with an existing application written in Delphi. I used WEB services... and I had no problems.
    Reply to this Reply to original

  5. development speed/ease[ Go to top ]

    That is a very interesting example using the various client technologies.


    From a developer's perspective, which one do you prefer and why? What was the relative speed comparison of the web service/corba/native ejb (both development and runtime)?
    Reply to this Reply to original