I came a little late to this group, so haven't fully caught up yet, so
apologies if what I'm about to describe is out of place. Firstly I think
context and it's use (which is wider than one-way message correlation)
is a requirement throughout the architecture: transactions, security,
correlation, workflow, reliable messaging etc. all have a notion of
context. I'm always in favour of referencing standards/specifications
that are available elsewhere, rather than reinventing the wheel. In that
case, I'd define the requirement in the model ("we need context; this is
what context is, ..." and then say it comes from WS-Context). I would
assume that we would do the same with other things, e.g., WS-Security?
Mark.
McGregor.Wesley@tbs-sct.gc.ca wrote:
>Hi again Mark,
>
>Your comments about context are right on target.
>
>Question still remains though:
>
>1) Is it only a requirement for the RM?
>2) Do we need to propose a mechanism to support it?
>3) Do we just reference WS-Context and be done with it?
>
>Wes
>
>
> -----Original Message-----
>From: Mark Little [mailto:mark.little@arjuna.com]
>Sent: April 25, 2005 9:23 AM
>To: McGregor, Wesley
>Cc: soa-rm@lists.oasis-open.org
>Subject: Re: [soa-rm] Opaqueness and Transactions
>
>Hi Wes. Comments inline.
>
>McGregor.Wesley@tbs-sct.gc.ca wrote:
>
>
>
>>Hi Mark,
>>
>>You are absolutely correct with respect to the overloading of the term, hence the reason I used it, ambiguity.
>>
>>
>>
>>
>I like ambiguity in some cases, but in this case I think it could lead
>to confusion and wrong interpretations of what is meant.
>
>
>
>>What I am trying to get say is that if we discuss the notion of service combining, then we must have a model that supports the results of a "call" getting back to the initiator in the expected order. Typically, no matter what the spec or technology is, a "transaction ID" or context specific data of some type is embedded somewhere within the response for correlation.
>>
>>
>>
>I agree, but would suggest concentrating on the context specific
>information: check out OASIS WS-Context (part of the WS-CAF work); this
>sounds exactly what WS-Context was set up for - composition of services.
>If you use the term "transaction" and, specifically, "transaction
>context" or "transaction ID" then there's an implication on the
>reliability and fault-tolerance characteristics of any interaction. I'm
>assuming that that isn't a core requirement here, so keeping clear of
>that to start with would be a good idea.
>
>
>
>>Without a mechanism as such, for asynchronous messaging, a mapping from response to caller cannot take place
>>
>>
>>
>>
>I'd definitely recommend WS-Context. Other groups within OASIS (e.g.,
>ebXML) have been looking at how to leverage it.
>
>
>
>>My question, to rephrase, is do we need to provide such a mechanism in the RM or rely on the derived reference architectures to describe it?
>>
>>
>>
>>
>I think referencing a requirement for context is useful. It's a fairly
>fundamental thing in any distributed environment.
>
>
>
>>Feel free to pose some arguments here pro or con.
>>
>>Wes
>>
>>
>>
>>
>
>Mark.
>
>
>
>>-----Original Message-----
>>From: Mark Little [mailto:mark.little@arjuna.com]
>>Sent: April 22, 2005 5:35 PM
>>To: McGregor, Wesley
>>Cc: soa-rm@lists.oasis-open.org
>>Subject: Re: [soa-rm] Opaqueness and Transactions
>>
>>Hi Wesley. Just a quick question: why the term "transaction" to describe
>>what you have? I'm just a little worried that that term is severely
>>overloaded in general, and definitely in the context of SOA and Web
>>Services.
>>
>>Mark.
>>
>>
>>McGregor.Wesley@tbs-sct.gc.ca wrote:
>>
>>
>>
>>
>>
>>>Hi All,
>>>
>>>I would like clarification on the following items if possible:
>>>
>>>Opaqueness
>>>
>>>I believe there are degrees of opaqueness. If a service interface allows JAVA classes as a parameter to the actual call, one definitely knows that the service supports JAVA at some level, implying the consumer has some knowledge about the internals of the service (not much but some). The service is not completely opaque.
>>>
>>>If the service only allowed XML as incoming data and object constructs, then the parser of choice could be in any language or any other combination of service calls. I would then say the service is more opaque.
>>>
>>>Proposal: There are degrees of opaqueness within the SOA RM and we need to define them.
>>>
>>>Transactions
>>>
>>>If a service is a combination service, example, service A is composed of service B and C, are we going to describe the method by which B and C asynchronous responses are delivered to the appropriate reception point within service A?
>>>
>>>Proposal: We need to describe by what method or model we support service composition at run-time.
>>>
>>>
>>>All comments welcome especially by those who have not said much so far!
>>>
>>>Enjoy your face to face,
>>>
>>>Wes
>>>
>>>-----Original Message-----
>>>From: Ken Laskey [mailto:klaskey@mitre.org]
>>>Sent: April 20, 2005 4:16 PM
>>>To: Duane Nickull; SOA-RM
>>>Subject: Re: [soa-rm] service composition scenarios
>>>
>>>Duane,
>>>
>>>I agree with your analysis. If there is a reason to know details of what
>>>the service is doing, e.g. a language translation is needed as part of what
>>>the composite service will do and the user wants to make sure a certain
>>>class of translation engines is used, then this information should be part
>>>of the service description/metadata and there may be rules/policy to
>>>evaluate for the user to make sure the composite server is
>>>appropriate. Constructing an orchestrated composite service may be done
>>>through another service, but such a service will be like any other to the
>>>RM. However, the example does indicate there may be a need for specific
>>>metadata and rules/policy capability and this may or may not go beyond the
>>>idea of a generic service. (Or, we may say that an SOA requires certain
>>>instances of a generic service be present.)
>>>
>>>Ken
>>>
>>>At 03:54 PM 4/20/2005, Duane Nickull wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>>TC:
>>>>
>>>>Although this may not be part of the core RM, this is probably an
>>>>interesting discussion to have. The concept of service composition has
>>>>been raised a few times on the list. I wanted to state a few observations
>>>>about this concept. Please see attached diagram for details.
>>>>
>>>>1. Services are opaque by nature. That means that the service consumer
>>>>cannot see anything beyond the interface (service interface) it uses.
>>>>If one service is actually aggregating two other services, the service
>>>>consumer cannot and should not know this. From a service consumers
>>>>viewpoint, a service is merely an agent or interface that offer some
>>>>function(s). Whether those functions are mapped to a set of classes in
>>>>some native language or another service is not important or relevant
>>>>(other than the service metadata stating what invoking the service means
>>>>or does)
>>>>
>>>>2. The service function (for service A) is described in the service
>>>>description specific to that service. If completing the function depends
>>>>on two or more serial or parallel paths of execution successfully
>>>>completing behind the service interface (like calling services B and C)
>>>>within a certain time frame, that is not relevant to state in the service
>>>>description for service A. The service consumer is only concerned with
>>>>the service's ultimate success or failure. Mapping the functionality to
>>>>success and failure is the responsibility of the service provider.
>>>>
>>>>Do you agree with this? This supports the notion of opaqueness.
>>>>
>>>>3. # 1 and # 2 above are mandatory to comply with a services autonomous
>>>>nature as described in the W3C WSA and subsequent services
>>>>architectures. A service alone must determine whether the service
>>>>succeeds or fails. If a service consumer can see any specifics behind the
>>>>service, this violates several of the core principles of SOA. If
>>>>visibility beyond the offered service is required, then the service does
>>>>nor meet the demand of the service consumer. Accordingly, the service
>>>>provider and consumer should discuss and re engineer.
>>>>
>>>>When implementing, more complex patterns of service invocation can be
>>>>facilitated while keeping these three axioms. If a transaction sequence
>>>>is needed, a service interface can offer two services - a put() and a commit().
>>>>
>>>>Duane
>>>>
>>>>--
>>>>***********
>>>>Senior Standards Strategist - Adobe Systems, Inc. - http://www.adobe.com
>>>>Vice Chair - UN/CEFACT Bureau Plenary - http://www.unece.org/cefact/
>>>>Adobe Enterprise Developer Resources -
>>>>http://www.adobe.com/enterprise/developer/main.html
>>>>***********
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>--
>>> ---------------------------------------------------------------------------------
>>> / Ken
>>>Laskey \
>>>| MITRE Corporation, M/S H305 phone: 703-983-7934 |
>>>| 7515 Colshire Drive fax: 703-983-1379 |
>>> \ McLean VA 22102-7508 /
>>> ----------------------------------------------------------------------------------
>>>
>>>*** note: phone number changed 4/15/2005 to 703-983-7934 ***
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
--
Mark Little
Chief Architect
Arjuna Technologies Ltd
(www.arjuna.com)