[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ws-rx] i050 - Delivery assurances and the protocol
|
Marc: I would prefer to have them removed all
together as I previously stated. I chose the first option solely on the fact
that the DA’s violate what I perceive to be the core tenets and values of
SOA. Interface based design and SOA infer that abstracting the underlying implementation
behind the service is a healthy thing. Services should remain as opaque as
possible. The benefits of this have been argued in several forums including
during the development of the W3C WSA, the UN/CEFACT architecture and several
OASIS SOA TC’s. Once you start poking holes to see the underlying
mechanisms behind a service interface, you start on a slippery slope to tight
coupling with intricate dependencies. Keeping services as opaque, clearly
defined action boundaries is logical. I would prefer architecture whereby the
service itself only makes visible whether or not the service invocation request
succeeded or failed and hides the reasons (including DA’s), decisions for
such from those who are using the service. Exposing DA’s to the service
consumer starts to poke holes in the managed transparency of services. Duane From: Marc Goodner
[mailto:mgoodner@microsoft.com] I’ve been considering i050 [1] and would like to hear
what other people in the TC are thinking about this. There were a couple of proposed directions in the issue, one
was to simply remove all references to delivery assurances and the other was to
move all mention of them to the policy spec. I would prefer not pursuing the
third option of a new deliverable. If we did pursue the first option, to remove all references,
that would seem to include removing the new parameter/assertion in the policy
spec as well. From my perspective this seems acceptable. It would not
cause any further complications in the spec to remove mentions of the delivery
assurances. The delivery assurances have never been manifested in the protocol
itself so there would be no impact there. Furthermore we already seem to be
spinning up new issues, like the outstanding AI to close i024 [2], which are
tied to nailing down details of the delivery assurances. I am concerned that
exposing the delivery assurance is going to result in further complication of
the protocol in terms of new features to perform operations around them such as
i006 [3]. As others have noted exposing these does seem to be a violation of
general SOA principles [4] and I suspect is why additional issues and protocol
complications are showing up around them. Finally it is not clear to me what
people are intending to do by exposing the delivery assurances. The only
answers to this question I have ever gotten relate to optimizations that in
terms of the additional complications to the protocol, in terms of use and
implementation, don’t seem worth it. What would we loose by removing the
delivery assurances from the spec? Would it make implementing or using the
protocol more difficult with or without them? If we are going to keep the delivery assurances I think the
second option makes the most sense, the definitions and all mentions of them
should be moved to the policy assertion spec. Regards, Marc g 1 i050 spec talks about delivery assurances but does not
clearly relate them to the protocol 2 i024 WS-RX policies not manifested on the wire 3 i006 Source based delivery QoS policy assertion 4 Discussion point on SOA principles in relation to DA and
i006 [http://lists.oasis-open.org/archives/ws-rx/200510/msg00100.html]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]