Action item on document work from F2F

Hi,
 
Attached is an update to the WSA document based on an initial attempt at exploring some of the suggestions from the face to face document breakout team.  Also attached is a diagram to illustrate the service oriented architecture concept, which I'll explain presently.
 
First, the document now includes this new material:
 
-- In Chater 1, a section introducing WSA as Service Oriented Architecture (I'll explain the reason for this below).
-- In Chapter 1, a "contract" with the reader 
-- In Chapter 3, a "trial" section on presenting the architecture in terms of its core concepts and relationships
-- In Chapter 5, a section on "stakeholder view" to illustrate this type of information might be presented
-- Some additional annotations with regard to additional possiblilities for changes and where to place David Booth's text on discovery (possibly chapter 4?)
 
New material is bracketed using horizontal rules.  I did not change anything existing text, but if the new approach seems to work out I will start to do so.  The new material is also attached as a separate file to make it easier to read just the new parts.  Existing text was used as the basis for the proposed new section on concepts and relationships.  If the new approach goes forward, a next step would be to repurpose the rest of the existing text into the new format(s).
 
The proposal was reviewed and discussed briefly during the editors' concall today.  It was noted that the concepts section overlaps with the glossary and we would need to ensure consistency across them and ensure the right topics and level of detail of is included for each.
 
Another comment was that the concepts section as organized is difficult to approach from the point of view of gaining a quick understanding of the architecture and its main elements.  A possible solution would be to include some overview or introductory material at the beginning of the more formal section so that it would be easier for the reader to pick up on key concepts and ideas.  
 
Katia submitted several comments on the concepts and relationships text, but because we are not yet changing document content, I did not process them.  I also had several comments, and included them as annotations prefaced by EN (my initials).
 
I added a section on service oriented architecture to the proposal we discussed at the F2F.  In reading through the concepts and relationships section, it occurred to me that it would help if we had a common frame of reference.  In other words, in listing the core concepts of the architecture and their relationships, it seemed like it would help to have some overall definition of the architecture itself in mind.  So I thought of introducing the idea of the WSA as an instance of a service oriented architecture.  
 
The SOA for WSA would be a fairly abstract instance of the type, with only a transport, services, and descriptions as the core ideas.  I tried to represent this in a drawing, which I've also attached.  Services interact with each other over the transport, and anything visible to the application is modeled as a service (this does not imply any mapping to physical execution entities such as address spaces, operating system processes, JVMs, etc.).  Some concepts might relate only to the transport, such as transport level reliability that's invisible to the application.  Other concepts might involve both services and the transport, such as security.  Security is often talked about as a context on the wire, or that the transport has to handle.  But I think it's equally valid to say that the context has to be created and managed by a service.  If the service context in the transport represents the authentication token from a sign-on, for example, the security "service" (at least in the abstract architectural model) is what checks the username/password and returns the token. Anyway other instances of services would include transactions, choreography, and discovery. 
 
To reiterate the proposal for the new approach, we were focused on the following:
 
-- Clearly state the contract with the reader (who it's for, what to expect, and the approach to formalism used)
-- Redo the existing text to more formally present core concepts and their relationships -- as the kind of architectural foundation
-- Reorganize existing text at the next level (i.e. proof points of the architecture, overarching concerns, and usage patterns) more formally as qualities, capabilities, and constraints of the architecture -- in the proposal this part of the text is called "stakeholder views" to reflect the idea that in this section we're effectively validating and verifying the various requirements in the requirements doc
 
Breakout team, please let me know if I've forgotten to cover something!  
 
Thanks to Frank, Katia, and Zulah for their continued participation in the breakout team work after the meeting.  I believe we have now delivered on our action item!
 
Regards,
 
Eric
 
 
 
 

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />



 <http://www.iona.com/> IONA Logo

Eric  <mailto:eric.newcomer@iona.com> Newcomer
CTO 


END 2 ANYWHERE

200 West Street 
Waltham, MA 02451
USA

Tel (781) 902-8366 
Fax (781) 902-8009 
 <mailto:Eric.Newcomer@iona.com> Eric.Newcomer@iona.com