OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebsoa message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Agenda (provisional) for 5.26 Call


I am traveling during the call so I leave this to the vice chair to sort 
out.

1. Roll call
2. Appointment of minute taker
3. Approval of agenda
4. Discussions:
a. SOA - defined as an architectural paradigm. (Everybody please read 
the existing document to see if you agree with what has been written so 
far please). There is a very clean definition of what SOA is within the 
community and perhaps already captured within our document draft. 
Discussion could perhaps focus more on who our key audience is.

Possible action item: Agree to Abstract on current draft or propose 
rewording it to reflect consensus.

Ditto with "Introduction"

At this point, let's not wordsmith too much. This is just a stake in the 
ground to get rolling.

b. The Patterns of SOA. So far there are two documented in our draft. Is 
this going in the right direction? What are the other 
ingredients/components of SOA? What needs to be done next to develop SOA 
draft (continue with Patterns by adding in more components?).

c. Whatever else the group decides is worthwhile.

My personal views: (in response to Sally's thread).

We do not have to completely redefine SOA and Even driven architectural 
paradigms but do have to realize how to capture the different views of 
it depending on the audience. We have a good start now with several work 
items defined. I would like individuals to pick up work items for the 
group and complete them.

Also - The skeleton for the draft is as follows:

3 SOA Architectural Patterns: What, Why & How
This paragraph should discuss what is meant by the term architectural 
patterns.

3.1 The SOA Pattern Notation
This section describes the template we are using for the definition of 
patterns.

3.1.1 Business Requirements (Scope) View
Goals, requirements, etc.

3.1.2 Business Model View
Conceptual view of processes.

3.1.3 System Model View
Technical view of processes (design).

3.1.4 Technology Model View
Implementation details.

3.1.5 Data Model View
Bits getting moved to and fro.

Let's agree on this. These are classical architectural views as 
discussed in the book Matt referenced and generally accepted conventions 
for defining architecture.

I personally believe this is a great outline to start with.

Sorry I cannot be there tomorrow.

Thanks

Duane

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]