Re: [soa-rm] SOA-RM Outline and Glossary

[Matthew MacKenzie <mattm@adobe.com>]

I'm not opposed to providing the information, just where it is provided :-)

-matt

Francis McCabe wrote:

> Everyone who reads the RM will be coming from their particular PoV. 
> Security is up there in the first 3 considerations people have about 
> distributed systems. If we do not address it directly we will be 
> criticized.
>
> The point of the stakeholder's sections is to act as a set of primers 
> to the RM itself; to embed it in the wider context. That could be done 
> in separate documents; but why make someone read 4 documents (with 4 
> sets of introductions, etc. etc.) when a pertinent section in one will 
> do the job.
>
> The other major driver behind that section is to help people 
> understand how to extend the RM to fit their particular needs. 
> Security happens to be a good example in that case; but its not the 
> only possible one -- manageability comes to mind, deployment, 
> realization in Java, ...
>
> Frank
>
>
> On Apr 12, 2005, at 6:47 AM, Matthew MacKenzie wrote:
>
>> I don't think we should include "why we didn't" sections in the 
>> normative part of the specifciation, or even applied RM sections 
>> (WS-*).  These should be in separate documents, IMO.
>>
>> -Matt
>> Francis McCabe wrote:
>>
>>> Potential stakeholder's perspectives
>>>
>>> This is where we directly address our audiences:
>>>
>>> 1. SOA for busy executives
>>>     i.e., what are the benefits of SOA, what architectural 
>>> constraints are *of the essence* and how to use the RM.
>>> 2. SOA and security
>>>     i.e., explaining why security per se is not a direct part of the 
>>> RM, but how different security considerations may be layered on top 
>>> and how that fits with the overall structure.
>>>     This one is also good for another reason: anyone wishing to 
>>> ensure some -ility on their particular architecture will want to 
>>> know how to map their requirements on to what is offered.
>>> 3. SOA for developers
>>>     I.e., what are the primary constraints implied by the 
>>> architecture -- as well as those that are *not* implied. How is 
>>> scalability achieved in the RM and what you need to look out for in 
>>> order to achieve scalability in your architecture. More generally, 
>>> how should you ensure that your architecture is a good example of an 
>>> SOA. How to fold legacy stove-pipes into you new SOA systems.
>>> 4. SOA for Web services
>>>    I.e., how does the RM differ from Web services, how do the WS-* 
>>> specs fit into the RM framework.
>>>
>>> Frank
>>>
>>>
>>>
>>> On Apr 11, 2005, at 1:04 PM, Thomas Erl wrote:
>>>
>>>> Frank,
>>>>
>>>> For those members not familiar with the W3C Web Services 
>>>> Architecture document, could you share your thoughts as to what 
>>>> would go in a potential "Stakehohlder's Perspectives" section for 
>>>> the SOA-RM?
>>>>
>>>> Thomas
>>>>
>>>> ----- Original Message ----- From: "Francis McCabe" 
>>>> <fgm@fla.fujitsu.com>
>>>> To: "Thomas Erl" <terl@serviceorientation.org>
>>>> Cc: <soa-rm@lists.oasis-open.org>
>>>> Sent: Monday, April 11, 2005 9:11 AM
>>>> Subject: Re: [soa-rm] SOA-RM Outline and Glossary
>>>>
>>>>
>>>>> +1
>>>>> Frank
>>>>>
>>>>> On Apr 10, 2005, at 11:30 PM, Thomas Erl wrote:
>>>>>
>>>>>> During our last conference call Frank McCabe suggested that we 
>>>>>> consider
>>>>>> using the W3C Web Services Architecture 
>>>>>> (http://www.w3.org/TR/ws-arch/)
>>>>>> document's outline as the basis for our reference model outline. 
>>>>>> The parent
>>>>>> level sections of this outline are as follows:
>>>>>>
>>>>>> 1 Introduction
>>>>>> 2 Concepts and Relationships
>>>>>> 3 Stakeholder's Perspectives
>>>>>> 4 Conclusions
>>>>>>
>>>>>> The W3C supplements this document with a separate glossary. As 
>>>>>> per Ken's
>>>>>> suggestion, we may want to consider adding a glossary as a fifth 
>>>>>> section or as an appendix.
>>>>>>
>>>>>> Thomas
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>