You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-dev@axis.apache.org by Aleksander Slominski <as...@cs.indiana.edu> on 2004/11/13 06:46:21 UTC
[Axis2] AXIOM goals
i think i am lost in recent developments of AXIOM and what i its goals.
i am very interested to hear if this list needs modifications and what
if the order of items reflect their priority
here is my understanding/interpretation:
* AXIOM API has no dependencies on other modules in AXIS2
* AXIOM API have dependencies on DOM, SAX, StAX, XmlPull
* AXIOM API allows to construct OM representing XML Infoset from input
* AXIOM API allows to write OM as XML Infoset to output
* AXIOM API can have multiple implementations with different performance
characteristics and optimizations
* AXIOM API provides subset of XML Infoset that is deemed needed for SOAP
* AXIOM API allows manipulation of XML infoset (adding elements,
removing etc)
* AXIOM API allows to access SOAP:Body directly as event stream and
avoid building of XML tree for it
* AXIOM API allows to supports DOM L2 (L3?) as an addon for cases when
security is used [for example WSS4J implementation XML Security requires
DOM as it uses libs requiring DOM]; when not DOM is not required then
AXIOM can be used without DOM APIs to achieve better performance and
lower memory footprint [configurable feature requested when OM is created]
* AXIOM API supports MTOM with a consistent XML Infoset view (MTOM
content looks like BASE64), allows direct optimized access to binary
data, and allows to store references to binary data that is serialized
according to MTOM/XOP rules (BASE64 if no attachments)
* AXIOM API is designed to support pluggable XML transformations
(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
* AXIOM API makes possible to store Java objects convertible to XML
Infoset on demand [for serialization]
* AXIOM API allows other APIs to be built on top of it including SAAJ
* AXIOM API is easy to use and follow common XML APIs patterns (like
JDOM, XOM) but has also if SOAP specific features if needed
* AXIOM API makes possible to create implementations with good or very
good performance and used general XML benchmarks (like Sosnoski) and WS
specific benchmarks developed based on use cases to estimate performance
and guard against regressions
* AXIOM API is designed to minimize memory footprint, allows streaming
and avoids creating wrapper objects if not needed
* [optional] AXIOM impl that has MTOM binary data streamed in/out of
external storage to avoid OutOfMemory exceptions for very large content
* [optional] AXIOM impl that uses XBIS <http://xbis.sourceforge.net/>
for optimized transport of XML Infoset, especially useful for low memory
footprint and better performance between two WS nodes that uses XBIS
* [optional] AXIOM impl that uses XBIS (or similar) to store XML events
for replay from memory (or file? db?),
alek
--
The best way to predict the future is to invent it - Alan Kay
AXIOM and DOM [Re: [Axis2] AXIOM goals
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>* AXIOM API allows to supports DOM L2 (L3?) as an addon for cases when
>>security is used [for example WSS4J implementation XML Security requires
>>DOM as it uses libs requiring DOM]; when not DOM is not required then
>>AXIOM can be used without DOM APIs to achieve better performance and
>>lower memory footprint [configurable feature requested when OM is created]
>>
>>
>
>No. DOM support is a layer on top of AXIOM, not built into AXIOM.
>
>
that is what i meant by saying that DOM support is "addon".
>Building the DOM impl is not a requirement to complete AXIOM. However,
>we will have to build it when plugging in the WSS4J code for sure and
>at that time it may be decided that it makes sense to keep that impl
>near/in AXIOM makes sense. Right now I'm -1 to saying the DOM impl is
>part of AXIOM because its not needed for Axis2 to complete.
>
>
i changed wording to indicate we should just make _possible_ to build
DOM on top of AXIOM so AXIOM API has nothing preventing doing this and
if possible makes it easier to build DOM impl on top of AXIOM?
how does this sound?
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
AXIOM and Java, WS-RM, XBIS [Re: [Axis2] AXIOM goals
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>
>>* AXIOM API makes possible to store Java objects convertible to XML
>>Infoset on demand [for serialization]
>>
>>
>
>+1 .. but that's just a different builder for AXIOM - starts with a
>Java object instead of a stream. We'll need a builder from DOM too
>in the future.
>
>
i am not sure how XML Infoset API (which is AXIOM API) should work on
top of AXIOM built from Java objects?for example what is namespace
property of java object?
i think this point needs much more clarifications. i was thinking that
ability to store Java objects directly as parts of AXIOM is good for
storing references to binary data, doing partial data binding (like one
header transformed with data binding and stored into tree) and similar
operations.
>
>>* AXIOM API is easy to use and follow common XML APIs patterns (like
>>JDOM, XOM) but has also if SOAP specific features if needed
>>
>>
>
>What's XOM? +1 for JDOM-like convenience.
>
>
another DOM-like API this one under LGPL and redesigned to be easy to
use: http://www.cafeconleche.org/XOM/
>>* AXIOM API is designed to minimize memory footprint, allows streaming
>>and avoids creating wrapper objects if not needed
>>
>>
>
>API enables different implementations - some which optimize memory,
>some which optimize for speed. Sometimes these two objectives cannot
>be met at the same time obviously.
>
>
of course but API *should* not require anything that is leading to slow
implementations or huge memory usage - of course it is hard to achieve
good balance in API so it allows different kind of impls
>
>>* [optional] AXIOM impl that uses XBIS <http://xbis.sourceforge.net/>
>>for optimized transport of XML Infoset, especially useful for low memory
>>footprint and better performance between two WS nodes that uses XBIS
>>
>>
>
>+1 but not only XBIS- there are several candidates available for
>alternate serializations and I'm very interested in enabling these.
>Hence my rabid focus on using tStAX for all input and output.
>
>
i think it can be good choice if we see good speedups when using it
between binary XML Infoset enabled WS nodes (XBIS)
>
>
>>* [optional] AXIOM impl that uses XBIS (or similar) to store XML events
>>for replay from memory (or file? db?),
>>
>>
>
>Not optional .. have to be able to serialize the entire message from
>day one. Sandesha cannot work fully without this capability.
>
>
i looked on it for handling together with attachments but i agree there
is a separate case for WS-RM persistent message storage.
alek
--
The best way to predict the future is to invent it - Alan Kay
RE: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Glen Daniels <gl...@thoughtcraft.com>.
+1
> -----Original Message-----
> From: Davanum Srinivas [mailto:davanum@gmail.com]
> Sent: Tuesday, November 16, 2004 7:01 AM
> To: axis-dev@ws.apache.org
> Subject: Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
>
> yes, please stay here.
>
>
> On Tue, 16 Nov 2004 17:11:03 +0600, Sanjiva Weerawarana
> <sa...@opensource.lk> wrote:
> > I think we should stay on axis-dev .. even folks who are
> not actively
> > participating are "lurking" because of that. Also, once
> Axis 1.2 ships
> > the focus can change quite a bit ..
> >
> > Sanjiva.
> >
> >
> >
> > ----- Original Message -----
> > From: "Aleksander Slominski" <as...@cs.indiana.edu>
> > To: <ax...@ws.apache.org>
> > Sent: Tuesday, November 16, 2004 8:06 AM
> > Subject: Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
> >
> > > Sanjiva Weerawarana wrote:
> > >
> > > >Dude, prefix your messages with [Axis2] ;-).
> > > >
> > > >
> > > for my filter it is enough if axis2 is in subject as it
> is common that
> > > when you reply you get "Re: [Axis2] ..." so otherwise i
> would miss all
> > > replies ;-)
> > >
> > > anyway i think we may need a separate mailing list ...
> > >
> > > alek
> > >
> > > >----- Original Message -----
> > > >From: "Aleksander Slominski" <as...@cs.indiana.edu>
> > > >To: <ax...@ws.apache.org>
> > > >Sent: Monday, November 15, 2004 11:10 PM
> > > >Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
> > > >
> > > >
> > > >
> > > >
> > > >>Sanjiva Weerawarana wrote:
> > > >>
> > > >>
> > > >>
> > > >>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>* AXIOM API is designed to support pluggable XML
> transformations
> > > >>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor,
> XmlBeans, RelaxNG, ...)
> > > >>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>I can't read AXIS-1498 right now (offline ATM) but
> data binding is NOT
> > > >>>part of AXIOM.
> > > >>>
> > > >>>
> > > >>>
> > > >>what i mean by it is "designed to support" is that
> doing data binding
> > > >>should be make easier by making AXIOM API works well
> with any data
> > > >>binding framework.
> > > >>
> > > >>
> > > >>
> > > >>>In fact data binding is layered into the engine so that
> > > >>>all of Axis2 can run without any data binding and with the app
> > accessing
> > > >>>the OM directly (maybe via something like JXPath layered on).
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>yes so AXIOM API must be designed (or changed when
> needed) so to support
> > > >>such access.
> > > >>
> > > >>
> > > >>
> > > >>>The point is that providers which have Java
> object-ified views of
> > > >>>the incoming XML blob is not the only way to implement
> a service. For
> > > >>>example, the service may be one or more XSLT scripts.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>yes - i think it would be very good for doc/literal
> kind of services and
> > > >>AXIOM should make it easy and not hard to implement
> such service.
> > > >>
> > > >>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
> > >
> > >
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Srinath Perera <he...@gmail.com>.
yap +1 I feel we should be in axis dev list , we need the lessons from
axis 1.x and want the people to remind if we missing them :)
Thanks
Srinath
On Tue, 16 Nov 2004 07:01:22 -0500, Davanum Srinivas <da...@gmail.com> wrote:
> yes, please stay here.
>
> On Tue, 16 Nov 2004 17:11:03 +0600, Sanjiva Weerawarana
>
>
> <sa...@opensource.lk> wrote:
> > I think we should stay on axis-dev .. even folks who are not actively
> > participating are "lurking" because of that. Also, once Axis 1.2 ships
> > the focus can change quite a bit ..
> >
> > Sanjiva.
> >
> >
> >
> > ----- Original Message -----
> > From: "Aleksander Slominski" <as...@cs.indiana.edu>
> > To: <ax...@ws.apache.org>
> > Sent: Tuesday, November 16, 2004 8:06 AM
> > Subject: Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
> >
> > > Sanjiva Weerawarana wrote:
> > >
> > > >Dude, prefix your messages with [Axis2] ;-).
> > > >
> > > >
> > > for my filter it is enough if axis2 is in subject as it is common that
> > > when you reply you get "Re: [Axis2] ..." so otherwise i would miss all
> > > replies ;-)
> > >
> > > anyway i think we may need a separate mailing list ...
> > >
> > > alek
> > >
> > > >----- Original Message -----
> > > >From: "Aleksander Slominski" <as...@cs.indiana.edu>
> > > >To: <ax...@ws.apache.org>
> > > >Sent: Monday, November 15, 2004 11:10 PM
> > > >Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
> > > >
> > > >
> > > >
> > > >
> > > >>Sanjiva Weerawarana wrote:
> > > >>
> > > >>
> > > >>
> > > >>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>>>* AXIOM API is designed to support pluggable XML transformations
> > > >>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> > > >>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
> > > >>>part of AXIOM.
> > > >>>
> > > >>>
> > > >>>
> > > >>what i mean by it is "designed to support" is that doing data binding
> > > >>should be make easier by making AXIOM API works well with any data
> > > >>binding framework.
> > > >>
> > > >>
> > > >>
> > > >>>In fact data binding is layered into the engine so that
> > > >>>all of Axis2 can run without any data binding and with the app
> > accessing
> > > >>>the OM directly (maybe via something like JXPath layered on).
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>yes so AXIOM API must be designed (or changed when needed) so to support
> > > >>such access.
> > > >>
> > > >>
> > > >>
> > > >>>The point is that providers which have Java object-ified views of
> > > >>>the incoming XML blob is not the only way to implement a service. For
> > > >>>example, the service may be one or more XSLT scripts.
> > > >>>
> > > >>>
> > > >>>
> > > >>>
> > > >>yes - i think it would be very good for doc/literal kind of services and
> > > >>AXIOM should make it easy and not hard to implement such service.
> > > >>
> > > >>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
> > >
> > >
> >
> >
>
>
> --
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Davanum Srinivas <da...@gmail.com>.
yes, please stay here.
On Tue, 16 Nov 2004 17:11:03 +0600, Sanjiva Weerawarana
<sa...@opensource.lk> wrote:
> I think we should stay on axis-dev .. even folks who are not actively
> participating are "lurking" because of that. Also, once Axis 1.2 ships
> the focus can change quite a bit ..
>
> Sanjiva.
>
>
>
> ----- Original Message -----
> From: "Aleksander Slominski" <as...@cs.indiana.edu>
> To: <ax...@ws.apache.org>
> Sent: Tuesday, November 16, 2004 8:06 AM
> Subject: Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
>
> > Sanjiva Weerawarana wrote:
> >
> > >Dude, prefix your messages with [Axis2] ;-).
> > >
> > >
> > for my filter it is enough if axis2 is in subject as it is common that
> > when you reply you get "Re: [Axis2] ..." so otherwise i would miss all
> > replies ;-)
> >
> > anyway i think we may need a separate mailing list ...
> >
> > alek
> >
> > >----- Original Message -----
> > >From: "Aleksander Slominski" <as...@cs.indiana.edu>
> > >To: <ax...@ws.apache.org>
> > >Sent: Monday, November 15, 2004 11:10 PM
> > >Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
> > >
> > >
> > >
> > >
> > >>Sanjiva Weerawarana wrote:
> > >>
> > >>
> > >>
> > >>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>>* AXIOM API is designed to support pluggable XML transformations
> > >>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> > >>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
> > >>>part of AXIOM.
> > >>>
> > >>>
> > >>>
> > >>what i mean by it is "designed to support" is that doing data binding
> > >>should be make easier by making AXIOM API works well with any data
> > >>binding framework.
> > >>
> > >>
> > >>
> > >>>In fact data binding is layered into the engine so that
> > >>>all of Axis2 can run without any data binding and with the app
> accessing
> > >>>the OM directly (maybe via something like JXPath layered on).
> > >>>
> > >>>
> > >>>
> > >>>
> > >>yes so AXIOM API must be designed (or changed when needed) so to support
> > >>such access.
> > >>
> > >>
> > >>
> > >>>The point is that providers which have Java object-ified views of
> > >>>the incoming XML blob is not the only way to implement a service. For
> > >>>example, the service may be one or more XSLT scripts.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>yes - i think it would be very good for doc/literal kind of services and
> > >>AXIOM should make it easy and not hard to implement such service.
> > >>
> > >>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
> >
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
I think we should stay on axis-dev .. even folks who are not actively
participating are "lurking" because of that. Also, once Axis 1.2 ships
the focus can change quite a bit ..
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Tuesday, November 16, 2004 8:06 AM
Subject: Re: AXIOM and data binding [Re: [Axis2] AXIOM goals
> Sanjiva Weerawarana wrote:
>
> >Dude, prefix your messages with [Axis2] ;-).
> >
> >
> for my filter it is enough if axis2 is in subject as it is common that
> when you reply you get "Re: [Axis2] ..." so otherwise i would miss all
> replies ;-)
>
> anyway i think we may need a separate mailing list ...
>
> alek
>
> >----- Original Message -----
> >From: "Aleksander Slominski" <as...@cs.indiana.edu>
> >To: <ax...@ws.apache.org>
> >Sent: Monday, November 15, 2004 11:10 PM
> >Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
> >
> >
> >
> >
> >>Sanjiva Weerawarana wrote:
> >>
> >>
> >>
> >>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >>>
> >>>
> >>>
> >>>
> >>>>* AXIOM API is designed to support pluggable XML transformations
> >>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> >>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
> >>>>
> >>>>
> >>>>
> >>>>
> >>>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
> >>>part of AXIOM.
> >>>
> >>>
> >>>
> >>what i mean by it is "designed to support" is that doing data binding
> >>should be make easier by making AXIOM API works well with any data
> >>binding framework.
> >>
> >>
> >>
> >>>In fact data binding is layered into the engine so that
> >>>all of Axis2 can run without any data binding and with the app
accessing
> >>>the OM directly (maybe via something like JXPath layered on).
> >>>
> >>>
> >>>
> >>>
> >>yes so AXIOM API must be designed (or changed when needed) so to support
> >>such access.
> >>
> >>
> >>
> >>>The point is that providers which have Java object-ified views of
> >>>the incoming XML blob is not the only way to implement a service. For
> >>>example, the service may be one or more XSLT scripts.
> >>>
> >>>
> >>>
> >>>
> >>yes - i think it would be very good for doc/literal kind of services and
> >>AXIOM should make it easy and not hard to implement such service.
> >>
> >>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: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>Dude, prefix your messages with [Axis2] ;-).
>
>
for my filter it is enough if axis2 is in subject as it is common that
when you reply you get "Re: [Axis2] ..." so otherwise i would miss all
replies ;-)
anyway i think we may need a separate mailing list ...
alek
>----- Original Message -----
>From: "Aleksander Slominski" <as...@cs.indiana.edu>
>To: <ax...@ws.apache.org>
>Sent: Monday, November 15, 2004 11:10 PM
>Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
>
>
>
>
>>Sanjiva Weerawarana wrote:
>>
>>
>>
>>>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>>>
>>>
>>>
>>>
>>>>* AXIOM API is designed to support pluggable XML transformations
>>>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
>>>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
>>>>
>>>>
>>>>
>>>>
>>>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
>>>part of AXIOM.
>>>
>>>
>>>
>>what i mean by it is "designed to support" is that doing data binding
>>should be make easier by making AXIOM API works well with any data
>>binding framework.
>>
>>
>>
>>>In fact data binding is layered into the engine so that
>>>all of Axis2 can run without any data binding and with the app accessing
>>>the OM directly (maybe via something like JXPath layered on).
>>>
>>>
>>>
>>>
>>yes so AXIOM API must be designed (or changed when needed) so to support
>>such access.
>>
>>
>>
>>>The point is that providers which have Java object-ified views of
>>>the incoming XML blob is not the only way to implement a service. For
>>>example, the service may be one or more XSLT scripts.
>>>
>>>
>>>
>>>
>>yes - i think it would be very good for doc/literal kind of services and
>>AXIOM should make it easy and not hard to implement such service.
>>
>>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: AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Dude, prefix your messages with [Axis2] ;-).
Sanjiva.
----- Original Message -----
From: "Aleksander Slominski" <as...@cs.indiana.edu>
To: <ax...@ws.apache.org>
Sent: Monday, November 15, 2004 11:10 PM
Subject: AXIOM and data binding [Re: [Axis2] AXIOM goals
> Sanjiva Weerawarana wrote:
>
> >"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> >
> >
> >>* AXIOM API is designed to support pluggable XML transformations
> >>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> >>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
> >>
> >>
> >
> >I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
> >part of AXIOM.
> >
> what i mean by it is "designed to support" is that doing data binding
> should be make easier by making AXIOM API works well with any data
> binding framework.
>
> >In fact data binding is layered into the engine so that
> >all of Axis2 can run without any data binding and with the app accessing
> >the OM directly (maybe via something like JXPath layered on).
> >
> >
> yes so AXIOM API must be designed (or changed when needed) so to support
> such access.
>
> >The point is that providers which have Java object-ified views of
> >the incoming XML blob is not the only way to implement a service. For
> >example, the service may be one or more XSLT scripts.
> >
> >
> yes - i think it would be very good for doc/literal kind of services and
> AXIOM should make it easy and not hard to implement such service.
>
> alek
>
> --
> The best way to predict the future is to invent it - Alan Kay
>
>
AXIOM and data binding [Re: [Axis2] AXIOM goals
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>* AXIOM API is designed to support pluggable XML transformations
>>(JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
>>discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
>>
>>
>
>I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
>part of AXIOM.
>
what i mean by it is "designed to support" is that doing data binding
should be make easier by making AXIOM API works well with any data
binding framework.
>In fact data binding is layered into the engine so that
>all of Axis2 can run without any data binding and with the app accessing
>the OM directly (maybe via something like JXPath layered on).
>
>
yes so AXIOM API must be designed (or changed when needed) so to support
such access.
>The point is that providers which have Java object-ified views of
>the incoming XML blob is not the only way to implement a service. For
>example, the service may be one or more XSLT scripts.
>
>
yes - i think it would be very good for doc/literal kind of services and
AXIOM should make it easy and not hard to implement such service.
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] AXIOM goals
Posted by Aleksander Slominski <as...@cs.indiana.edu>.
Sanjiva Weerawarana wrote:
>"Aleksander Slominski" <as...@cs.indiana.edu> writes:
>
>
>>i am very interested to hear if this list needs modifications and what
>>if the order of items reflect their priority
>>
>>
>
>Excellent list!
>
>
>
i have put the list in WIKI:
http://wiki.apache.org/ws/FrontPage/Architecture/OMGoals
All OM developers: please visit the list and post your concerns.
thanks,
alek
--
The best way to predict the future is to invent it - Alan Kay
Re: [Axis2] AXIOM goals
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
"Aleksander Slominski" <as...@cs.indiana.edu> writes:
> i am very interested to hear if this list needs modifications and what
> if the order of items reflect their priority
Excellent list!
> here is my understanding/interpretation:
> * AXIOM API has no dependencies on other modules in AXIS2
+1
> * AXIOM API have dependencies on DOM, SAX, StAX, XmlPull
No- it depends *only* on StAX .. or actually eventually the
"typed" StAX API that's in SVN, which builds on StAX.
> * AXIOM API allows to construct OM representing XML Infoset from input
+1
> * AXIOM API allows to write OM as XML Infoset to output
+1
> * AXIOM API can have multiple implementations with different performance
> characteristics and optimizations
+1
> * AXIOM API provides subset of XML Infoset that is deemed needed for SOAP
+1
> * AXIOM API allows manipulation of XML infoset (adding elements,
> removing etc)
+1, again only that is deemed needed for SOAP.
> * AXIOM API allows to access SOAP:Body directly as event stream and
> avoid building of XML tree for it
+1
> * AXIOM API allows to supports DOM L2 (L3?) as an addon for cases when
> security is used [for example WSS4J implementation XML Security requires
> DOM as it uses libs requiring DOM]; when not DOM is not required then
> AXIOM can be used without DOM APIs to achieve better performance and
> lower memory footprint [configurable feature requested when OM is created]
No. DOM support is a layer on top of AXIOM, not built into AXIOM.
Building the DOM impl is not a requirement to complete AXIOM. However,
we will have to build it when plugging in the WSS4J code for sure and
at that time it may be decided that it makes sense to keep that impl
near/in AXIOM makes sense. Right now I'm -1 to saying the DOM impl is
part of AXIOM because its not needed for Axis2 to complete.
> * AXIOM API supports MTOM with a consistent XML Infoset view (MTOM
> content looks like BASE64), allows direct optimized access to binary
> data, and allows to store references to binary data that is serialized
> according to MTOM/XOP rules (BASE64 if no attachments)
+1
> * AXIOM API is designed to support pluggable XML transformations
> (JavaBeans2XML, XSD with JaxMe/JAXB, Castor, XmlBeans, RelaxNG, ...)
> discussed in http://nagoya.apache.org/jira/browse/AXIS-1498
I can't read AXIS-1498 right now (offline ATM) but data binding is NOT
part of AXIOM. In fact data binding is layered into the engine so that
all of Axis2 can run without any data binding and with the app accessing
the OM directly (maybe via something like JXPath layered on).
The point is that providers which have Java object-ified views of
the incoming XML blob is not the only way to implement a service. For
example, the service may be one or more XSLT scripts.
> * AXIOM API makes possible to store Java objects convertible to XML
> Infoset on demand [for serialization]
+1 .. but that's just a different builder for AXIOM - starts with a
Java object instead of a stream. We'll need a builder from DOM too
in the future.
> * AXIOM API allows other APIs to be built on top of it including SAAJ
+1
> * AXIOM API is easy to use and follow common XML APIs patterns (like
> JDOM, XOM) but has also if SOAP specific features if needed
What's XOM? +1 for JDOM-like convenience.
> * AXIOM API makes possible to create implementations with good or very
> good performance and used general XML benchmarks (like Sosnoski) and WS
> specific benchmarks developed based on use cases to estimate performance
> and guard against regressions
+1
> * AXIOM API is designed to minimize memory footprint, allows streaming
> and avoids creating wrapper objects if not needed
API enables different implementations - some which optimize memory,
some which optimize for speed. Sometimes these two objectives cannot
be met at the same time obviously.
> * [optional] AXIOM impl that has MTOM binary data streamed in/out of
> external storage to avoid OutOfMemory exceptions for very large content
Sure, +1.
> * [optional] AXIOM impl that uses XBIS <http://xbis.sourceforge.net/>
> for optimized transport of XML Infoset, especially useful for low memory
> footprint and better performance between two WS nodes that uses XBIS
+1 but not only XBIS- there are several candidates available for
alternate serializations and I'm very interested in enabling these.
Hence my rabid focus on using tStAX for all input and output.
> * [optional] AXIOM impl that uses XBIS (or similar) to store XML events
> for replay from memory (or file? db?),
Not optional .. have to be able to serialize the entire message from
day one. Sandesha cannot work fully without this capability.
Sanjiva.