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


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm-ra message

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

Subject: M reads: rm-ra] Re: service interaction [was: [soa-rm-ra] Follow-up to 7-5-08 Telecom]

I am glad we have started talking about services Actions. 

First, I totally agree with Ken in Action against the service makes no sense if the service doesn't follow with an action.  I think the only right thing to say is the message sender invokes the service's action. This, finally, recognizes that service is not an interface (like WSDL), it Has a body, which performs Actions. Moreover, the Actions may be different depending on the EC (i.e. EC also applicable not only to the communication or Actions against the service, but to the service execution/Actions as well)

Second, getting back to Kens concern: can have its separate policies.  From the perspective of service description and discovery, this is a disaster. There are several lines of considerations:

1)  for WSDL-based interface or not, a service cannot have different end-point and may not have different communication protocol based on interface operations. Otherwise, such interface is simply inconsistent. I am saying that it may be no need to have another service if some operations require different communication characteristics but certainly  another interface. This goes AGAINST notion of service defined for Web Services ( where WSDL=interface=service) but can perfectly be consistent in SOA: one service - multiple interfaces  multiple policies per interface

2) So, it is difficult to me to imagine different policies applied to communication (or Actions against service) for different service Operations. Kens example of Ken Laskey Web Service is the bad practice because the service should keep together only cohesive functionality, which is impossible to have with Ken Laskey Web Service as described. Thus, if the service and its interface are designed poorly, it is THE disaster for both service provider and consumer and RA cannot help in it. [Nobody have said that WS-Policy is the final truth and in all situations we must follow it]

3)  another point ( which I think is mostly my personal point ) is that I believe that taking a class ( in Java or C# or in whatever) and exposing it via WSDL is the biggest SOA mistake and it does not matter how many people do it. It is the same thing as using database primary keys to write database queries in the Web pages (or in JSP Tag Libraries) which was very popular until people started to pay real money for such convenience. This class or even legacy app was never designed to behave as a service. As a result, we getting into Web Service integration instead of service orientation. Thus, it is the same bad practice as in the point 2)

4) where different policies can really appear on per service interface operation basis is the area which lists the policies affecting RWE, i.e. service level Actions. In this case, it is the design tradeoff whether to use different interfaces grouping operations appropriately or creating new service all together.

5) what I would avoid is stretching service to the service of single operation. First, it would be an API (well, remote API) , and, second, it would not help. That is, I may have a document/literal style of Web Service with only one operation but with a million of message namespaces (message schemas) and demand one policy per namespace (why not?). Sorry for such low technical level but I try to point that a single operation per service DOES NOT simplify situation and resolve Kens concerns.
- Michael

Subject: M reads: rm-ra] Re: service interaction [was: [soa-rm-ra] Follow-up to 7-5-08 Telecom]
	From: Ken Laskey <klaskey@mitre.org>
	To: "Jeffrey A. Estefan" <jeffrey.a.estefan@jpl.nasa.gov>
	Date: Tue, 20 May 2008 23:49:49 -0400
Sorry I let this drop but couldn't push it while on travel.  I've reread the RM and sections 3.5 and 4.3 of the RA, and I'm still not satisfied we are clear on what needs to be said about Action.

Section 4.3 reads: An interaction can be characterized by a sequence of actions.

The RM reads:  interaction proceeds through a series of information exchanges and involved actions.

First, would it be appropriate to harmonize the two by having section 4.3 read: An interaction proceeds through a sequence of actions?

Next, I have been picking at our definition of Action as the application of intent.  (Note, Intent is defined differently on line 784 and line 844.)

If sending the message is the Action, then the action model of a service consists of the messages that can be received.

Line 759 states: An action may have preconditions.  If the action is the sending of the message, then the preconditions are those of the sender and not the receiver (likely the service).  I don't send messages before breakfast can be my precondition.  The receiver may not know or care about my preconditions.

Now, it is reasonable that the message sender's preconditions should include:
- knowing the message being sent to a given endpoint is part of the receiver's action model related to that endpoint
- knowing preconditions of the message endpoint, especially the related process model.

Before I go on, let me respond to Rex's comment.  My distinction between action level and service level is meant to be real and not just for that discussion.  In theory, there can be one Ken Laskey Web Service (I'm being specific here on purpose) that does everything Ken Laskey needs through dozens of WSDL operations: one operation for sports scores, another for stock quotes, another to tell my wife when I've left work.  Each operation can have its peculiar RWE and, per WS-Policy, can have its separate policies.  From the perspective of service description and discovery, this is a disaster.  How can I describe a service if I have to describe each operation in separate detail?  Why aren't these just separate services?

The examples we give in the RM talk to multiple process steps -- described in the process model -- that must be followed in sequence to realize a RWE.  There is then some describable connection that can be captured at the service level.

Back to Frank's context for action, an agent sends a message because it knows the RWE will be the message recipient, e.g. a service, taking certain "action".  Let's assume the action is the application of intent by the service.  Is making this indirection explicit really necessary?  Action against the service makes no sense if the service doesn't follow with an action.  Do we lose anything by saying the message sender invokes the service's action.  Interaction will still be the sequence of actions -- each a joint action between sender and receiver -- leading to the RWE.

One final thing: there appears there should be a strong, explicit connection between Operation defined in section 4.3.2 and the Process Model.  Note that Operation is only used in two places: the paragraph beginning on line 1955 and on line 2007.  So I ask whether defining Operation is necessary, especially because it is likely to cause confusion with the WSDL operation.  Can we not talk about this in terms of private actions or steps in the process model?

And one more thing: line 1965 states: the request/response MEP represents action.  What does this mean if both the request and the response is a joint action?

Enough for now.

KenOn May 13, 2008, at 12:15 PM, Jeffrey A. Estefan wrote:

Remember, there are only two types of action:
1. [Separate] "Action," which is the application of intent by [A] participant (or agent) in order to achieve a RWE.
2. "Joint Action," which is an action involving the efforts of [TWO OR MORE] participants to achieve a RWE.
Note:  The emphasis in brackets is mine.
In the context of interaction, we emphasize "joint action" because you have to have a speaker AND a listener in order to interact.  Further, recall that we define the means by which joint actions [and event notifications] are coordinated by service participants (or agents) to be "message exchange," and we define "operations" as the sequence of actions a service must perform in order to validly participate in a joint action.  Consequently, there are indeed separate actions that service performs (i.e., perform operations) and there are joint actions [and event notifications] used for message exchange.  This is why we make the point that messages denote either action (more accurately, joint action) that causes a RWE and events that report a RWE.
What we should probably do is make the emphasis on joint action relative to Fig. 40 (based on PRD 1 of the RA) so as to not cause this kind of confusion.  The emphasis on joint action isn't really addressed in until later in Section 4.3.2 when we talk about message exchange.  In addition, it is not just the joint action realized through messages that causes a RWE to occur but also the separate actions (i.e., operations) that the service performs that contribute to the RWE, i.e., it is both types of action performed in concert that leads to a RWE.  This point is not clearly articulated in the RA and needs to be.
If yawl agree, I'll make the necessary minor updates to the Interacting with Services model to help resolve this ambiguity before the next PRD.
 - Jeff

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]