axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Glyn Normington" <glyn_norming...@uk.ibm.com>
Subject Re: Architecture guide : comments
Date Tue, 08 Jan 2002 14:10:48 GMT

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 FaultableHandler.java and
>WSDDFaultFlow.java 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



Mime
View raw message