[prev in list] [next in list] [prev in thread] [next in thread] 

List:       mirae-dev
Subject:    Re: JAX-RPC Architecture
From:       Damitha Kumarage <damitha_kumarage () yahoo ! com>
Date:       2005-07-22 6:20:20
Message-ID: 20050722062020.54631.qmail () web33905 ! mail ! mud ! yahoo ! com
[Download RAW message or body]

Hi,
On Wed, 2005-07-20 at 12:01 +0600, Thavarajah
Kurinchikumaran wrote:
> Hi all,
> 
> It is better to come to a decision regarding the
JAX-RPC module of
> Mirae. Here we can consider 2 types of architecture
for JAX-RPC module
> 
>         # Mirae's JAX-RPC at present
>                 This architecture supports both RPC
and Document styles.
> But serialization and deserialization is not carried
out completely by
> the JAX-RPC module and it is  done inside the param
classes also. It
> seems not good. And as we don't support "multiref"
it seems RPC is not a
> serious issue and we should consider about it and
come to an alternative
> solution. But this architecture results a better
memory consumption than
> other architectures when the SAX parser is replaced
by kxml pull parser
> and it can be enhanced more by StAX-ME.

Without supporting "multiref" telling that we support
RPC is
meaningless. So I agree with Ias(In a previous mail)
that supporting rpc
through document/wrap literal is ok.

You told that if Mirae's current JAX-RPC sax is
replaced with kxml pull
parser it gives better memory consumption. Can you
explain why this so
happen?. If it is good why don't we use kxml pull
thing?

> 
>         # Ias's JAX-RPC implementation which was
developed before the
> Mirae was committed (same to SUN's Implementation)
>                 It supports Document style only at
this moment and I am
> not sure whether it can be changed to support to RPC
style. As it has
> the serialization and deserialization logic inside
the JAX-RPC module it
> seems better than Mirae's current implementation.

But I think Mirae's current implementation with kxml
is a better option.
The problem with Ias's JAX-RPC thing is that it
accumulates a dom tree
while parsing which is memory intensive. Also it
creates a schmema type
object before parsing of the body starts which again
is memory
intensive.
But in current Mirae's implementation in memory
objects are created only
at the time of parsing of that element. That
capability is there because
it has serialization and serializatin logic in the
param classes it
self. I guess that's why it give good memory
consumption with kxml pull
parser.


> 
> Security & Header support
>         Mirae doesn't support any security issues
and SOAP header. If
> those things are implemented it will be useful to
have authentication in
> Mirae applications.

Shall we discuss a plan how to do this?

> 
> Regards
> Kurinchikumaran
> 
>

Damitha Kumarage
software Engineer
BeyondM software international(Pvt)Ltd 
Sri Lanka

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

[prev in list] [next in list] [prev in thread] [next in thread]