axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From hemap...@apache.org
Subject svn commit: r155184 - webservices/axis/trunk/java/xdocs/intro.html
Date Thu, 24 Feb 2005 12:51:40 GMT
Author: hemapani
Date: Thu Feb 24 04:51:38 2005
New Revision: 155184

URL: http://svn.apache.org/viewcvs?view=rev&rev=155184
Log:
update the intro

Modified:
    webservices/axis/trunk/java/xdocs/intro.html

Modified: webservices/axis/trunk/java/xdocs/intro.html
URL: http://svn.apache.org/viewcvs/webservices/axis/trunk/java/xdocs/intro.html?view=diff&r1=155183&r2=155184
==============================================================================
--- webservices/axis/trunk/java/xdocs/intro.html (original)
+++ webservices/axis/trunk/java/xdocs/intro.html Thu Feb 24 04:51:38 2005
@@ -1,23 +1,39 @@
 <h1 align="center">WebServices - Axis 2.0</h1>
 <h2 align="left">Introduction</h2>
-<p>Axis 2.0 will be a platform for the next generation of web services / service 
-oriented applications. To achieve this goal, we need to incorporate the latest 
-in concepts in Web Services Architecture group and WSDL working group among 
-others. For example, the architecture should be completely asynchronous and 
-should support all kinds of MEP's. The platform must be very extensible 
-(runtime, java2wsdl, wsdl2java etc) to accomodate the growing demand for 
-different WS-* implementations. A &quot;module&quot; can very easily change the behaviour

-of existing components. For example, additional decorations can be added at 
-runtime to the base wsdl (for example, for WSDM manageability spec). Presence of 
-an addressing module could change the client code generated (where additional 
-methods can be exposed) that make it easy to use addressing. One main focus is 
-to improve the performance even in the presence of a heavy duty &quot;security&quot;

-module. </p>
-<p>As a starting point we have started working on the core of Axis 2.0. This M1 
-release will not have support for ANY JSR specs like JAX-RPC or SAAJ. But we 
-will make sure we can build JAXRPC/SAAJ layers on top of the core architecture. 
-The core is basically a streaming XML infoset that we call &quot;OM&quot; that supports

-deffered building and the xml pull event generation and async support will be 
-baked in to the core as well. </p>
+<p>
+Axis2 is an effort to re-design and totally re-implement both Axis/Java and
+(eventually) Axis/C++ on a new architecture. Evolving from the now standard
+"handler chain" model which Axis1 pioneered, Axis2 is developing a more
+flexible pipeline architecture which can yet be managed and packaged in a
+more organized manner. This new design acknowledges the maturing of the Web
+services space – in terms of new protocols such as WS-ReliableMessaging,
+WS-Security and WS-Addressing that are built on top of the base SOAP system.
+At the time Axis1 was designed, while it was fully expected that other protocols
+such as WS-ReliableMessaging would be built on top of it, there was not a
+proper extension architecture defined to enable clean composition of
+such layers.</p>
+<p>Thus, one of the key motivations for Axis2 is to provide a clean and simple
+environment for like Apache Sandesha [4] and Apache WSS4J [5] to layer on
+top of the base SOAP system.
+Another driving force for Axis2 as well as the move away from RPC oriented
+Web services towards more document-oriented, message style asynchronous
+service interactions. The Axis2 project is centered on a new representation
+for SOAP messages called AXIOM (AXIs Object Model). AXIOM consists of two
+parts: a complete XML Infoset representation and a SOAP Infoset representation
+on top of that. The XML Infoset representation provides a JDOM-like simple
+API but is built on a deferred model via a StAX-based (Streaming API for XML)
+pull parsing API. A key feature of AXIOM is that it allows one to stop
+building the XML tree and just access the pull stream directly; thus enabling
+both maximum flexibility and maximum performance. This approach allows us to
+support multiple levels of abstraction for consuming and offering Web
+services: using plain AXIOM, using generated code and statically data-bound
+data types and so on.</p>
+<p>At the time of Axis1's design, RPC-style, synchronous, request-response
+interactions were the order of the day for Web services. Today service
+interactions are much more message-oriented and exploit many different
+message exchange patterns. The Axis2 engine architecture is careful to
+not build in any assumptions of request-response patterns to ensure that
+it can be used easily to support arbitrary message exchange patterns.
+</p>
 <h2 align="left">Credits</h2>
 <p align="left">Axis 2.0 development team</p>



Mime
View raw message