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: FW: [soa-rm] changing shared state to shared view


Sorry about being late in responding but had troubles with accessing the
mailing list... Frank, here is what I was talking with you about at
OMG...

-----Original Message-----
From: Dale Moberg 
Sent: Tuesday, April 18, 2006 11:00 AM
To: 'Duane Nickull'; Chiusano Joseph
Subject: RE: [soa-rm] changing shared state to shared view

Some rejoinders (and agreements) noted below. Not sure that this
perfectly conveys the intended point, but let me see if it moves it
anywhere closer to a RM generalized in one tiny way... Btw, I see RM
issues as tied to what is essential to a concept, as opposed to what is
just a frequently found feature of kinds of instances of the concept
(the old Aristotelian accidental properties).

Duane N. says:

In the context of BPSS, perhaps this makes some sense, but in the
abstract
world of SOA RM, it is flawed.  

Dale> I don't think that my concern is a RA detail because a prohibition
on services disclosing state about managed resources would be an
arbitrary restriction to the concept of a service. But maybe so... let
me build my case in favor of RM relevance.

Duane:
Orthogonal to process, managed service transparency conceptually keeps
certain details of state hidden and internal to a specific service and
known only to the environment behind the service.

Dale> I confess to a little uncertainly on how that is to be parsed but
I am mostly in agreement that there are many (most) aspects of a service
that are and should be hidden and internal. But "many/most" does not add
up to "all"; and you must say that all resource details must be hidden
and internal to say that conceptually services do not leak information
about their state via other services. 

I recall your fondness for java metaphors. Certainly though there are no
friends in java (RA1) as in C++ (RA2), there are distinctions falling
between the most restricted and the least restricted-- namely, package
private and protected. The details about restricted visibility are
certainly architectural detail. The idea of levels of access of member
methods or variables is, however, general and found across languages
(RAs) (at least within a certain class of languages). In saying there is
only the information returned in the signature of the service that is
public and the rest is private/hidden/internal, you overlook other
approaches to the layering of accessibility. If this is so, it is a flaw
within the RM context, and not a matter of specialization in RAs. But
perhaps the TC has decided to build all or none accessibility into the
idea of a service. I just think that all-or-none accessibility is just
one specific version of a more general idea of resource/state/capability
accessibility that can have many forms.


Duane:
Even in the BPSS world, you would be forced to admit that you only
should
care about the externally visible state properties, given the hidden
internal ones are irrelevant if you can never see them anyways.

Dale> Partially true, but that means that there are some aspects of
resources that are visible and are made visible by other services.
Internal ones are not necessarily irrelevant even though they are not
displayed in all their specificity. For example, an
acceptanceAcknowledgementException may be based on some disk out of
space condition that is not revealed. Such a detail does show up in an
abstracted away as a technical failure state that is, however, visible
in a management level service.

Duane:
Assuming anything behind a service which has not been exposed is
probably
not a good practice IMO.  You may cite this as flawed but it has also
been
generally accepted as a principle in WS-*.  

WS-Coordination, WS-Transaction, WS-ResourceFramework, the idea of an
EPR in WS-Addressing, a lot of the grid services management work... We
have to disagree here.

Also, good practice is RA level description to me. Not sure why this
kind of consideration should be raised if this is a RM issue.

Duane:
This discussion you point at below was recently discussed in great
detail within the WS-RX group (which surprisingly was almost exactly the
same conversation we had in ebXML messaging about 4 years ago).  The
question was about message ordering where one philosophy was that the
service interface should provide delivery assurances WRT messages being
delivered to the application destination in order.  This presumed a
certain architecture behind a service which is not optimal and actually
flies against the general philosophy of SOA/OO et al whereby one should
write the interface and not care how the interface is functionally
enabled.  Yes - as you point out - in certain cases, the service
provider might opt to make these things visible, but this is at the
discretion of the service provider.  When made visible, they are
externally visible properties.  The internal state may still be
different and no one on the outside should ever be the wiser.

Dale:
Discuss another day.

Duane:
 For lack of a better word, the concept we are trying to capture is the
"externally visible properties" of state alignment between consumer and
providers.  Given this is concrete, it probably will not be resolved in
the RM, but probably more relevant to an RA. 

Dale:
I think the concept is a specialization of accessibility to a resource
especially when exposed over multiple services. The externally visible
realm can, at one extreme, be highly restricted (your buttoned down
atomic service interface is one of those extremes). Or the resource can
possibly have a debugger service method exposed in which case all the
innards are readable and writable (presumably this is a method that is
way at the other extreme of accessibility!) In between, there are the
multiple-method variously accessible resources in which abstracted
aspects of resource state are externally visible).

 





I am not sure that "view" is the correct word.  I am sure we will get it
sorted.

I hope you will consider providing active input on the RA - we could use
more people with the depth of experience you possess.

Cheers

Duane



*******************************
Adobe Systems, Inc. - http://www.adobe.com
Vice Chair - UN/CEFACT  http://www.uncefact.org/
Chair - OASIS SOA Reference Model Technical Committee
Personal Blog - http://technoracle.blogspot.com/
******************************* 


-----Original Message-----
From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] 
Sent: Wednesday, April 12, 2006 10:45 AM
To: Duane Nickull; Chiusano Joseph; soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] changing shared state to shared view

Duane writes:

"State alignment is flawed IMO.  You cannot see past the interface
therefore
how do you know (or why care) that someone's state is aligned with
yours.
As long as the externally visible properties are synced with your
requirements, you should not care what their actual state is."

BPSS modeled some open-edi and RNIF ideas that assume layering of
message processing. There are several layers of interfacing defined, and
not one monolithic layer called overall "service" So your reasoning
starts out from a false premise: you can see behind "the interface" to
higher layers. For example, if signals for AcceptanceAck and
AcceptanceAckException are used, then there is a layer at which the
validity of the request is acknowledged (from the standpoint of it being
one for which some response is to be performed).  Because the backends
for the responding long-running processes often optimize after all
orders are in (and do not merely use greedy algorithms) for resource
utilization decisions, there is a separation of process into
stages/layers each of which can be conducted somewhat independently. 

You may insist that architectures "should not care about intermediate
processing stage decisions," but that will fit only a certain class of
processing architectures. 

I personally think SOA-RM should describe situations where intermediate
states can be accessed (status services, forward progress services, etc)
that are possibly of interest to the requesting process making use of
the entry point service. What prevents those intermediate services from
disclosing information about other services, in particular the entry
point service? While nothing more is learned about each service on its
own than through its inferface, a sufficiently general SOA should allow
for services that supply info on other services.






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