axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eoin Lane <>
Subject RE: Architecture guide : comments
Date Wed, 09 Jan 2002 10:30:49 GMT

I really like your document and coupled with the code I was, as a first
timer, able to navigate my way through it. It did take a couple of reading
though :).

My comments, which are v small, are more about expanding and clarifying what
you have already written. I would like to see a clarification, maybe in term
of a class diagram, to explain the complex polymorphic behavior between
Handlers, Chains, Target Handlers, etc. I have a first draft of one, which I
developed when I was trying to understand the relationship myself, and would
be glad to forward it on to you. 

I think it would also be beneficial to show some very simple sequence
diagrams detailing the message flow, on the server, from the Transport
Listener though to the Axis Engine and on through the various Handlers,
Chains, and pivot. This could also be possible from a client view.

One of the key diagrams in the document in terms of my understanding is
'laying of subsystems' diagram and I would like to see this expanded and to
show how the modularity of this approach can lead to the addition of other
services, providers and transports.

Finally I agree totally with your view that the fundamental architecture of
the message process should be achieve with the primitive notion of request,
pivot, and response Handlers as against the abstract notion of the three
layers of handlers. Simplicity here is the key :)

Hope this helps any bit,



> -----Original Message-----
> From: Glyn Normington []
> Sent: 08 January 2002 14:11
> To:
> Subject: Re: Architecture guide : comments
> Glen,
> I really appreciate your comments. Please keep 'em coming!
> >Hi Glyn!  I think this is a good start on expanding the text in the
> >integration guide, but could use a little editing.  Some comments:
> >
> >I'd prefer to see the "meta" discussion (things like "The relationship
> >between these subsystems needs to be documented and somewhat cleaned
> >up...") elsewhere. These are great topics for emails, but shouldn't,
> >IMHO, go in the actual document. Ditto for the questions. In various
> >places you say "we need to decide...", which I think detracts from
> >the purpose of an architecture document.  An "open issues" section
> >would be fine at the end, but the main meat of the document should
> >be explanations of what we have decided and how the system actually
> >works. It should read crisply and clearly, without venturing
> >off into speculation and questioning much at all.
> Point taken. I've put the issues and questions in an "Open Issues" section
> at the end. I prefer not to remove them from the document entirely as then
> it might falsely appear to be finalised: in its current form, the guide
> should be read with healthy skepticism, especially given that I'm really
> trying to second guess the architecture mostly from the code. I'll
> initiate
> email threads on specific issues as you suggest.
> >Message Path on the Server - I'd pull "for instance when there is a
> >response message".  The path is the same whether or not there is an
> >actual response generated (i.e. the response handlers still get called,
> >since they might do things like stop timers, clean up resources, etc).
> >Ditto for the client.
> Pulled. I've noted the pont about the message path when there is no
> response.
> >We should make it clear that the connection between the "pivot" in
> >the client side diagram and the "Target Service" is in fact usually
> >sending SOAP across a "wire" of some kind.
> >Show the little cloud and a SOAP message traversing it, etc.
> >Also, I'd call the pivot in this diagram the "sender" to follow along
> >with the text.
> Clarified.
> >"Parsing / encoding" and "Message model" are probably other good
> >subsystems to note.  I'd call the "dispatcher" subsystem something
> >like "processing flow", since it seems like more than just simple
> dispatching.
> I've added "encoding" and "message model" subsystems sitting on top of the
> "dispatcher" which I have renamed to "message flow". I'd be interested to
> know whether the "encoding" and "message model" subsystems are orthogonal
> to the other subsystems on top of "message flow". Also, I'd be interested
> in what classes should be included in each of these subsystems. I've added
> issues to cover these queries.
> >The fault model consists of more than just the onFault() method.
> >There is also the "faultFlow" stuff in WSDD which causes the
> >creation of a "FaultableHandler", which serves to wrap another
> >Handler, catching exceptions and potentially invoke()ing other
> >Handlers to deal with the Fault. See and
> > for more.
> I've added a place-holder for this and a question in the Open Issues
> section.
> >OK, bedtime for me, more later.  This is a great start, let's keep
> >the momentum going!
> Glyn

View raw message