RE: Proposed text on 'SOA' (resend)

Extensibility is an optional constraint that yields the desirable property
of evolvability, imo.  It is not a constraint that is unique to web
services.  So why spend time on it in web services?  The only thing I'd like
to say something like "Web services should use a Must Ignore unknown
elements and their descendents", whereas other apps might only ignore the
unknown element.  Again, what is specific to web services ability
extensibility and evolvability.

I disagree also that SOAP-RPC=!interoperable and !SOAP-RPC=interoperable.
The principle property of SOAP-RPC is a particular schema that constrains
the wire format.  This may or may not help with interoperability because it
is unclear whether mapping arbitrary programming constructs to arbitrary
schema language constructs is easier or harder to create interoperability
than mapping arbitrary programming constructs to constrained schema.  There
are lots of interoperability problems in both soap-rpc constrained and
document formatted.

I still don't understand your first constraint.

Dave

> -----Original Message-----
> From: He, Hao [mailto:Hao.He@thomson.com.au]
> Sent: Monday, September 08, 2003 4:13 PM
> To: 'David Orchard'; www-ws-arch@w3.org
> Subject: RE: Proposed text on 'SOA' (resend)
>
>
> hi, David,
>
> I agree with you that defining SOA using constraints is a
> good idea and the
> approach taken by Roy is a good one.
>
> However, I don't agree with the details you define SOA in
> [1].  My view is
> that SOA is to achieve loose coupling via the two constraints
> I listed.  SOA
> may not be REST but REST is an instance of SOA. Good Web Services are
> instances of SOA as well but not all of them are good.  So if
> you have a
> closed schema, you might still have a Web service but you
> have also defeated
> the purpose of loose coupling.  Again, SOA is not the Web architecture
> although the Web architecture is an instance of SOA.
>
> Using this SOA definition, we can add additional constraints
> to get REST,
> and WSDL/SOAP Web services as you suggested:
>
> SOAP/WSDL Web service
> SOAP/WSDL Web service introduces the following constraints:
> 1. Except for binary data, messages must be in SOAP.
> 2. The description of a service must be in WSDL.
> SOAP Web service is the most common form of "Web service" in
> the industry.
> There are two "favours" of SOAP Web Services: SOAP RPC Web service and
> Document-centric SOAP Web service, depending on how SOAP is used.
> SOAP RPC Web service
> A SOAP RPC Web service intended to be an SOA but breaks the second
> constraint required by an SOA. A SOAP RPC Web service encodes Remote
> Procedure Calls in SOAP messages. Effectively, it prescribes
> both system
> behaviours and application semantics together.  Because
> system behaviours
> are very difficult to prescribe in a distributed environment,
> applications
> created with SOAP-RPC are not interoperable by nature. Many real-life
> implementations have confirmed this statement.
>
> Hao
> -----Original Message-----
> From: David Orchard [mailto:dorchard@bea.com]
> Sent: Saturday, September 06, 2003 9:25 AM
> To: www-ws-arch@w3.org
> Subject: RE: Proposed text on 'SOA' (resend)
>
>
>
> A long time ago, I proposed what I thought were the
> constraints on SOA wrt
> those defined for REST.  I think they are a better formulation of the
> constraints on SOAs.  [1] Some of this made it into the web
> arch document in
> 1.6.3 (yes, somebody actually quoting the doc!) but it got
> totally watered
> down (like dropping the layered client server aspect) and
> then muddled (the
> "also, with emphasis on messages" and remaining paragraph).
> This is quite
> frustrating, having contributions that are solid undergo such
> a morphing.
> FYI, my assertion about representations being transferred in
> the post case
> has been validated by the tag and is being described in the
> latest web arch
> document.
>
> I'll say again.  I think the web service architecture document should
> describe any constraints that it applies to components and
> the relationships
> between componenents.  I took a first pass at that and I
> think it's a good
> start if the group decides to look at component architecture
> descriptions.
> Describing technologies and their relationships is also good, but is
> separate from the components.
> >
> > The main purpose of SOA is to achieve loose coupling among
> > software agents
> > through the following constraints:
> > 1.	Simple and ubiquitous interfaces to all participating software
> > agents. Zero or minimum application semantics is encoded at
> > the interfaces.
> > The interfaces should be universally available for all providers and
> > consumers.
>
> huh?  What is "simple and ubiquitous" and "all participating software
> agents"?  That sounds a like REST.  Either the interfaces are
> constrained,
> or they're not.  I thought that we moving to a model of where
> REST is a more
> constrained SOA.  This seems to say that SOA=REST.  Which is
> rather wrong.
> I'll observe that there is a message oriented model that
> defines agents (so
> why use "software agent") and messages and descriptions (but
> not interface).
>
> > 2.	Descriptive messages constrained by an extensible
> > schema. Zero or
> > minimum system behaviours are prescribed by messages. A
> > schema limits the
> > vocabulary and structure of messages. An extensible schema
> allows new
> > versions of services being introduced without breaking
> > existing services.
> >
>
> I don't get this whatsoever.  A schema may limit portions of
> the vocabulary,
> but not all.  It may or may not allow extensibility.  And having an
> extensible schema by no means is sufficient to allow new versions of
> services to be introduced in a backwards or forwards
> compatible way.  are
> the constraints "1. all messages must be constrained by a
> schema.  2. said
> schemas must be extensible"?  So if I create a closed schema
> it's not a web
> service?  eek.
>
> I completely agree that extensibility and evolvability are
> key properties of
> the web and web services, and that we should look at how
> versioning should
> be done.  Trick question: How does extensibility and
> evolvability for web
> services differ than that of the web?  Answer: WSDL and SOAP
> are constraints
> in web services.  We should describe what is different than
> the rest of the
> web from an extensibility and evolvability perspective.
>
> FYI, the TAG (particularly myself and Norm Walsh) is looking at the
> evolvability and extensibility from a web perspective.  So let's not
> reinvent web architecture (yet again) for web services.
> Let's focus on what
> is different about web services than the web.  And that's
> particularly soap
> and wsdl.
>
> > Explanation:
> >
> > 1. The purpose of constraint 1 is to reduce the artificial
> > dependency at the
> > interface level for all agents and therefore reduce the cost
> > of consuming
> > and providing services. For example, one might create a
> > special service
> > interface but then the interface requires a very specific language,
> > platform, in a very specific manner. In such an example, it
> > is a violation
> > of this constraint.
> >
> > 2. The motivation behind constraint 2 is that It is it is
> > very difficult (if
> > not impossible) to prescribe system/application behaviours in
> > a distributed
> > environment. It is up to the receivers of a message to decide
> > what to do and
> > how to do with it. An extensible schema allows
> > partial-understanding, so a
> > receiver can act on only part of a message. This allows a
> complicated
> > service to be decomposed into smaller services and evolve
> > independently from
> > consumers.
> >
> >
> > An SOA,
> > 1.	MUST provide a mechanism that enables the communication
> > between a
> > provider and a consumer under the context of a service sought by the
> > consumer.
> > 2.	MUST define service contracts between providers and consumers.
> >
> > Optional constraints:
> > 1.	Stateless messaging. Each message that a consumer sends to a
> > provider must contain all information necessary for the
> > provider to process
> > the message.   This constraint makes a service provider
> more scalable
> > because it does not store state information about consumers.
> > 2.	Stateful messaging. Both the consumer and the provider share the
> > same consumer specific context, which is either included or
> > referenced by
> > messages exchanged between the provider and the consumer.
> > This constraint
> > makes the communication between a provider and a consumer
> > more efficient but
> > reduces the overall scalability of the service provider
> > because it must
> > remember the shared context for each consumer.  It increases
> > the coupling
> > between a service provider and a consumer and makes
> switching service
> > providers more difficult.
> > 3.	Idempotent messaging.  Duplicated messages received by
> > a software
> > agent cause exactly the same effects as a single unique
> > message does.  This
> > constraint allows providers and consumers to improve the
> > overall service
> > reliability by simply repeating messaging if faults are encountered.
> >
> >
>
> [1] http://lists.w3.org/Archives/Public/www-ws-arch/2003Feb/0055.html
>

Received on Monday, 8 September 2003 19:39:05 UTC