No subject

the entire EJB object model with Webservices just to access it from inside
the intranet from the JSP presentation layer ?

In our case we installed one single facade which encapsulated more or less
the entire business logic of the app (using other EJBs) and exposed this
facade thru SOAP. But if you have to do this for a couple of EJBs it becomes
really expensive if you have to manually write the SOAP interfaces. (If this
is what you intend to do you should check out the following link for a site
that offers a tool for the automatic generation of SOAP interfaces based on
ordinary Java interfaces: http://www.idoox.com/ )

For me the question remains if it is worthwhile to connect single EJB
instances of the EJB layer by using webservices from an intranet or if SOAP
webservices should rather be used from the Internet because of their
protocol overhead?

~Patrick

----- Original Message -----
From: "Alex Ross" <aross at rightsline.com>
To: <opensource at javacorporate.com>
Sent: Tuesday, December 04, 2001 9:19 AM
Subject: RE: [Opensource] Expresso/J2EE


> Our company has had similar thoughts but we're going to try a standard EJB
> business object layer exposed through Web Services to a Struts MVC layer
(or
> possible any other frontend). We're going to start prototyping as soon as
> possible.
>
> Anybody else have thoughts on this?
>
> Alex
>
> -----Original Message-----
> From: opensource-admin at javacorporate.com
> [mailto:opensource-admin at javacorporate.com]On Behalf Of
> scott_d_mccrory at bankone.com
> Sent: Tuesday, December 04, 2001 6:07 AM
> To: opensource at javacorporate.com
> Subject: RE: [Opensource] Expresso/J2EE
>
>
>
> I'd also like to chime in that some developers (particularly those I work
> with) are skeptical about the long-term wisdom of EJBs.  To me, it somes
> down to EJB/RMI, which is a relatively proprietary technology, at least
for
> now requiring Java on both ends of the service, versus a Web Services
> approach.  The biggest concern that I and my co-workers have is that if
> we're going to put a lot of work into creating common services, then why
> not make them Web Services and expose them to the whole (multiplatform)
> company instead of forcing the use of Java.  We never know what management
> will ask of us in the future, and being tied to a Java-only technology
> (we've also discovered that RMI can have significant performance and
> interoperability issues) wouldn't put us in a very good position.  I won't
> pretend that we have a fully formed strategy yet, but I suspect that the
> developer community, and indeed Sun, will want to challenge the merits of
> EJB, even in enterprise applications.
>      Scott
>
>
>
>
> This transmission may contain information that is privileged, confidential
> and/or exempt from disclosure under applicable law. If you are not the
> intended recipient, you are hereby notified that any disclosure, copying,
> distribution, or use of the information contained herein (including any
> reliance thereon) is STRICTLY PROHIBITED. If you received this
transmission
> in error, please immediately contact the sender and destroy the material
in
> its entirety, whether in electronic or hard copy format. Thank you.
>
>
>
> _______________________________________________
> Opensource mailing list
> Opensource at javacorporate.com
> http://www.javacorporate.com/mailman/listinfo/opensource
>
>
>
> _______________________________________________
> Opensource mailing list
> Opensource at javacorporate.com
> http://www.javacorporate.com/mailman/listinfo/opensource