I think EJB 3.0 or beyond should address internet capability (web service
integration). Currently EJB clusters are restricted to LAN usage but the
internet service paradigm has amazing capability and is taking hold. I would
advocate in the same manner that MDB's were introduced, that there be
"internet beans" - these are EJB's that are web services themselves in a
sense and do communicate with other (remote) web services via XML
advertisement and discovery. This could offer some powerful capabilities and
a decent platform interface.
(Just my $.02)
>From: Peter Braswell <[EMAIL PROTECTED]>
>Reply-To: Peter Braswell <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: Design Question : XML descriptions & session beans (LONG)
>Date: Fri, 27 Jul 2001 15:39:51 GMT
>
>Jerome,
>IMHO, EJB's should never accept arguments that represent an XML document!
>The reasons are simple:
>- XML is fat and RMI serialzation does not help. The most popular method
>is for the EJB to accept a String or File as a parameter which represents
>the XML document. The number of bytes that are consumed goes up a zillion
>percent when marshalling data in this format as opposed to traditional RMI
>object serialization. Case in point: "<myInt>8</myInt>" to transport int
>value=8? Things get worse the larger your "Object" is...
>- XML parsing is intensive, especially DOM. The place to do this
>processing is NOT in an EJB container.
>- It's bad design semantics and bad OO, i.e. String returnDoc =
>myBean.doSomething(String xmlDoc); Says nothing about what doSomething does
>or the types of arguments it takes, DTD's help but the contract is really
>not clear...
>
>Better design: let your presentation layer handle the data stream (via
>servlets) and invoke EJB as needed. OR you can use SOAP that delegates
>invocations to EJBS. Don't pass XML to EJBS!!
>
></opinion>
>
>hope this helps,
>peter
>
>
>On Fri, 27 Jul 2001 09:39:06 +0200 [EMAIL PROTECTED] wrote:
> > Hi all EJB gurus,
> > sorry for any incovenience if my question seems stupid but I've got a
> > question dealing with design of my EJB (sessions):
> > I'd like to open my business services to as many apps as possible so I
> > think that getting views of my entities using XML descriptions could be
> > a great
> > way for this. SO I thought that session beans could expose such
> > services offering XML descriptions of underlying entities using ids or
> > names.
> > But the little confusing (for me) EJB specs tends to convince me that my
> > session bean should not handle IO streams.
> > Note:
> > One of my beans should provide a file (it is its only service, that 's
> > its job!!), is it a design fault ?
> > Transactions & concurrency are not a problem for this bean, is it
> > possible ? It seems that some containers could prevent me accessing to
> > local Filessytem.
> > All clues welcomed!!!
> >
> > Am I wrong . Has someone implemented such design ? For deployment
> > reasons I'd like to avoid using a servlet engine for such service....
> > I'd like to use Castor/XML Java/XML mapping tier for such job, in order
> > to avoid coding writeToXML() methods.
> >
> > All experience & feedback welcomed
> >
> > Cheers
> > Jerome
> > PS:
> > excsue me for my poor english written
> >
> >
>==========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
>body
> > of the message "signoff EJB-INTEREST". For general help, send
>email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
>
>
>Peter Braswell
>Utopian Software
>[EMAIL PROTECTED]
>757.560.8867
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
