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: comments collected from SOA-RM presentation


Warning: VERY long email to follow

As noted in earlier emails, I gave a detailed presentation of the RM and encouraged people to submit formal comments on things they felt warranted it. This email summarizes questions I generated while preparing the talk and points raised as part of the discussion during the presentation. I do not know how many, if any, will actually be submitted as comments during the review but the following provides a capture for consideration by the TC. Whether this merits additions or rewording of PR1, material for an accompanying FAQ, or just fodder for Powerpoint is left to further discussion.

Note, the vast majority of the RM was very well received and I’ve gotten numerous positive comments. Most of those who were troubled are actually more interested in seeing the RA. Thus, most of what follows is clarification with only a few inconsistencies that need to be addressed.

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.

- OO has intentional melding of methods to a given data object. The methods can be thought of as a property of the object. For SOA, one can think of the services as being the access to methods but the actual existence of methods and any connection to objects is incidental. The service accesses a capability and the invocation of the service generates the real world effect from the capability. The capability can be implemented using OO techniques but this is not required. A data model for a service is exposed through its service description, but the implementation of the data model, the service, or the underlying capability are opaque to the service consumer. Thus while an OO implementation is possible for the service or the capability, it is not required nor does it play an essential role in the use of the service itself.

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

- 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.

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).

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.

5. In an attempt to be prepared for what were likely to be questions about how the concept of SOA service aligned with the idea of business services, I took material from some email exchanges I’d been in and created the following text for two slides.

Side Discussion (not in SOA-RM) - Business Service vs. SOA Service (1)
Caveats:
For reference model, we describe abstract concepts and not concrete instantiations of the concepts
Recall SOA reference model focus[es] on the field of software architecture and make[s] no attempt to completely account for use outside of the software domain
Nevertheless, question often arises, “but how about my business service?”
Thus, the side discussion

Side Discussion (not in SOA-RM)
- Business Service vs. SOA Service (2)
Business service represented by one or more capabilities and delivered in some way
What you need defines your business service of interest
Remodeling house example: may need plumbing service or may have general contractor so plumbing gets done but never interact with a plumbing service
SOA service (both the thing and the dynamic use of the thing)
the means of connecting a network-accessible capability to some need (but need may not be the need service provider had in mind)
the access is over a network but this says nothing about the underlying capability or how the real world effects are realized
The SOA service = “connectiveness” provided by SOA paradigm
a business service that provides the connectivity (per the execution context) to the capability
other business services could provide that connectivity under different paradigms

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.

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?

- 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?

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?

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?

<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.
 
2 - Several problems with the term "shared state":
a) Is the "shared state" the same as RWE?

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.

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.

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???

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 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]