----- Original Message -----
From: "John Harby" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 27, 2001 9:27 PM
Subject: Re: Design Question : XML descriptions & session beans (LONG)
> Currently EJB clusters are restricted to LAN usage
Isnt' this a limitation of a particular implementation ? Or are you saying
people prefer using it that way ?
>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".
===========================================================================
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".
