RE: Choreography-related definitions in the Web Services Glossary

What is "crossing the boundary of domain of control"?

If I have an ERP system deployed from some vendor and I use a hosted sales
force management tool from some service provider am I crossing domain of
control? I can't think of the hosting service provider as a different
business entity because I manage my data as one business entity in both. But
I do need these two separate services to interoperate. And I can be a
complex scenario since the hosting service provider is more keep on giving
me all the capabilities/features I want. I think that's a valid application
for WS Choreography.

If I have an ERP system deployed from some vendor and a CRM from another
vendor, can I just ask them to update the same data in the same set of
database tables? Or do I have to look at them as two domains of control,
each controlling what it does on the inside and exposing some behavior to
the outside. Are these two business entities when they are owned by the same
business entity (per the legal definition)? Do I need a business agreement
to tie my ERP to my CRM? Is that not an intersting problem that WS are asked
to solve on a daily basis in Fortune 500 companies around the world?

There's a reason why domain of control is more interesting then trading
partners: it applies to a larger set of problems. And what we see out there
is that a majority of the use of WS is within a single trading partner but
as David put it: crossing the boundaries of domain of control.

arkin



> Agree !  But I think we care more about those Web Service
> interaction that
> are crossing the boundary of "domain of control" rather than within it.
>
> Best regards,
> Ricky
>
> At 05:53 PM 3/15/2003 -0800, Assaf Arkin wrote:
>
> > >    Turing complete
> > >           @@@
> >
> >Can simulate a Universal Turing Machine. The definition of a Universal
> >Turing Machine is uniform and about one page long, I doubt if we want to
> >repeat it but can definitely reference it from a non-normative reference.
> >
> >As for everything below, I have one question. We live in the WS
> world, so in
> >my opinion we should define activities that a WS performs and proceses in
> >which the WS is involved. If the WSA decides that WS only
> perform 'business
> >activities' that this term would be adequate. Similarly if the
> WSA decides
> >that WS are business entities, the a choreography of Web
> services is in fact
> >a choreography of business entities. But unless such a definition is
> >proposed by the WSA, should we make this restriction in our glossary?
> >
> >arkin
> >
> > >    abstract (choreography) business processes
> > >           These are definitions that are designed to describe the
> > >           ordering of business activities that send and/or receive
> > >           messages. The definition of the flow between
> activities is not
> > >           computationally complete (i.e., it cannot be
> executed). All of
> > >           the messages are between independent business entities
> > >           (participants). The participants may be across companies or
> > >           within a company. There are two types of these processes:
> > >           interface business processes and collaboration business
> > >           processes.
> > >
> > >    interface business processes
> > >           This is an abstract business process that defines
> how outside
> > >           participants can expect to interact with a service of a
> > >           business entity. This service can be implemented as
> any type of
> > >           application, including an executable business
> process. If the
> > >           interface is for an executable business process, then all
> > >           activities within the interface business process will also
> > >           exist within the executable business process-that is, the
> > >           interface business process will be a sub-set of the
> executable
> > >           business process. Example of specifications to define these
> > >           types of processes: WSCI and the abstract part of BPEL4WS.
> > >
> > >    collaboration business processes
> > >           This is an abstract business process that defines how two or
> > >           more interface business processes interact with each other.
> > >           Even if these business processes were executable,
> there could
> > >           be no central control mechanism that could run one of these
> > >           processes. These processes are dependent on the
> implementations
> > >           of the interface business processes to act in coordination.
> > >           Example of specifications to define these types of
> processes:
> > >           WSCI global model and BPSS.
> > >
> > >    executable (orchestration) business processes
> > >           These are definitions that are designed to describe the
> > >           ordering of business activities that send and/or receive
> > >           messages. The definition of the flow between activities is
> > >           computationally complete (i.e., it can be executed). The
> > >           messages may be sent to/from: a) an independent
> business entity
> > >           to itself and b) an independent business entity to another
> > >           (participant). These could be called internal or workflow
> > >           business processes. The business activities that
> interact with
> > >           another participant will also appear in a derived abstract
> > >           business process. In fact, the definition of an executable
> > >           business process is a superset of the definition of
> an abstract
> > >           business process. Example of specifications to define these
> > >           types of processes: executable part of BPEL4WS and BPML.
> > >
> > > Note that there wasn't consensus on these definitions.
> > >
> > > Regards,
> > >
> > > Hugo
> > >
> > > --
> > > Hugo Haas - W3C
> > > mailto:hugo@w3.org - http://www.w3.org/People/Hugo/

Received on Sunday, 16 March 2003 16:31:47 UTC