RE: Dubray paper comments + questions

A better analogy would be to talk about a service oriented architecture
(SOA) as being something like the notion of an Object/Class in Java, and
interfaces (aka service type) are defined and services are objects
implementing these interfaces.

Choreography then becomes a language to express the relation, so the
language like Java is very simple and has a small set of keywords, and it
can use any number of service types (interfaces/classes) and any number of
services (objects).

arkin

> -----Original Message-----
> From: Xper|EnCe Campbell [mailto:fishy3@singnet.com.sg]
> Sent: Thursday, February 27, 2003 4:42 PM
> To: Assaf Arkin
> Cc: jdart@tibco.com; bhaugen; public-ws-chor@w3.org
> Subject: RE: Dubray paper comments + questions
>
>
> Hi all,
>
> I am an attachment student from Singapore SIMTech, and would
> appreciate that if I raise some doubts here.
>
> Is the plan for now to build a generic model for all kinds of
> services (just like a superclass for Java), and when it had been
> greatly adopted, perhaps would venture more into scoping for
> various specific services (where Java comes with the sub classes) ??
> Or should I say the plan is to work on something that almost the
> massive public would adopt, than "upgrade" it further; rather
> than to waste resources on something so detailed and end up to be
> put in one corner??
>
> Regards
> Bernard
>
> --- Assaf Arkin <arkin@intalio.com> wrote:
>
> >
> >
> > > Assaf Arkin wrote:
> > > > For me it's appealing to have a language that can describe the
> > > choreography
> > > > of services and be part of the WS SOA. It's also appealing to
> > have a
> > > > language that described pre-negotiated business collaborations.
> > And it's
> > > > even more appealing if the service interaction resulting from a
> > > combination
> > > > of BPSS, RSS, CPA negotiation, etc could be described in terms
> > > of a service
> > > > choreography.
> > >
> > > I'm all for generality if it doesn't have an unacceptably high
> > cost in
> > > terms of complexity. But I'm afraid it will have a high cost, if
> > we set
> > > out to build a framework in which to model every possible form of
> > > interaction. So I am concerned about scope creep. I also don't
> > want to
> > > duplicate what ws-arch is doing, namely, defining what constitutes
> > a SOA
> > > at a very high level of abstraction.
> >
> > On the contrary, we should conform to the WSA's definition of WS SOA
> > at the
> > proper level of abstraction, and to the WSD's definition of a
> > service
> > interface with WSDL being one possible syntax and a normative
> > reference. So
> > no doubt their work will influence ours.
> >
> > The question really boils down to simplicity. So at least three
> > questions on
> > my side:
> >
> > 1. Is simplicity better achieved by basing the choreography language
> > on the
> > same abstract model as proposed by the WSA, namely services and
> > operations,
> > or is simplcity better achieved by defining another construct,
> > defining the
> > choreography in terms of that construct, and defining mappings from
> > that
> > construct to the WSA abstract model?
> >
> > 2. In electing a very simple and generic model based on already
> > defined
> > communication idioms (Amy's term for what WSDL is working to define)
> > helpful
> > in achieving simplicity of the choreography language?
> >
> > 3. Assuming we take these communication idioms for granted and try
> > to
> > compose them into more complex long-running interactions, can we
> > concieve a
> > fairly simple language for doing that?
> >
> > arkin
> >
> > >
> > >
> >
> >
>
>
>
> Best wishes and Regards
> Bernard
>
> owner of http://hamster.islovely.com
> LiVe FrEe ~~~ Quoted from "The Scorpion King"

Received on Thursday, 27 February 2003 21:19:59 UTC