Fast Web Services / Fast Infoset / Fast Schema [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API to modify the soap header/body content

[Aleksander Slominski <as...@cs.indiana.edu>]

Davanum Srinivas wrote:

>have u reviewed this? -
>http://java.sun.com/developer/technicalArticles/WebServices/fastWS/
>  
>
i think it is interesting approach to doing _binary_ XML but requires 
both sides to talk Fast Web Services but generally will not work with 
"slow" Web Services unless client knows WSDL endpoint (that would be the 
case for WSIF) or there is some dynamic metadata discovery protocol to 
identify that endpoint supports FWS.

there is clearly a tradeoff between performance of binary encoding and 
flexibility/readability of text protocols and that may be become even 
more of issue when doc/literal message exchange dominates use of XML - i 
think that  there is really no point of converting complex XML schema 
that has lot of extensibility points (and xsd:any) to ASN.1 (even if it 
was possible) ...

still the most important factor to consider is network latency - when 
you deploy service on Internet the bottleneck is network and not how 
fast you can process messages (you can always do load balancing and 
throw more and always cheaper hardware) so using FWS will just mean less 
hardware. moreover self-describing XML is clearly an advantage when you 
try to create complex Internet scale distributed application (so that 
may pay all extra hardware as debugging/maintenance time is lower).

however FWS (and any other binary protocol) has a definite advantage as 
an optimized alternative to XML when used in *controlled* environment 
such as inside enterprise, mobile computing for very constrained devices 
(but here one should look on WS vs XHTML lesson) and even on Internet 
when there is a need to transfer large amounts of data but even in this 
case MTOM may be the winner as it keeps binary data integrated in XML 
infoset and will not require any special FWS-enabled wsdl2java 
stub/skeleton generator ....

interesting problem would be to build XML infoset API that would work 
both for XML 1.0/1.1 serialization, supports binary data (MTOM), allows 
partial in-memory materialization *and* can be (de)serialized to FWS ....

just dumped my thoughts - they may change when i actually see working 
FWS prototype (can it be downloaded from somewhere? 
https://jwsdp.dev.java.net/fast/ asks to "Stayed tuned ...")  :)

alek

>On Sun, 06 Jun 2004 22:24:05 -0500, Aleksander Slominski
><as...@cs.indiana.edu> wrote:
>  
>
>>Ias wrote:
>>
>>    
>>
>>>Hi Thomas,
>>>
>>>Thanks for your pointing the issues out. As a contributor of the SAAJ 1.2
>>>implementation in Axis (with Dr. Ahn), I have to admit that he and I already
>>>made our own (refactored) Axis satisfy #1 and #2. He created DOM recorder
>>>for #1 and I refactored the whole org.apache.axis.message package for #2. As
>>>for #2, org.apache.axis.message.Node was created and
>>>org.apache.axis.message.MessageElement and org.apache.axis.message.Text
>>>extended it.
>>>
>>>However, those changes are quite big and wide, so we need to modify Axis a
>>>lot. Now we are in the middle of finalizing Axis 1.2, I don't think such
>>>large changes will happen to this upcoming version of Axis. Personally, I
>>>often have felt that contributing #1 and #2 to the current Axis base seems
>>>pretty difficult and consider re-structuring the SAAJ part with Axis NG
>>>(Next Generation).
>>>
>>>What I'm designing regarding Axis NG is a complete implementation of JAX-RPC
>>>2.0 and Web Services Metadata for high performance with StAX (streaming
>>>parser). I'm planning to open my thoughts on that as soon as JAX-RPC 2.0 and
>>>JAXB 2.0 early drafts are unveiled around JavaOne 2004. Briefly, I'd like
>>>Axis NG to use StAX when deserializing/serializing between SOAP messages and
>>>SAAJ instances.
>>>
>>>      
>>>
>>how will this help avoid the trap of SAX event recording i.e. how it
>>makes any difference if you record SAX or StAX events?!
>>
>>i have pondered this problem and decided that trying to make two things
>>(streaming and DOM-like Infoset) fit into one hole is *the problem*.
>>
>>so my current thinking is that the optimal solution is a super
>>lightweight XML infoset in-memory representation that can be partially
>>materialized or de-materialized (stored in file, stream on-demand
>>parsing backed).
>>
>>to make this happen it is handy to allow to store non XML content in XML
>>infoset tree that is only XML-ized when message is about to be sent
>>(such as pointer to file so really huge files can be sent as BASE64, as
>>attachments, or MOTM or whatever it is called). when receiving message
>>goes through multiple processors in pipeline and is gradually converted
>>from XML to whatever Java representation one needs (such as pointer to
>>file backed representation).
>>
>>this approach tries to avoid converting between multiple XML
>>representation, caching them and trying to keep them consistent (huge
>>memory inflation to keep all message representations or CPU overhead to
>>recompute them on demand which is even worse as XML is CPU bound) and
>>that i think is the root of all current problem ...
>>
>>best,
>>
>>alek
>>
>>--
>>The best way to predict the future is to invent it - Alan Kay
>>
>>
>>    
>>


-- 
The best way to predict the future is to invent it - Alan Kay

Re: Fast Web Services / Fast Infoset / Fast Schema [Re: opinion Axis' future ... [Re: Using SAAJ-1.2 API to modify the soap header/body content

[Sanjiva Weerawarana <sa...@opensource.lk>]

What surprised me was that FWS was only producing like 10X max over
a pure JAXRPC impl. IMO that's not a good enough benefit .. AxisMora
comes close to that against Axis/Java with a typed pull parser (yours
+ extensions ;-)) and a different internal architecture.

> interesting problem would be to build XML infoset API that would work
> both for XML 1.0/1.1 serialization, supports binary data (MTOM), allows
> partial in-memory materialization *and* can be (de)serialized to FWS ....

+1 for this. The JROM project we (my group in IBM) did a while back
(and release via alphaWorks) was an attempt at a pure Infoset model
with PSVI info too. IBM has a new thing called SDO (which is an open
source project at eclipse.org I believe) which has now replaced that
but its a bit more complicated unfortunately as the scope is much
broader. I haven't looked at the beehive stuff yet but it seems that
BEA must have something along these lines there too (something beyond
XMLBeans I mean).

Sanjiva.

----- Original Message ----- 
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Monday, June 07, 2004 9:45 PM
Subject: Fast Web Services / Fast Infoset / Fast Schema [Re: opinion Axis'
future ... [Re: Using SAAJ-1.2 API to modify the soap header/body content


> Davanum Srinivas wrote:
>
> >have u reviewed this? -
> >http://java.sun.com/developer/technicalArticles/WebServices/fastWS/
> >
> >
> i think it is interesting approach to doing _binary_ XML but requires
> both sides to talk Fast Web Services but generally will not work with
> "slow" Web Services unless client knows WSDL endpoint (that would be the
> case for WSIF) or there is some dynamic metadata discovery protocol to
> identify that endpoint supports FWS.
>
> there is clearly a tradeoff between performance of binary encoding and
> flexibility/readability of text protocols and that may be become even
> more of issue when doc/literal message exchange dominates use of XML - i
> think that  there is really no point of converting complex XML schema
> that has lot of extensibility points (and xsd:any) to ASN.1 (even if it
> was possible) ...
>
> still the most important factor to consider is network latency - when
> you deploy service on Internet the bottleneck is network and not how
> fast you can process messages (you can always do load balancing and
> throw more and always cheaper hardware) so using FWS will just mean less
> hardware. moreover self-describing XML is clearly an advantage when you
> try to create complex Internet scale distributed application (so that
> may pay all extra hardware as debugging/maintenance time is lower).
>
> > however FWS (and any other binary protocol) has a definite advantage as
> an optimized alternative to XML when used in *controlled* environment
> such as inside enterprise, mobile computing for very constrained devices
> (but here one should look on WS vs XHTML lesson) and even on Internet
> when there is a need to transfer large amounts of data but even in this
> case MTOM may be the winner as it keeps binary data integrated in XML
> infoset and will not require any special FWS-enabled wsdl2java
> stub/skeleton generator ....

> interesting problem would be to build XML infoset API that would work
> both for XML 1.0/1.1 serialization, supports binary data (MTOM), allows
> partial in-memory materialization *and* can be (de)serialized to FWS ....
>
> just dumped my thoughts - they may change when i actually see working
> FWS prototype (can it be downloaded from somewhere?
> https://jwsdp.dev.java.net/fast/ asks to "Stayed tuned ...")  :)
>
> alek
>
> >On Sun, 06 Jun 2004 22:24:05 -0500, Aleksander Slominski
> ><as...@cs.indiana.edu> wrote:
> >
> >
> >>Ias wrote:
> >>
> >>
> >>
> >>>Hi Thomas,
> >>>
> >>>Thanks for your pointing the issues out. As a contributor of the SAAJ
1.2
> >>>implementation in Axis (with Dr. Ahn), I have to admit that he and I
already
> >>>made our own (refactored) Axis satisfy #1 and #2. He created DOM
recorder
> >>>for #1 and I refactored the whole org.apache.axis.message package for
#2. As
> >>>for #2, org.apache.axis.message.Node was created and
> >>>org.apache.axis.message.MessageElement and org.apache.axis.message.Text
> >>>extended it.
> >>>
> >>>However, those changes are quite big and wide, so we need to modify
Axis a
> >>>lot. Now we are in the middle of finalizing Axis 1.2, I don't think
such
> >>>large changes will happen to this upcoming version of Axis. Personally,
I
> >>>often have felt that contributing #1 and #2 to the current Axis base
seems
> >>>pretty difficult and consider re-structuring the SAAJ part with Axis NG
> >>>(Next Generation).
> >>>
> >>>What I'm designing regarding Axis NG is a complete implementation of
JAX-RPC
> >>>2.0 and Web Services Metadata for high performance with StAX (streaming
> >>>parser). I'm planning to open my thoughts on that as soon as JAX-RPC
2.0 and
> >>>JAXB 2.0 early drafts are unveiled around JavaOne 2004. Briefly, I'd
like
> >>>Axis NG to use StAX when deserializing/serializing between SOAP
messages and
> >>>SAAJ instances.
> >>>
> >>>
> >>>
> >>how will this help avoid the trap of SAX event recording i.e. how it
> >>makes any difference if you record SAX or StAX events?!
> >>
> >>i have pondered this problem and decided that trying to make two things
> >>(streaming and DOM-like Infoset) fit into one hole is *the problem*.
> >>
> >>so my current thinking is that the optimal solution is a super
> >>lightweight XML infoset in-memory representation that can be partially
> >>materialized or de-materialized (stored in file, stream on-demand
> >>parsing backed).
> >>
> >>to make this happen it is handy to allow to store non XML content in XML
> >>infoset tree that is only XML-ized when message is about to be sent
> >>(such as pointer to file so really huge files can be sent as BASE64, as
> >>attachments, or MOTM or whatever it is called). when receiving message
> >>goes through multiple processors in pipeline and is gradually converted
> >>from XML to whatever Java representation one needs (such as pointer to
> >>file backed representation).
> >>
> >>this approach tries to avoid converting between multiple XML
> >>representation, caching them and trying to keep them consistent (huge
> >>memory inflation to keep all message representations or CPU overhead to
> >>recompute them on demand which is even worse as XML is CPU bound) and
> >>that i think is the root of all current problem ...
> >>
> >>best,
> >>
> >>alek
> >>
> >>--
> >>The best way to predict the future is to invent it - Alan Kay
> >>
> >>
> >>
> >>
>
>
> -- 
> The best way to predict the future is to invent it - Alan Kay
>
>