RE: Internal/External questions - scribed from f2f 1

> -----Original Message-----
> From: public-ws-chor-request@w3.org
> [mailto:public-ws-chor-request@w3.org]On Behalf Of Jim Hendler
> Sent: Friday, March 14, 2003 12:11 PM
> To: public-ws-chor@w3.org
> Subject: Internal/External questions - scribed from f2f 1
>
>
>
> The following is a list of questions relating to external v. internal
> design decisions, developed by abreakout group at the first face to
> face:
>
> ------------

The comments below reflect my opinion:

> What are the business problems we're trying to solve?
> 	- what is the distinction between internal and external
> 		* internal = building implementation?  Awareness of details?
> 		* external = interface/contract
> 		[explain w/use cases]

Depends on your point of view. If you are a stock holder in my company that
I would like you to only have information that is available to the public at
large. If you are a potential customer I would give you more detailed
information, I would trade you even more information if you are a business
partner. But I still won't tell you how much I make on each sale. Unless you
are my accountant, that is. In all four roles you are a different business
entity, yet the barrier is not cast in stone but rather fluid and depends on
what we want to achieve. In other words, one man's external is another man's
internal and vice versa.

The interface of the service define it's external behavior. That's what
someone can tell about its behavior by exchanging messages with it. It may
do a lot of other things that are not observable in that way, let's call
that internal. Now, there are three tricky points here:

1. Conceptually the internal may be no different from the external. It's
very easy to come up with a test case in which the interface describes all
that the implementation does. It's impossible to force the internal to be
different from the external, but in most cases this difference does exist.

2. There are valid reasons for exposing some of that internal information as
part of the interface even though it's not observable. The use cases I've
been given for doing that all deal with privacy, to protect their privacy
people want more visibility. It's akin to asking the CheapDeals.com what
they do with your e-mail address so it doesn't end up at the hands of
Spam.com.

3. What is externally observable may be the result of internal activities,
so even the narrow definition of interface that describes only externally
observable behavior would allow for definitions that some internal-only
advocates don't like. But if won't force them to use it - only allow if they
choose to.

It's important to state that the language does not say what you should
expose, it only gives you a tool and you can use that tool any way you see
fit. I may decide to expose more details, so I will write them down as part
of the choreography. Someone else may decide to expose less details, so they
would write a more constrained choreography. But the language will never
force you to expose more than you want to. The discretion is always at your
hands.


> 	- as a consumer/developer, what do I need to know to use ws-chor?
> 	- are we trying to develop a lang to tie together WS?
> 		If not, what are we developing?

Yes we are.

> 	- what definitions/terms must we have consensus on, how do these
> 		effect our ability to make the int/ext decision?

My list so far: choreography, orchestration and implementation. And I think
these are the interesting terms because have to expose implementation
details is both an issue and breaks the abstraction that is important for
choreography. But being able to do so selectively brings more value to
choreography. And the thin line is orchestration which is sometimes as
abstract as defined by the choreography and sometimes as concrete as being
an implementation.

> 	- does external exposition require communication of internal details
> 		* how does the description of the service related to int/ext
> 		* separating the description from impl langs (GPL,
> WSDl, etc.)

The description of the service says everything about its behavior. You may
say as little as possible, or you may include more information. You can
expose different information to different people. For example, you can
always say "this service is implemented according to spec X", but never give
anyone access to spec X. Or you can give access to spec X, or spec X may be
well known. For example, HIPPA says a lot about security and privacy of
data, so you can say that a service is implemented according to that spec
and you do expose some information, but information that you are mandated to
expose by law.


> 	- how do we ensure we have a set of abstraction at various levels,
> 		such that the relations among levels are complete and
> 		well-formed (relate to int/ext)

This is one of the thing that composition needs to address. If I compose
services X and Y to form service Z then this composition is a definition of
service Z. The composition is interesting to me: it describes the
choreography between X and Y. The composition may not be interesting to
someone using service Z.

We can enable composition in the language in such a way that I can compose X
and Y to form Z but I can let others use Z without having access to that
composition. We can also allow someone to expose these details at their
discretion. The language should not force one use by employing a recursive
model of composition.


> 	- does the distinction stay consistent for both inter- and
> 		intra- company choreographies?

Yes. Definitions are like information: if you own them you can decide what
information to give to whom. You can share it with the world, with your
business partner, with one business partner, or just hide it in your drawer.


> 	- what is choreography w respect to:
> 		* a lang to tie together WS
> 		* separate desc language

WS Choreography should be a language to tie together Web services. However,
it should be seen as a separate description language from WSDL, XSDL,
WS-Policy, etc, but one that can used in combination with these languages
(e.g. to extend WSDL, or to be references in a policy).


> 	- if choreography must be internally consistent, how can we
> 		view it externally

This is not an issue if we elect a recursive model for composition.

> 	- what is the theoretical "definition" of choreography, and
> 		does this imply external v. internal?

The theoretical definition of choreography does not imply external v.
internal. However, it does make a distinction between implementation and
interface. The interface describes the externally observed behavior, which
is to say, everything that is not externally observered is internal. Usually
the internal will have much more details than the external, but nothing
prevents the external from being equivalent to the internal, especially for
the simple cases. An implementation may itself be achieved by another
choreography, and recursively, so the ability to do recursive composition
gives you a nice clean model and also lets you control what information is
exposed at what level.

> 		* e.g. does pi-calculus constrain us to a particular view

pi-calculus fits well with recursive composition, it allows you to view
things at different levels and also to compose processes from smaller
processes recursively.


> 	- does compositionality require internal view/details?
> 		* composition @ runtime
> 	- is the thing that gets composed itself a service?
> 		* does this imply int or ext

Yes.

> 	- how can we understand what we're trying to do relative to
> 		existing specs (BPEL, BPSS, WSCI, WSFL, etc.)
> 		* do other specs have internal/ext distinction

BPEL, BPML, WSCI and WSFL take a similar approach to recursive composition,
so in fact we're not reinventing, we have a basis with which to work, and we
have experience with using that stuff. BPSS takes a different approach.

> What are the technical problems we're trying to solve and how do
> these relate to the business problems?  Are these different problems
> for internal vs. external?

There is a big overlap between choreography and orchestration, and both are
interesting problems that are solved by a single model. By not making any
arbitrary restriction on the choreography language we in fact allow both.
But we are not going into implementation. An implementation that is not a
composition of Web services requires a different approach that is outside of
scope.

arkin

>
>
>
> --
> Professor James Hendler				  hendler@cs.umd.edu
> Director, Semantic Web and Agent Technologies	  301-405-2696
> Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
> Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
> http://www.cs.umd.edu/users/hendler

Received on Tuesday, 18 March 2003 06:07:04 UTC