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

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

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


Subject: Re: [soa-rm] comments collected from SOA-RM presentation


Ken:
  Interesting discussion you had...

  I have some comments inline.


On Mar 26, 2006, at 6:41 PM, Ken Laskey wrote:

>
>
> 1.  As expected, there was considerable discussion on how SOA is  
> different, especially how it relates to OO.  Some points from  
> emails, real-time discussions, and after discussions for  
> consideration in expanding our discussion in the RM follow.
>
> - Both OO and SOA are as much a way of thinking about representing  
> things and actions in the world as these are about the specifics of  
> building a system.  The important thing is understanding and  
> applying the paradigm.  So the question is not “what is a service?”  
> any more than it is “what is an object?”  Anything can be a service  
> in the same way anything can be an object.  The challenge is to  
> apply the paradigms to enhance clarity and get things done.

There are some hidden assumption in OO that do not show up in the  
promotional literature. I agree that the "what is an X?" question  
often dominates and it can get heated. But, I would say that OO  
started out as a programming paradigm; SOA starts out as a  
architectural paradigm.

> - You instantiate an object to use it, but you interact with a  
> service where it exists.

I think that this reflects the programming/systems distinction quite  
well.

>
> - An object exposes structure but no way to express semantics other  
> than what can be captured as comments in the class definition.  SOA  
> emphasizes the need for clear semantics.

+1

>
> 2. On descriptions of architectures, someone asked about the  
> relationship to IEEE 1471.  On a quick look, there is somewhat of a  
> different perspective but also many parallels that may be useful to  
> make to better relate to another community.
>
> 3.  Possible one line description of SOA:  A modular design of  
> solutions where the modules are distributed anywhere, owned by  
> anyone, and reused by everyone (in a manner consistent with  
> specified constraints and policies, including those which limit  
> access).

This is more like an RA view of SOA

>
> 4. Possible summary description of execution context:  Given all  
> the possible things under description (e.g. functions and technical  
> requirements, related constraints and policies, mechanisms for  
> access or response), the participants (providers and consumers)  
> must agree and acknowledge a consistent set to use in order to have  
> a successful interaction.  EC is the collection of this consistent  
> set.

+1

>
> 6. There was a question whether an SOA service had to be network- 
> accessible.  What if all the services are on the same machine?   
> What if the data transfer was sneaker-net on a floppy?  The essence  
> of my response (and later thought) was that everything on the same  
> machine and specifically designed just to be on the same machine is  
> not SOA.  Everything can be on the same machine as an  
> implementation but it should have been designed with the idea that  
> it could be distributed and the parts could be owned by different  
> entities.  As far as sneaker-net, that is a data transfer  
> capability that may be brought to bear through a service  
> interaction, but it is an implementation that is opaque to the  
> requester.

I think that, technically, you can go back to a single computer  
system and ask if its SOA-like. But this is where the hidden  
assumptions start to show up again. If you build a system that is  
intended to be used in a single machine then you are not likely to  
follow the constraints and approaches suggested by SOA. You are  
likely to take advantage of the fact that 'everything is close at  
hand'; and, as soon as you do that you will probably stray away from  
the SOA approach.


>
> 7. In formal definition of a service, it say “is accessed by means  
> of a service interface” and the question was whether there can be  
> more than one service interface to the same service.  The answer is  
> obviously yes (I used the example in one of our email threads of a  
> local and metro telephone number to the same pizza parlor) but it  
> may be worth clarifying.
>
> 8.  Point that seemed to resonate but really wasn’t made in RM:  
> entity providing a service may not be the same as the one providing  
> the underlying capability.
>
> 9.  re description:
>
> - is the idea made enough that building description with links aids  
> in reusability and explicit reusability (vice just using the same  
> string as used elsewhere) aids interoperability?  Or is this a  
> point to include in the RA?

I think that this is an important point that we could stress more.

>
> - Is the idea made enough that “description” is the important  
> concept and service description is the one we talk about the most;   
> however, description of needs (the consumer end) is also (equally?)  
> important?

While I agree completely that this is important, and would be a  
central theme of SOA 2.0, I am not sure that the community has  
reached this stage yet. It appears to imply some kind of description  
intersection which is non-trivial to do.

>
> 10.  No one had a problem with the concept of “shared state” but  
> many were confused by the term because they thought of state as  
> being something persistent that changed value.
>
> - Shared state needs to be added to glossary.
>
> - Is there a better term/name or do we need a few more lines of  
> description?

I admit to having some hesitancy over the term shared state; it  
sounds too much like shared data. How about "shared views of the world"?

>
> 11. There is an inconsistency between lines 277-282 and lines  
> 477-480 on how shared state relates to a simple response to a data  
> request.  See <emailDialog> below for some follow-up discussion
>
> 12. Description of reachability in section 3.3.1.1 says metadata on  
> protocols is part of reachability.  Is this consistent with the  
> discussion on reachability in section 3.2.1.3, i.e. reachability as  
> part of visibility?

3.3.1.1 reads that the metadata is part of the description, not part  
of reachability per se. The metadata facilitates reachability.  
Perhaps more text would be helpful here?

>
> <emailDialog>
> [This expands on item 11.]
> 1 - I interpret RWE as result/effect of a service to consumer and  
> provider, especially response of service to consumer.  Why do we  
> need to predicate "effect" with "real world"?  Why not use the term  
> "effect"?
>
> The RWE term resonated and I don't know there was documented  
> rationale.  It follows from the idea that you use SOA to accomplish  
> real things and this is not just an academic exercise.

+1

>
> 2 - Several problems with the term "shared state":
> a) Is the "shared state" the same as RWE?

No it is not. If you follow the "shared views on the world", then the  
RWE is manifested in those shared views: all parties can see that  
there is now a booking.
>
> I think we will need to do some clean-up here.  Note, lines 277-282
>
> The consequence of invoking a service is a realization of one or  
> more real world effects (see Section 3.2.3). These effects may  
> include:
>
> 1.	information returned in response to a request for that information,
> 2.	a change to the shared state of defined entities, or
> 3.	some combination of (1) and (2).
>
> and then lines 477-480
>
> Instead we focus on the set of facts shared by the parties – the  
> shared state. Actions by service providers and consumers lead to  
> modifications of this shared state; and the real world effect of a  
> service interaction is the accumulation of the changes in the  
> shared state.

This is not actually a contradiction. But I have no problem in  
including responses as part of the RWE. There is a minor Byzantine  
Generals problem with responses but we can fire the generals:-)

>
> I would lean toward lines 277-282 where change in shared state is  
> separate from what is equivalent to an HTTP GET.
>
> b) Is "shared state" RWE that are common to consumer and provider?
>
> From lines 141-144
>
> public actions result in changes to the state that is shared at  
> least between those involved in the current execution context and  
> possibly shared by others. Real world effects are, then, couched in  
> terms of changes to this shared state.
>
> So the answer is yes for consumer and provider and possibly others  
> who may have reason to view the shared state, such as the example  
> in lines 489-491
>
> Flowing from the shared facts, the passenger, the airline, and  
> interested third parties may make inferences – for example, when  
> the passenger arrives at the airport the airline confirms the  
> booking and permits the passenger onto the airplane
>
> c) Can there be NO "shared state"?
>
> In responding to question 2a, I would say yes because I could just  
> be returning information.  I need to run this past the other  
> editors to see how we resolve the inconsistency in the text.

No, I would say that there must be shared views on the world.  
Otherwise there would be no effective communication.

>
> d) I would like to add that when reading the example, I thought  
> maybe that the intent was to actually imply "state".  E.g., using  
> the airline booking example, the effect is a booking but it goes  
> through several states (request, confirm, deny, cancel).  Could  
> that be what is implied here?  Maybe I'm reading too much into this???

No, we were not trying to capture the life-cycle of a seat reservation.

>
> I don't think that interpretation would be inconsistent but it  
> wouldn't be limited to that.  For example, I could respond with a  
> message that Seat 6A is reserved for you but that does not require  
> a state variable be maintained for Seat 6A and that the reservation  
> changes that state.
>
>
> Maybe the answer to above is simple, but did not come across that  
> way in reading the SOA RM.
>
> Part of the rationale for my presentation was to uncover areas  
> where the wording might be improved.  I'm sure in some cases we  
> will leave the wording as is and rely on maybe an FAQ page.  In  
> others, we'll attempt to refine.
>
>
> 3 - My view of the "Execution Context" is that it delves into the  
> business process modeling domain.  Was that the intent?

I don't think that this was our intention. But, in so far as the  
process that the various parties are executing is necessary for  
understanding the semantics of what is going on, then that process is  
part of the EC. (Akin to choreography being part of the EC)

>
> I believe business process is part of execution context;  the  
> connection is being explored more as part of the reference  
> architecture.  My latest thought is that in the same way as I would  
> characterize WSDL as being the implementation of a necessary but  
> small part of the description, I would consider BPEL as the  
> implementation of a necessary but small part of the execution  
> context.  Note, "small" is relative depending on what else is  
> needed for a given context.
>
>
>
> BTW, I think the SOA RM is a great start.
>
>
> Glad to provide community service :-)
>
> </emailDialog>
>
>
> Ken
> ---------------------------------------------------------------------- 
> --------------------
> Ken Laskey
> MITRE Corporation, M/S H305     phone:  703-983-7934
> 7515 Colshire Drive                        fax:        703-983-1379
> McLean VA 22102-7508



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