 | Mailing List | | Home | | Forum Home | | JBoss - Java Application Server | | Struts - A MVC web framework | | Tomcat - JSP/Servlet container | | iText - An open source PDF Java Library | | JDOM - JDOM XML Parser | | J2EE - A mailing list for Java(tm) 2 Platform, Enterprise Edition | | J2EE Pattern - An interest list for Sun Java Center J2EE Pattern Catalog | | Servlet - A mailing list for discussion about Sun Microsystem's Java Servlet API Technology | | JSP - A mailing list about Java Server Pages specification and reference | |
Struts & Hibernate
|
|
|
| | | Servicing non-HTTP Sockets in a J2EE environment | Servicing non-HTTP Sockets in a J2EE environment 2003-10-27 - By Chris Rowse
Back
Hi Andrea
Almost exactly one year on , I have exactly the same scenario. I need to
supply proprietary protocols into and out of my J2EE server on various TCP
server and client ports. (This is after all IMHO what middleware is about).
My problem comes from legacy (and not so legacy) services that are being
incrementally replaced by a J2EE framework. Many of these services are non
java based (short, medium and long term) , and I have no control over the
third party software that requires the service(s). This scenario will
continue as the business purchases third party software that wants to use
J2EE middleware .. NB MOM facilities.
Did you manage to solve your problem? If so how?
It seems to me that any self respecting application server would want to
listen on many TCP/IP ports for various reasons.
Both methods you propose seem to introduce far more complexity, and little
benefit over a simple service port that posts messages to a JMS queue. I
really dont feel like creating an artifact service outside my J2EE to provide
these services, with the attendant messy deployment and management issues
that I will have to provide manually.
Can anyone explain to me why J2EE doesnt support Server Sockets, perhaps if I
can understand the rationale, I can design round the limitation more
elegantly?
many thanks
Chris Rowse
On Wednesday 23 October 2002 03:37, you wrote:
> Dan,
> Thank you for your answer, yes, I am definitely planning to handle
> all the protocol dependent functions as early as possible and then transfer
> control to a protocol independent business delegate.
> If I understand you correctly, it is acceptable to handle non HTTP
> connections in the J2EE presentation tier. What is the recommended way to
> do that? Should I use a GenericServlet? Is there a better way? (my
> connections will come in on a specific port)
>
> Thanks
> Andrea
>
> -- --Original Message-- --
> From: An interest list for Sun Java Center J2EE Pattern Catalog
> [mailto:J2EEPATTERNS-INTEREST@(protected)]On Behalf Of Dan Malks
> Sent: Tuesday, October 22, 2002 2:59 PM
> To: J2EEPATTERNS-INTEREST@(protected)
> Subject: Re: Servicing non-HTTP Sockets in a J2EE environment
>
> Andreas,
> As you suggest, HTTP is the most common protocol for entry into a J2EE
> presentation tier, but a well designed presentation tier will be loosely
> coupled and will not propogate protocol information through all its
> interfaces and certainly not back across tiers.
>
> Thus, the listeners for the sockets you describe could be clients (along
> with a servlet controller) to the protocol independent classes that
> initiate the processing of your request. These protocol independent classes
> could be the command helpers to which the servlet and your socket
> listeners delegate to (if you give the command objects a protocol-neutral
> signature), but if not then the protocol independent classes would be your
> business delegates, which act as a channel into the business tier. The
> delegates will be a common choice in many apps for this purpose...in
> fact, this scenario is exactly one of the reasons we mention the benefits
> of the biz delegate as an early abstraction even though it seems to some
> people like "just one more layer"...of course, adding biz delegates via a
> refactoring later is not a huge problem typically either ;-)
>
> For more information on Business Delegate, check out:
> http://java.sun.com/blueprints/corej2eepatterns/Patterns/BusinessDelegate.h
>t ml
>
> Hope this helps.
> Dan
>
> Andrea Mazzario wrote:
> > Our J2EE application is unusual in the sense that in addition to
>
> supporting normal HTTP connections it must also support connections from
> devices that use TCP/IP, but not the HTTP protocol.
>
> > Is there a recommended pattern to handle this situation?
> > The EJBs are not supposed to accept socket connections, so these
>
> connections must be accepted outside of the business tier.
>
> > In theory, servlets should be able to support non-HTTP connections, but
>
> would that really work? Is the J2EE presentation tier really HTTP
> independent? Most of what I have read about it is really targeted towards
> HTTP, so I wonder if using it for non-HTTP connections would really work.
>
> > The other alternative would be to deploy a number of J2EE clients which
>
> would be listening to the non-HTTP connections and work as a proxy between
> these connections and the EJBs.
>
> > Has anybody a better recommendation?
> > Thanks in advance for your help!
> >
> > ===================================================================> >
Community Web Site (Core J2EE Patterns Catalog - Online Version):
> > http://java.sun.com/blueprints/corej2eepatterns
> > Getting Started (Beta Version):
> > http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
> > Get the book:
> > http://www.amazon.com/exec/obidos/ASIN/0130648841/corej2eepatte-20 (See http://tte-20.ora-code.com)
> > List Archive:
> > http://archives.java.sun.com/archives/j2eepatterns-interest.html
> > Unsubscribing:
> > email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
>
> ===================================================================>
Community Web Site (Core J2EE Patterns Catalog - Online Version):
> http://java.sun.com/blueprints/corej2eepatterns
> Getting Started (Beta Version):
> http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
> Get the book:
> http://www.amazon.com/exec/obidos/ASIN/0130648841/corej2eepatte-20 (See http://tte-20.ora-code.com)
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing:
> email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
>
> ===================================================================>
Community Web Site (Core J2EE Patterns Catalog - Online Version):
> http://java.sun.com/blueprints/corej2eepatterns
> Getting Started (Beta Version):
> http://developer.java.sun.com/developer/technicalArticles/J2EE/patterns/
> Get the book:
> http://www.amazon.com/exec/obidos/ASIN/0130648841/corej2eepatte-20 (See http://tte-20.ora-code.com)
> List Archive:
> http://archives.java.sun.com/archives/j2eepatterns-interest.html
> Unsubscribing:
> email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
===================================================================Companion
Site: http://www.corej2eepatterns.com
J2EE BluePrints: http://java.sun.com/blueprints/corej2eepatterns
List Archive: http://archives.java.sun.com/archives/j2eepatterns-interest.html
Unsubscribing: email "signoff J2EEPATTERNS-INTEREST" to listserv@(protected)
|
|
|
