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"
>>>> <>
>>>> To: "Thomas Erl" <>
>>>> Cc: <>
>>>> 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
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>
