new SOAP/XML forum at IBM site

[graham glass <gr...@mindspring.com>]

FYI, there's a new SOAP/XML forum at the IBM developer site:

http://www.ibm.com/developer/xml/

it has just been launched.

cheers,
graham

-----Original Message-----
From: James Snell [mailto:jmsnell@intesolv.com]
Sent: Tuesday, December 12, 2000 12:18 PM
To: 'soap-dev@xml.apache.org'
Subject: RE: Notes from the F2F


Comments inline ( look for <js></js> )

-----Original Message-----
From: Glen Daniels [mailto:gdaniels@allaire.com]
Sent: Tuesday, December 12, 2000 9:30 AM
To: 'soap-dev@xml.apache.org'
Subject: Notes from the F2F



First of all, thanks to all who attended last week's F2F meeting in DC!!

Vahe Amirbekyan
Wouter Cloetens
Glen Daniels
Doug Davis
Diane Davison
Jean-Noel Gadreau
Jim Gloor
Steve Graham
Jacek Kopecky
Bruce Lowenthal
Yuhichi Nakamura
Simeon Simeonov
Sanjiva Weerawana

(did I forget anyone?)

OK, so this is a note to summarize the discussion we had.  It's pretty raw,
as I don't have much time before I leave for Seattle and I want to get it
out before I go.  Apologies in advance for not being as detailed as I'd
like...  In general, the discussion was very productive, and I think we're
well on our way to an architecture which we can write up and begin
implementing as a real Axis codebase.  I believe the next step might be to
get an architecture doc together and get committers to agree on it, but
that's open for discussion.

Basically, we spent about 6 hours on Wednesday night, and another 2 and a
half on Thursday morning discussing Axis.  We started by going over the
requirements list, which generated the new list that Jacek posted yesterday.
That took a few hours (OK, I guess 20 minutes was a little unrealistic :)),
since we ended up doing a lot of technical discussion as a part of the
requirements editing process.  This was a good thing, as it set the stage
for the rest of the discussion very nicely.


<js>

	6 hours? oy-vey! Sounds like it was productive ;-)

</js>


We finally got to the presentations at around 10PM, and whizzed through
quick 10 minute versions of everyone's talks.  It was clear that we had a
lot of overlap in our architectures, with the major difference being whether
or not a given Handler has access to both the inbound and the outbound (i.e.
request and response) messages.  Alas, I don't have time right now to
summarize this whole discussion, but perhaps someone else can do it?

Major issues we came up with:
1. Rename "Message" to be something else, since it can actually contain MIME
attachments, context information, etc.


<js>

	"Envelope" ?   <-- I'd vote for this one
	"Package"  ?
	"Packet"   ?

</js>


2. To switch or not to switch?  In other words, do Handlers have "inbound"
and "outbound" and then switch at the turnaround point, or do they just have
a single message which some handler knows to change into the response at the
right time?


<js>

	In other words, (S = Send, H = Handler, R = Response)

	this:  S -> H -> H -> H -> H     <-- Input chain
             R <- H <- H <- H <- H     <-- Output chain

	or

	this:  S -> H -> H -> H -> H -> H -> R   <-- Single chain

	I would vote for number two for two reasons:

      1. It simplies the architecture.

      2. It helps to abstract the differences between Request/Response,
Intermediaries, and One-Way Services.  Take the following examples:

	A. Request/Response:  S -> {RPC Handler} -> R
		In this instance, the pipeline configuration would indicate
that R = S.  The RPC Handler would not have to know about it, then engine
takes care of the routing.

	B. Intermediary: S -> {Intermediate Handler} -> R
		The pipeline configuration indicates the address of R.

	C. One-Way Server: S-> {One-Way Handler}
		The pipeline configuration does not define R so that know
message is sent

	In my opinion, it is important to keep in mind that SOAP is defined
as "one-way messages" that CAN be used in a request/response pattern.  Using
the Input/Output Chain model can potentially force the request/response
model.  Thoughts?


</js>


3. What is the type of the inbound and outbound thing?  It's usually a
SOAP/XP envelope, but could be a JPEG, or a variety of other things as
well...

<js>

	A raw binary stream parsed by pluggable parsers/encoders.

</js>


4. How do we deal with serialization/encoding?

<js>

	Pluggable Serializers/Encoders registered with each chain?
Something like:

	<chain parser="soap.parser" encoder="soap.encoder">
		<handler/>
	</chain>

	This could define a default parser/encoder that each handler could
override if it wants to.  The parser and serializer can be accessible via
the context:

	function handleMessage(Context ctx) {

		/* uses default parser to build canonical envelope object */
		Envelope env = ctx.parseEnvelope();

		/* or */

		/* override the default parser with custom parser */
		XPParser xparse = new Apache.XPParser(ctx.rawEnvelope);
		Envelope env = xparse.parseEnvelope();
	}



</js>

5. Are the handlers/chains allowed to have state?  If so, how is it managed?


<js>

	Preferrably no-state, although I can imaging maintaining a pool of
handler instances configurable by the administrator.  By maintaining a pool,
the handlers could maintain state but it would not be safe to do so.

</js>

Here are the notes taken at the meeting:


WEDNESDAY'S DISCUSSION NOTES
----------------------------

Much discussion about the API/structure of the MessageHandlers.

Suggestion that we spec out both "versions" and vote... (i.e. one message,
or inbound/outbound)

Need discussion of Fault patterns.


<js>

	For Every 1 Chain, x Number Of Fault Chains:

		<chain>
			<primary>
				<handler/>
				<handler/>
			</primary>
			<Fault name="fault_name_1">
				<handler/>
			</Fault>
			<Fault name="fault_name_2">
				<handler/>
			</Fault>
		</chain>

	Each Fault chain can be individual invoked by the handlers by
something similar to:

		throw new AXISException("fault_name_1");

</js>

There may be some stuff in the Context which is engine-writable only (for
instance, response handlers shouldn't be
able to CHANGE the "original" message)

Sessions - Should we have a transport-independent session concept?  How to
implement?  Suggestion to put a Session  object of some sort into the
Context, which can be used by handlers.  Suggestion that it *shouldn't* be
in the  context.  Discussed the fact that all handlers might need this, not
just end-handler (i.e. application).

<js>

	I would vote for making the context = session.  In other words, for
every Envelope, there is a context object, we can provide a ContextID
property and a method of storing and retrieving Context State.

</js>

SOAP itself could be just a (set of) handler(s), and other protocols
implemented the same way....?

<js>

	SOAPRPCHandler
	SOAPParser
	SOAPEncoder

</js>



<js>

	Another thing to also keep in mind that I have just recently thought
about.  Let's say that we have three handlers in the chain (S -> H1 -> H2 ->
H3 -> R).  H1 adds a SOAP Header with a mustUnderstand = 1 attribute and an
actor attribute = H2.  H2 must be able to determine whether or not it
understands the Header.  In other words, whereas we had been figuring that
mustUnderstand Headers could be figured out when the message is first
received, we may need to consider the case that mustUnderstand headers must
be determined by each individual handler.


</js>
------------------------------------------------------------

THURSDAY'S DISCUSSION NOTES
---------------------------

Discussion of stateful vs. stateless handlers/chains.  Should the handlers
be thread-safe or should they be cloned and/or pooled?  Where do stateful
handlers keep their state?

<js>

	-1 on stateful handlers.
	+1 on optional pooled handlers.
	+1 on thread safe.

</js>

a) in the object - need multiple instances
b) in the context - per message, or maybe per chain container
c) in some external state-management framework ala EJB... this requires some
sort of load()/store() methods.

Handlers might need an "init()" method to let them deal with any resources
they need to get ready.

<js>

	This can be done in the constructor/deconstructor

</js>

4 possible contexts for state:
- Message
- Session
- Service
- Server

<js>

	+1 on Service and Server Context.

	I think that the Message Context can equal Session context.

</js>

There is some server-specific config which needs to get set up at init time
(db connection pools, etc)

---------------------

Q: what order do the handlers get initialized in?  Can this be concurrent?

<js>

	If not pooled: handlers initialized per message

	If pooled: x-number of handlers initialized on service startup

</js>

There needs to be a "programming model guide" for this which explains that
if you rely on serial initialization for  the handlers (order dependency),
you may get screwed when the engine changes later.

What about the concept of handler configurations being external to the chain
definitions?  You could then reference  them just like you compose chain
definitions.... (i.e. you can use the same handler configuration in multiple
chains without repeating it)

<js>

	Interesting idea.  I'll have to give it some thought.

</js>

Deleting handler types / chains - if you try and delete a handler type which
is currently in use, you can't until  you undeploy all services with that
handler.

<js>

	Agreed.

</js>

Q - what is an "envelope" anyway?  In the face of MIME returns and such...
should there be a different object for  input/output streams, JPEGs, etc...

<js>

	One raw-binary stream containing the message data, whatever it is,
the pluggable parser takes care of the details.

</js>

Suggestion that everything that flows around should be XML - if you want
Java, you need to do that yourself and if you want to share  your Java
objects, you have to do it through the context.  Is there a use case where
you need to pass Java objects?   When would a header handler, say, need
access to the Java version of the Body?

<js>

	Hmmm... I think sticking to native types within the engine is the
most efficient.

</js>

SAX/DOM issues - can handlers take a stream-based representation of the Body
instead of DOM?  SCalability and  performance are really critical in B2B
applications, so even if it's harder to deal with,

<js>

	If the message data is passed around as a raw binary stream with
pluggable parsers, the pluggable parsers can do whatever they want, SAX,
DOM, or mystic incantations.

</js>

Vahe brings up Object-by-reference as an important extension.  General
agreement.

<js>

	In exactly what context? RPC?

</js>