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".
