ws-axis-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From to...@apache.org
Subject cvs commit: ws-axis/site/src4forrest-060/java/src/documentation/content/xdocs/docs CachingEarlDraft2.xml F2F-2.xml ms-interop.xml SOAPVerse.xml
Date Thu, 27 Jan 2005 09:42:15 GMT
toshi       2005/01/27 01:42:15

  Added:       site/src4forrest-060/java/src/documentation/content/xdocs/docs
                        CachingEarlDraft2.xml F2F-2.xml ms-interop.xml
                        SOAPVerse.xml
  Log:
  Migration for Forrest 0.6
  
  Revision  Changes    Path
  1.1                  ws-axis/site/src4forrest-060/java/src/documentation/content/xdocs/docs/CachingEarlDraft2.xml
  
  Index: CachingEarlDraft2.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd">
  <document> 
    <header> 
      <title>WebServices - Axis</title> 
    </header> 
    <body> 
      <section>
        <title>WebServices - Axis - Caching Early Draft</title>
  <p>
  <TABLE border="0" WIDTH="100%" cellspacing="80">
   <TR>
    <TD ALIGN="CENTER">
     <H1>
     Draft Proposal of<br/>
     Caching Mechanism for Axis<br/>
     as a JAX-RPC runtime system<br/>
     </H1>
    </TD>
   </TR>
   <TR>
    <TD ALIGN="CENTER">
     <H2>
     Early draft 2<br/>
     25 Aug, 2003
     </H2>
    </TD>
   </TR>
   <TR>
    <TD ALIGN="CENTER">
     <H2>
     Toshiyuki Kimura<br/>
     Apache Axis Committer<br/>
     toshi@apache.org
     </H2>
    </TD>
   </TR>
  </TABLE>
  
  <hr/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT" id="page2">- Page 2 -</TD></TR>
  </TABLE>
  <H2>Table of Contents</H2>
  <P>
  <TABLE BORDER="0" cellspacing="20">
   <TR>
    <TD>
  <a href="#section1">1. INTRODUCTION</a><br/>
  <a href="#section1.1">1.1 DESIGN GOALS</a><br/>
  <a href="#section1.2">1.2 ACKNOWLEDGMENTS</a><br/>
  <a href="#section1.3">1.3 STATUS</a><br/>
  <a href="#section1.4">1.4 NOTATIONAL CONVENTIONS</a><br/>
  <a href="#section2">2. CACHING MECHANISM USECASE</a><br/>
  <a href="#section2.1">2.1 WEATHER FORECAST SERVICE</a><br/>
  <a href="#section2.1.1">2.1.1 Service Description</a><br/>
  <a href="#section2.1.2">2.1.2 Service Use</a><br/>
  <a href="#section2.2">2.2 CACHING MECHANISMS</a><br/>
  <a href="#section2.2.1">2.2.1 Service Client</a><br/>
  <a href="#section2.2.2">2.2.2 Server Side</a><br/>
  <a href="#section3">3. REQUIREMENTS</a><br/>
  <a href="#section4">4. REFERENCE</a><br/>
  <a href="#section5">5. APPENDIX: PROTOTYPE OF CACHING MECHANISM</a><br/>
  <a href="#section6">6. APPENDIX: SAMPLE APPLICATION</a><br/>
  <a href="#section7">7. APPENDIX: UNRESOLVED ISSUES</a><br/>
    </TD>
    <TD>
  <a href="#page3">------ 3<br/></a>
  <a href="#page3">------ 3<br/></a>
  <a href="#page3">------ 3<br/></a>
  <a href="#page3">------ 3<br/></a>
  <a href="#page3">------ 3<br/></a>
  <a href="#page4">------ 4<br/></a>
  <a href="#page4">------ 4<br/></a>
  <a href="#page4">------ 4<br/></a>
  <a href="#page5">------ 5<br/></a>
  <a href="#page5">------ 5<br/></a>
  <a href="#page5">------ 5<br/></a>
  <a href="#page6">------ 6<br/></a>
  <a href="#page7">------ 7<br/></a>
  <a href="#page7">------ 7<br/></a>
  <a href="#page8">------ 8<br/></a>
  <a href="#page8">------ 8<br/></a>
  <a href="#page9">------ 9<br/></a>
  </TD>
   </TR>
  </TABLE>
  </P>
  <HR id="page3"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 3 -</TD></TR>
  </TABLE>
  <H1 id="section1">1. Introduction</H1>
  <DIV>
  <p>
    At the present time, SOAP is actually famous as a transport-independent protocol. But
in fact,
  HTTP protocol is the leading binding of SOAP implementations. In addition, a lot of JAX-RPC
  implementations use the HTTP POST method for invoking Web Services based on SOAP 1.1
  specification. The HTTP POST method is specified in HTTP 1.0 specification (RFC 1945) as
  uncacheable. Because of this, SOAP is also uncacheable in the present situation.</p>
  <p>
    This document proposes a set of APIs for JAX-RPC and Messaging styles to enable the cache
  control mechanism in various SOAP implementations.
  </p>
  </DIV>
  
  <H2 id="section1.1">1.1 Design Goals</H2>
  <DIV>
    The goals of this document are as follows:<br/>
  <UL>
    <LI>Specify APIs for supporting Caching Mechanism for both Server side and Client
side on the
    Java platform. Caching Mechanism includes 'Enable/Disable Cache', 'Validate Cache',
    'Reload Control', and 'Invalidate Cached Data'.</LI>
    <LI>Define protocol-bindings independent of Caching Mechanism for SOAP Messages</LI>
    <LI>Support both HTTP POST method and HTTP GET method as cacheable protocol bindings
    for SOAP Messaging</LI>
    <LI>Support interoperability across heterogeneous platforms and environments</LI>
    <LI>Support conformance and interoperability requirements that are testable for
an
    implementation of this proposal</LI>
  </UL>
  
  <H2 id="section1.2">1.2 Acknowledgments</H2>
    Satoshi Koyama, Takayuki Nagakura, Kenji Suzuki, and Masashi Takeichi (all from NTT DATA
  corporation and its business partners) have provided precious technical input to this document.
  
  <H2 id="section1.3">1.3 Status</H2>
    This document is the early draft version of the proposal.
  
  <H2 id="section1.4">1.4 Notational Conventions</H2>
  <UL>
    <LI>Diagrams follow the standard UML notation</LI>
    <LI>Code snippets are not shown in complete form. Refer to the Java docs for complete
and
    detailed description.</LI>
    <LI>Examples are illustrative (non-prescriptive)</LI>
  </UL>
  </DIV>
  
  <HR id="page4"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 4 -</TD></TR>
  </TABLE>
  <H1 id="section2">2. Caching Mechanism Usecase</H1>
  This chapter describes use cases for the Cashing model in a non-prescriptive manner. Later
  chapters of this document specify requirements and APIs in a prescriptive manner.
  
  <H2 id="section2.1">2.1 Weather Forecast Service</H2>
  <DIV>
    The following description uses a weather forecast service example to illustrate Caching
  Mechanism concepts.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image2-1.gif"/>
  </DIV>
  
  <H2 id="section2.1.1">2.1.1 Service Description</H2>
  <DIV>
    The WeatherForecastService endpoint defines and implements the following Java interface.
  </DIV>
  <B>Code Example: Interface of WeatherForecastService</B>
  <BLOCKQUOTE>
  package com.example;<br/>
  public interface WeatherForecastProvider extends java.rmi.Remote {<br/>
  int getChanceOfRain ( String areaSymbol ) throws java.rmi.RemoteException;<br/>
  &nbsp;&nbsp;&nbsp;&nbsp;// ...<br/>
  }<br/>
  </BLOCKQUOTE>
  The WeatherForecastService has the following features to note:
  <UL>
    <LI>It returns a chance of rain for the specified area.</LI>
    <LI>It forecasts chance of rain from observation data which is provided every 3
hours.</LI>
    <LI>The chance of rain won't be changed until the next update of observation data,
even though
    a client has frequently access to the service.</LI>
  </UL>
  
  <hr/>
  <TABLE WIDTH="100%" id="page5">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 5 -</TD></TR>
  </TABLE>
  <H2 id="section2.1.2">2.1.2 Service Use</H2>
  <DIV>
    A service client uses a JAX-RPC service by invoking remote methods on a service endpoint.
  The following diagram shows how a service client uses JAX-RPC runtime and Caching
  Mechanism.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image2-1-2.gif"/>
  </DIV>
  
  <H2 id="section2.2">2.2 Caching Mechanisms</H2>
  <DIV>
    This section describes an overview of Caching Mechanisms.
  </DIV>
  
  <H2 id="section2.2.1">2.2.1 Service Client</H2>
  <DIV>
    The following use case diagram shows how a client-side JAX-RPC runtime system uses local
  cached data which is stored by Caching Mechanisms.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image2-2-1.gif"/>
  </DIV>
  
  <HR id="page6"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 6 -</TD></TR>
  </TABLE>
  <H2 id="section2.2.2">2.2.2 Server Side</H2>
  <DIV>
    The diagram shows how a server-side JAX-RPC runtime system informs that a response
  message is cacheable to the service client.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image2-2-2.gif"/>
  </DIV>
  
  <HR id="page7"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 7 -</TD></TR>
  </TABLE>
  <H1 id="section3">3. Requirements</H1>
  <DIV>
    This chapter specifies the proposed scope and requirements for the 1.0 version of Caching
  Mechanisms. These requirements will be described in more depth in the later chapters.
  </DIV>
  
  <B>R01 Protocol Bindings</B>
  <UL>
  The goal of this document is to enable support for multiple protocol bindings. SOAP 1.1
  specification [1] provides a sample for using SOAP in HTTP protocol [4] with HTTP POST
  methods. An extended version, SOAP 1.2 [2] adds a scenario by using HTTP GET methods.
  <B>Note:</B> HTTP 1.0 [3] does not allow caching for HTTP POST methods, however
HTTP 1.1 adds
  some additional rules to enable caching mechanisms for HTTP POST methods.
  </UL>
  
  <B>R02 Transport</B>
  <UL>
  As a minimum this caching mechanism is required to support HTTP 1.1 as the transport for
  SOAP message. HTTP binding for the SOAP message is based on the SOAP 1.1 specification
  [1].
  </UL>
  
  <H1 id="section4">4. Reference</H1>
  <UL>
    <LI>[1] W3C Note: SOAP 1.1: <link href="http://www.w3c.org./TR/SOAP/">http://www.w3c.org./TR/SOAP/</link></LI>
    <LI>[2] W3C: SOAP 1.2: <link href="http://www.w3c.org/TR/soap12/">http://www.w3c.org/TR/soap12/</link></LI>
    <LI>[3] HTTP 1.0 <link href="http://www.w3.org/Protocols/rfc1945/rfc1945">http://www.w3.org/Protocols/rfc1945/rfc1945</link></LI>
    <LI>[4] HTTP 1.1: <link href="http://www.w3.org/Protocols/rfc2616/rfc2616">http://www.w3.org/Protocols/rfc2616/rfc2616</link></LI>
  </UL>
  
  <HR id="page8"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 8 -</TD></TR>
  </TABLE>
  <H1 id="section5">5. Appendix: Prototype of Caching mechanism</H1>
  <DIV>
    In order to demonstrate the feasibility of Caching Mechanisms, I made a prototype of a
cache
  controller which provides a local cache on the service client side.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image5.gif"/>
  </DIV>
  
  <DIV>
    The hatched areas indicate the extended modules for Apache Axis as a typical JAX-RPC
  implementation. The detail of this implementation (i.e. class diagram, sequence diagram,
and
  Java docs) will be provided after translation and review.
  </DIV>
  
  <H1 id="section6">6. Appendix: Sample Application</H1>
  <DIV>
    This sample application uses the WeatherForecastService to enable a cacheable scenario.
When
  an end-user sets a location (like as Tokyo, Osaka, or Kyoto) and invokes the service, the
  system returns chance of rains for the specified area. Additionally, if the request is cached
data
  and the cache is still valid data, the response message will be picked up from the cache
  repository.
  </DIV>
  
  <DIV ALIGN="CENTER">
  <img src="images/image6.gif"/>
  </DIV>
  
  <DIV>
  <B>Note:</B> The role of the HTTP Header Handler is to set a HTTP protocol header
for cache controls.
  </DIV>
  
  <HR id="page9"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 9 -</TD></TR>
  </TABLE>
  <H1 id="section7">7. Appendix: Unresolved issues</H1>
  <DIV>
    The following items are to be determined.
  </DIV>
  
  <TABLE BORDER="1" WIDTH="90%" ALIGN="CENTER">
   <TR ALIGN="CENTER">
    <TH>ID</TH><TH>Name</TH><TH>Detail (actual state)</TH>
   </TR>
   <TR>
    <TD>1</TD><TD>Dynamic cache-control API</TD><TD>The current
version only provides static configurations with
  server-config.wsdd.</TD>
   </TR>
   <TR>
    <TD>2</TD><TD>SwA (SOAP Messages with Attachments)</TD><TD>The
current version doesn't support caching a response which
  has attachment parts.</TD>
   </TR>
   <TR>
    <TD>3</TD><TD>Protocol-bindings independent Caching Mechanism</TD><TD>The
current version is a prototype for HTTP bindings. To
  create a protocol-bindings independent Caching Mechanism,
  the following needs to be done;
    <UL>
      <LI> Specify a standard SOAP Message header to cache</LI>
      <LI> Implement a SOAP Message setter on server side</LI>
      <LI> Implement a SOAP Message parser on client side</LI>
    </UL></TD>
   </TR>
  </TABLE>
  
  <HR id="page10"/>
  <TABLE WIDTH="100%">
   <TR><TD ALIGN="RIGHT">Copyright &copy; 2003 Toshiyuki Kimura</TD></TR>
   <TR><TD ALIGN="LEFT">- Page 10 -</TD></TR>
  </TABLE>
  <TABLE BORDER="0" WIDTH="100%" CELLSPACING="100">
   <TR><TD></TD></TR>
   <TR><TD>
    <BLOCKQUATE>
    Sun, Sun Microsystems, and Java are trademarks or registered trademarks of
    Sun Microsystems, Inc. All other product names mentioned herein are
    trademarks of their respective owners.
    </BLOCKQUATE>
   </TD></TR>
  </TABLE>
  </p>
      </section>
    </body>
  </document>
  
  
  
  1.1                  ws-axis/site/src4forrest-060/java/src/documentation/content/xdocs/docs/F2F-2.xml
  
  Index: F2F-2.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd">
  <document> 
    <header> 
      <title>WebServices - Axis</title> 
    </header> 
    <body> 
      <section>
        <title>WebServices - Axis - </title>
  <p>
  <h2>Notes from Axis Face-to-Face Meeting at Allaire, Newton, MA.  </h2>
  <h3>Date: 28 Feb 2001</h3>
  <b>Attendees:</b>
  <ul>
  <li>Glen Daniels, Allaire.  Host</li>
  <li>Doug Davis, IBM Raleigh</li>
  <li>Steve Graham, IBM Raleigh</li>
  <li>Jim Stearns, HP Redmond</li>
  <li>Jacek Kopecky,  Idoox, Prague</li>
  <li>Waqar Sadiq, Vitria</li>
  <li>James Snell, IBM Fresno (by phone)</li>
  <li>Stuart Williams, HP Bristol</li>
  </ul>
  
  <p>Glen expressed some frustration at the lack of good tools that Apache provides
for project management.  The mailing list archives kind of bite, etc.  SourceForge seems to
have good tools for scheduling / task management / collaboration...</p>
  
  <p><i><b>ACTION ITEM : Glen will email Sam and ask about the possibility
of "co-locating" the project with SourceForge? Investigating other tools and solutions?</b></i></p>
  
  <p>Waquar Sadiq from Vitria, a new member of the team, volunteered to be Project Manager
for Axis!  (applause applause)</p>
  
  <p>Steve presented a short Powerpoint presentation to frame the meeting.</p>
  
  Axis 1.0 will be a serious product.  As such, it will have:
  <ul>
  <li>product-level code</li>
  <li>product-level testing</li>
  <li>product-level doc + examples</li>
  <li>product-level performance</li>
  </ul>
  
  <h4>Goals for the 1.0 release:</h4>
  <ul>
  <li>Full SOAP 1.1 implementation</li>
  <ul>
    <li>Interoperability testing/discussions to answer ambiguities</li>
    <li>Intermediary implementation must be in 1.0 release</li>
  </ul>
  <li>Relative priority (Glen)</li>
     <ul>
     <li>Full implementation of 1.1</li>
     <li>Customer requirements</li>
     <li>Where xmlp is headed (Glen, Waqar, Jacek are all on XML Protocol group)</li>
     </ul>
  
  <li>Fast (need to do the streaming parsing)</li>
  <li>Pluggable</li>
  </ul>
  
  <p>Support for requestor/provider/intermediary (one-way, initiated by either side);
client notification.
  Support for request/response and the other 3 transmission primitives from WSDL</p>
  
  <p>Glen : Don't think we should make the axis-user list until 0.9 or beta 1.0...</p>
  
  <p>Issue : Migrating from Apache SOAP to Axis - should be easy, but how easy?</p>
  
  <p>Waqar: We should be tracking ebXML as well as XMLP...</p>
  
  <h5>Testing/Process-related discussion...</h5>
  <ul>
  <li>coding standards</li>
  <li>test-case centric development</li>
  <li>regression test cases</li>
  <li>scenario-centric design/architecture</li>
  <li>Unit tests are good, but not sufficient</li>
  <li>Is JUnit too oriented towards "white box" unit testing?  Jim says they're using
it as a framework at HP for both unit and functional.</li>
  <li>Three types of testing - unit, functional integration, interop</li>
  <li>conformance testing; maybe use the userland validator? leverage external efforts?
Microsoft "bakeoff"?</li>
  <li>interop testing with big players (.NET) is crucial!</li>
  <li>Requiring some level of testing implementation from commmitters is key.  The question
is how to best codify this in a strong but not draconian way</li>
  </ul>
  
  The plan for the rest of today:
  <ul>
  <li>Walk through requirements doc</li>
  <li>Generate scenarios</li>
  <li>walk through scenarios, updating requirements</li>
  </ul>
  
  
  <h3>Requirements discussion</h3>
  <ul>
   <li>lose
       1.1 and 1.1.1: architecture is settling  not overdoing use of handlers</li>
   <li>server-initiated
       solicit/response (in WSDL spec)</li>
   <li>4
       options (synch/asynch, client-initiated vs server-initiated)</li>
   <ul type="circle">
    <li>requestor/provider
        </li>
    <li>Facets
        (Steve):</li>
    <ul type="square">
     <li>Who
         initiates (server or client)</li>
     <li>1-way/2-way</li>
     <li>asynch/synch</li>
     <li>(1-way
         synch makes no sense, so 7 options)</li>
     <li>2-way
         asynch?</li>
    </ul>
    <li>Glen:
        what is underlying protocol doesn't support synchronous (such as smtp)?</li>
    <li>Waqar:
        what about async request expecting ack, vs. one not expecting one?</li>
    <li>Is this (a)synchronous at the <b>API</b> level, or the <b>transport</b>
level?</li>
    <li>Call
        this topic "message exchange patterns"</li>
    <li>"Synchronous"
        == blocking</li>
    <li>everything is initiated
        by a client of the axis engine, which can be on requestor,
        intermediary, or provider</li>
    <li>Q:
        in a one-way WSDL message, can you specify a fault? James: yes, but spec doesn't say
what
        to do with the fault. Stuart:
        thinks treatment of fault is above the message layer.</li>
    <li>WSDL
        1.1 one-way only has input, but doesn't have output or fault (Steve
        brought up)</li>
    <li>Stuart:
        Service in wsdl is more like operation.</li>
   </ul>
   <li>What
       can we dispatch by?</li>
   <ul type="circle">
    <li>Dispatch
        by transport URL</li>
    <li>Dispatch
        by HTTP SOAPAction</li>
    <li>Dispatch
        by QName of first body entry</li>
    <li>Dispatch,
        using custom handler, by any information available)</li>
   </ul>
   <li>How
       many RPC's per message, and where</li>
   <ul type="circle">
    <li>Axis
        will NOT support a RPC invocation specified in a header</li>
    <li>Axis
        will support only one RPC invocation per body entry.</li>
    <li>Suggestion to remove "first" from body child, 6-2 against.</li>
   </ul>
   <li>XML
       Prototocol - Status</li>
   <ul type="circle">
    <li>Something
        will be published in April  issues with SOAP 1.1 that need to be fixed</li>
    <li>July-ish:
        first XML protocol spec  soap 1.1 with fixes to some issues</li>
    <li>November:
        proposed recommendation</li>
    <li>December:
        1.0 spec  recommendation</li>
   </ul>
   <li>Intermediaries:
       Glen: TRLSoap has implemented them to some extent.</li>
   <ul type="circle">
    <li>Steve:
        state of the art is Single-hop fake.</li>
   </ul>
   <li>SOAP
       Encoding Support</li>
   <ul type="circle">
    <li>We
        use for RPC, and yet won't require xsi:type (<b>type info can come from a
        reference to a schema outside the message</b>) </li>
   </ul>
   <li>Performance</li>
   <ul type="circle">
    <li>Action
        Item: need to research alternative benchmarks for SOAP performance (Jim
        volunteered) and for interoperability.</li>
    <ul type="square">
     <li>UI</li>
    </ul>
    <li>Glen
        was willing to prioritize "not significantly slower" as want but not
        required. Jim advocated that we
        need at release, and Steve agreed.</li>
   </ul>
  </ul>
  
  <p>Discussion of metrics - some arguments as to whether it's a Handler or an API.
 Well, logging is an API, maybe metrics are as well...</p>
  
  <p><i><b>ACTION ITEM: Glen will investigate JRun's metrics API and share
with the group.</b></i></p>
  
  <p>We need to have some kind of "Required header" parameter either in the WSDD or
as an API in the Handler itself if we want "pre-flight" knowledge of required headers (and
perhaps a default fault response)...</p>
  
  <p>Big discussion about header handling - jukebox handler, there were worries that
it's a security risk.  Glen notes that the handlers that are in the jukebox's registry are
limited, just like the handlers on a chain, you just don't need to call them all in order...doesn't
seem like a risk.</p>
  
  
  <hr/>
  
  <h2>Day 2</h2>
  <h3>1 March 2001</h3>
  
  <b>Attendees:</b>
  <ul>
  <li>Glen</li>
  <li>Steve</li>
  <li>Doug</li>
  <li>Jacek</li>
  <li>Jim</li>
  </ul>
  
  Agenda (wish list):
  <ul>
  <li>Finish revision of requirements</li>
  <li>Develop rough use case scenarios</li>
  <li>Revisit requirements after use cases</li>
  <li>Glen: supplier pattern</li>
  <li>Steve: WSDD</li>
  <li>All: streaming parser</li>
  </ul>
  
  <p>Code on BOTH client and Server looks like this?</p>
  
  <code>
  Handler handler = Axis.getHandler(name1);<br/>
  MessageContext mc = new MessageContext();<br/>
  // set up MC properties, including target!<br/>
  handler.invoke(mc);<br/>
  </code>
  
  <h3>Requirements review, continued</h3>
  
  <ul>
   <li>Service
       Description</li>
   <ul type="circle">
    <li>Interaction
        between WSDL and WSDD. Each can
        be used to create the other?</li>
    <li>Steve:
        hard to generate wsdl for document (rather than rpc).</li>
    <li>Jacek:
        treat the WSDD as the master</li>
    <li>Jim:
        no, WSDL is the standard, WSDD is just our team's proposal.</li>
    <li>Glen:
        WSDD may not contain all the info needed to generate a WSDL file</li>
    <li>WSDD
        can contain either (1) pointer to existing WSDL file or (2) enough data
        (possibly, but not certainly) to generate a WSDL from scratch, or (3)
        enough data which in combination with existing WSDL, to generate an
        updated WSDL.</li>
    <li>WSDD
        should provide cross-checking (WSDL not consistent with WSDD)</li>
    <li>(I
        missed some issues here: there's flexibility here that makes this
        difficult  e.g. what serializer?)</li>
    <li>DISCO
        on Axis root added.</li>
    <li>Client-side</li>
    <ul type="square">
     <li>Default
         will be simple case: generate a proxy</li>
     <li>But
         WSDL can require a digital signature header  want to be able to have
         WSDD on client side to deploy a chain that includes a digital signature
         generator.</li>
     <li>Doug:
         where to get digital signature handler?</li>
  	   <ul>
     <li>Steve/Glen: wsdl can include pointer to handler.</li>
     <li>Glen: there are extension elements in
         WSDL.</li>
  	   </ul>
     <li>Added
         as wish proxy generation from wsdl (and wsdd). Stated: java, possibly c++</li>
    </ul>
   </ul>
   <li>Platform</li>
   <ul type="circle">
    <li>Surprising
        amount of interest in doing C++ implementation (Glen, Steve, Jacek) for
        performance, but was listed as wish [P5]. Background: James Snell added this, including
using local
        services (e.g. COM).</li>
   </ul>
   <li>Transports
       </li>
   <ul type="circle">
    <li>SMTP
        sender and POP3 poller.  Assume external mail server
        available.  This is what
        Apache SOAP 2 does.</li>
    <li>Glen:
        do we want to provide a generic (fast) transport between handlers?</li>
    <ul type="square">
     <li>Transport
         Sender</li>
     <li>Glen:
         all transport-specific chains end in a router. Oops, maybe not; if no router at end,
look at target
         service field and if not null, invoke that service; then look <i>again</i>
to see if target service is not null.  Loop until null.</li>
     <li>Order</li>
     <ul>
      <li>Transport
          chain  no router</li>
      <li>Global
          chain  no router</li>
     </ul>
    </ul>
    <li><i>(Lots
        of discussion on axis engine and dispatching)</i></li>
    <li>Jim
        asked whether any of these transport cases could be punted  these
        asymmetric cases of HTTP request asking for SMTP response. Glen, Steve, Jacek all
said no, we
        need to support all of these.</li>
    <li>(Discussion
        over how to send asymmetric response to request sent over one-way
        protocol: callback, or configure in a Transport Sender and if return
        message is non-null, send and then null out return message so it. Callback or null-out
message? Steve and Jacek: putting up to
        committer vote would be a big morass? Jacek: ok, grumble, fallback.</li>
    <li>Doug:
        are we going to support multi-cast? Jacek: why not? Jim: why?</li>
    <li>Things
        that Transport Listener must call and set:</li>
    <ul type="square">
     <li>Static
         handler Axis.getHandler(String tlID);</li>
     <li>Request
         chain bag ID</li>
     <li>Response
         chain bag ID</li>
     <li>Target
         bad ID</li>
     <li>Transport
         Sender</li>
    </ul>
    <li>Jacek
        prefers many small registries over fewer larger ones. Glen said that smaller hash
tables
        perform lookups faster.</li>
    <ul type="square">
     <li>Services (deployed handlers)</li>
     <li>Handlers
         (available handlers)</li>
     <li>(After
         much discussion, settled on 2)</li>
    </ul>
   </ul>
   <li>Data
       Encoding</li>
   <ul type="circle">
    <li>Steve:
        (de)serialization only makes sense for RPC, not document handling.</li>
    <li>Jacek
        would love to see general serialization at 1.0 release.</li>
    <li>Serialization
        may occur anywhere, not in one fixed place in Axis architecture.</li>
   </ul>
  </ul>
  
  
  <h2>Streaming Parser Discussion</h2>
  
  <p>For reading in input, we use the PDOM model - <br/>
  We have either a SAX event source or a pull parser underneath something that looks like
JDOM.<br/>
  In the SAX case:<br/>
  <ol>
  <li>a thread starts processing the SAX event stream, and blocks until told to continue.</li>
  <li>When people ask for a particular element (i.e. getNextChild()), the parser thread
unblocks, and runs the SAX event stream through, building up the JDOM object model, until
it gets to the desired element/attribute/etc.  Then it blocks again, and returns control to
the getWhatever() API.</li>
  </ol>
  </p>
  Sot the Message API gets: (or maybe JDOM gets the latter three)<br/><br/> 
  <code>
  getAsElement()<br/>
  parseAsSAX(SAXHandler)<br/>
  getAsXMLStream()<br/>
  getAsByteStream()<br/>
  </code>
  
  <p>Does getAsByteStream() terminate the option of doing anything else afterwards?</p>
  
  How do we test this?  Metrics:
  <ol>
  <li>Use PDOM, read first few elements, then stream rest to file</li>
  <li>Use JDOM, process first few elements, then write to file</li>
  <li>Stream bytes from file to file</li>
  </ol>
  <p>do this for small (1K), medium (50K), and large (10 meg) files</p>
  
  <p>On the output side, we should be able to setAsStream, and hand the element a stream
which will eventually be pulled for content when someone does a getAsStream() on the whole
doc.  This means a proxy stream which clunks its way down the message, draining streams it
encounters along the way.</p>
  
  <p>Open question - is it easy/efficient to get a JDOM Element as a stream/string,
as opposed to a whole doc?  Looks like Element.getSerializedForm() isn't implemented yet?</p>
  
  <p>Pull parser discussion - if possible, a real pull parser would avoid the multi-threading,
and probably perform better than the SAX-based PDOM model.  We'll look into this!</p>
  
  <hr/>
  
  <p>Project Participants:</p>
  
  <ul>
   <li>PM: Waqar
       (Vitria)</li>
   <li>Coders:
       Doug, Steve, Glen, Jacek, Jim, James, Yuichi, Ryoh</li>
   <ul type="circle">
    <li>Glen
        and Doug can work on this a lot</li>
    <li>James
        doing stuff</li>
    <li>Steve
        doesn't have much time for coding</li>
   </ul>
   <li>Others:
       George, Chris Nelson, Kevin Mitchell, Sanjiva, Matt, </li>
   <li>Sam
       for political and process stuff.</li>
   <li>Connection
       to XML Protocol: Glen, Waqar, Jacek</li>
   <ul type="circle">
    <li>Stuart
        for Conversations</li>
   </ul>
   <li>Connection
       to Apache 2.x: Doug, Glen, Sanjiva</li>
   <li>(Glen:
       SOAP 2.1 documentation is bad, could impact us  less credibility).</li>
  </ul>
  </p>
      </section>
    </body>
  </document>
  
  
  
  1.1                  ws-axis/site/src4forrest-060/java/src/documentation/content/xdocs/docs/ms-interop.xml
  
  Index: ms-interop.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd">
  <document> 
    <header> 
      <title>WebServices - Axis</title> 
    </header> 
    <body> 
      <section>
        <title>WebServices - Axis - Summary of Apache/Microsoft Interoperability Meeting</title>
  <p>
  Summary of Apache/Microsoft Interoperability Meeting<br/>
  March 12-14, 2001
  </p>
  <p>
  From Apache: Glen Daniels, Jim Stearns, Doug Davis<br/>
  From MS: (main contacts) Keith Ballinger, Andrew Layman, Eric Andrae
  </p>
  <p>
  Most of the 3 days were spent testing Apache SOAP v2.1 and Axis against
  the 5 different versions of SOAP MS has (one being an IE client).
  Since Axis doesn't have serialization support yet (just Strings) it
  was limited in what it could do, but for those simple tests that
  did NOOPs or tested Strings it did ok as a client and a server (just
  a few minor tweaks were needed).
  </p>
  <p>
  Apache SOAP v2.1 did much better.  There were a few bugs (and holes)
  that were discovered but Glen was able to track them down and, I think,
  fix all of them.  He's in the process of trying to see if the
  fixes can be integrated back into the cvs tree, but is unsure about
  one of the fix's impact on the MIME support - but we'll see.
  </p>
  <p>
  MS has 5 different versions of SOAP and they've been doing some of
  their own interoperability testing internally so I think they were
  able to flush out most(all) of their differences before we got there.
  However, we did manage to find a bug (or two?) in their code 8-)
  but overall they had things pretty well covered.
  </p>
  <p>
  For better or worse, MS is very WSDL dependent. If the industry is
  headed down the path of basically requiring WSDL then Apache might
  need to do so as well.
  </p>
  <p>
  We had two strategy meetings in which we discussed how to improve
  interoperability testing/conformance in the future, not just between
  Apache and MS but everyone.  We decided to set-up a consortium in
  which different SOAP implementations can join and test their version
  of SOAP against the others in the group.  The main purpose of the
  group would be to focus attention on interoperability issues and not
  necessarily prove conformance to the SOAP spec.  While we will have
  testcases that we "believe" test some aspects of conformance we can
  not be the defining authority on who is, or is not, spec compliant.
  All we can do is pretty much help people say that their SOAP code
  can, or can not, play nicely with others in the group.  That being
  said, there are some definite MUSTs and MUST NOTs in the spec and
  we will have some tests that test those so we'll be walking a fine
  line.
  </p>
  <p>
  We will also group tests based on sections of the SOAP spec.  Not
  everyone will want to implement all sections of the spec but will
  still want to test conformance based on what they have implemented.
  </p>
  <p>
  To help this "consortium" we're going to set-up a web site
  (Jim has already reserved wsinterop.org and soapinterop.org) where
  people can post their testcases and test results.  We also talked about
  having pointers to "live" servers that people can hit to test their
  SOAP implementations.  It wasn't decided how Apache will work this.
  <br/><b>****TODO*****</b><br/>
  We need to get someone to volunteer to set this up/host it.
  </p>
  <p>
  Along the lines of getting interoperability, we discussed showcasing
  how nicely we're all playing together.  8-)  In particular we
  discussed having a live demo at a conference (maybe NetWorld Interop
  in May) where people can hook up their machines in our network of
  computers and join in "the game".  "The game" will consist of a fairly
  simple maze type of game - each server will own a certain number of
  rooms and clients will be able to walk from room to room examining,
  and placing, objects in each one.  We'll define a set of base SOAP 
  interfaces that people will need to implement and if they do then
  they should be able hook-in their server and extend the maze.
  </p>
  <p>
  Glen is working on the write-up of the overall idea and will
  distribute it once it's done.  In order to help things along we
  agreed to try to have another F2F around the end of April where we
  will all get together in a room to hash-out the details of the
  game/interfaces and to actually code it up.  I (Dug) have agreed to
  see if IBM will host it in Raleigh.  Glen is going to see if 
  Allaire (aka Macromedia) will be willing to work on the GUI that
  the main-server will use to display the status of the game.
  </p>
      </section>
    </body>
  </document>
  
  
  
  1.1                  ws-axis/site/src4forrest-060/java/src/documentation/content/xdocs/docs/SOAPVerse.xml
  
  Index: SOAPVerse.xml
  ===================================================================
  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V1.2//EN" "./dtd/document-v12.dtd">
  <document> 
    <header> 
      <title>WebServices - Axis</title> 
    </header> 
    <body> 
      <section>
        <title>WebServices - Axis - SOAPVerse</title>
  <p>
  Hi folks!
  </p>
  <p>
  This is a quick writeup of an idea that a bunch of folks had last week while
  discussing interoperability demos and tests. It's a pretty simple system
  which we thought was a) fun, b) technically interesting, and c) quite a
  compelling demo. I'd like to know what people think of the idea - is this
  too ambitious, is it something you'd be psyched to help design/implement,
  is it cool?
  </p>
  <p>
  The SOAPVerse : A long-term SOAP interoperability demo<br/>
  ------------------------------------------------------<br/>
  </p>
  <p>
  [1.0 Introduction - the view from outside]
  </p>
  <p>
  I'll start explaining the idea by giving a brief scenario. You connect a
  browser to SOAPVerse.org, which gives you three choices - 1) enter the
  SOAPVerse, 2) look at the map, and 3) learn about joining. You choose #1,
  and are offered a list of available clients and "entry portals" (i.e.
  clients (no, not "IE clients", necessarily...)) on the web. You choose a
  local entry portal, and a Java applet appears, primarily composed of a text
  window:
  </p>
  <p>
  --------------<br/>
  SOAP Tower<br/>
  </p>
  <p>
  You stand in the SOAP tower. The floor's a bit slippery here, but you
  suspect you could make it to the exits to the NORTH or EAST if you walked
  slowly.
  </p>
  <p>
  There is a briefcase sitting here.
  </p>
  <p>
  (this room lives at foo.ibm.com, and is powered by Tomcat/Apache-SOAP 2.1!)
  --------------<br/>
  </p>
  <p>
  It's a text adventure, much like Zork or Colossal Cave, but a lot simpler.
  The interesting part happens when you move to the East:
  </p>
  <p>
  --------------<br/>
  [a strange feeling overcomes you for a moment as you pass through the door]
  </p>
  <p>
  Campus West
  </p>
  <p>
  You stand on the Microsoft campus, near building 33. You may ENTER, or
  travel WEST or SOUTH down the main road.
  </p>
  <p>
  Others in this room : KeithB
  </p>
  <p>
  There is a rubber ducky sitting here.
  </p>
  <p>
  (this room lives at bar.microsoft.com, and is powered by IIS/ASP.NET!)<br/>
  ---------------<br/>
  </p>
  <p>
  What just happened is that you smoothly and transparently moved from one
  SOAP-based server to another. The servers had to interoperate to "pass you
  off", and anyone who wants to go check out the website can see the deeper
  technical explanation of what's going on.
  </p>
  <p>
  If you'd selected the "map" option, you'd see a cool graphical depiction of
  the whole graph of rooms currently connected to the SOAPVerse, color-coded
  by host/server technology.
  </p>
  <p>
  [2.0 Digging a little deeper]
  </p>
  <p>
  That's the basic idea - a totally distributed text adventure game that
  demonstrates SOAP interoperability at a number of levels. The actual APIs
  are pretty simple, and should be implementable in few days at the most.
  </p>
  <p>
  So if you go to the "join us" section of the site, you end up with several
  things. First, a description of the structure of the application, in
  enough
  detail that you could implement it on your own site. This can (and should)
  be in as many forms as possible - english text, WSDL, SDL, IDL, etc....
  So you build the server to the spec, in any language/environment/platform
  you happen to have handy.
  </p>
  <p>
  Next, you find a form which allows you to test your server once you've got
  it up. This causes the SOAPVerse server to run a series of tests against
  your endpoint, to see if you can interoperate with it. Assuming that
  works,
  you can click "hook me up!" and the SOAPVerse server randomly picks a place
  on the graph to add your area, and matchmakes a connection between your
  server and whoever you're connecting to. The tests should get run again
  between you and this new guy, to make sure you two interoperate (you don't
  want to just prove interoperation between the "main" server and your impl),
  and then if everything looks good, you're now a part of the world, and your
  rooms appear on the master map.
  </p>
  <p>
  There's some more detail about which kinds of things we're testing with a
  system like this (data serialization, headers, intermediaries?), actual
  APIs,
  etc. but I'll convey my thoughts about that in a design discussion if
  there's
  enough community interest in this project.
  </p>
  <p>
  [3.0 Musings]
  </p>
  <p>
  This kind of thing serves at least two purposes. First, it can stay up in
  perpetuity, demonstrating SOAP interoperability in a fun way. This should
  be something you can always find, and hook new servers into. Second, it's
  a
  good demo for tradeshow-type events.
  </p>
  <p>
  Obviously there's a lot of opportunity for errors to happen here, so the
  system shouldn't assume too much about robustness, and should gracefully
  fail in the face of problems. It's meant as an interoperability demo,
  not a full-scale game.
  </p>
  <p>
  None of this is at all carved in stone, we just liked the basic idea. It
  shouldn't get too complicated, and it shouldn't rely on any particular
  implementation.
  </p>
  <p>
  If this could get done by late next month, this could be the actual
  technolgy
  for the "interopathon" demo which has been discussed for NetWorld/Interop
  in May.
  </p>
  <p>
  What do you think?
  </p>
  <p>
  --Glen
  </p>
      </section>
    </body>
  </document>
  
  
  

Mime
View raw message