RE: Internal/External questions - scribed from f2f 1

Yoko

You are right. I should have said ...

 >>>I think we do have to do both at the same time as the internal is
*partially* constained by the external.

David
-----Original Message-----
From: Yoko SEKI [mailto:y-seki@sdl.hitachi.co.jp]
Sent: Tuesday, March 18, 2003 11:03 PM
To: public-ws-chor@w3.org
Subject: Re: Internal/External questions - scribed from f2f 1




Hi David and All,

"Burdett, David" wrote:
> 
> >>>From the discussions last week, it is clear that we want to do
> "external," even though the details have not been defined. What is not
clear
> is whether we should do "internal" at the same time.<<<
> 
> I think we do have to do both at the same time as the internal is
constained
> by the external.
> 
> David

So do I.
In my opinion, "internal" may be more flexible in spite of some
constraints by the "external" such as I/O interface.

I think ws-choreography is available as a substitution for conventional
architectures such as CORBA.
Current business processes administrated "internally" based on their own
techs may be disconnected over firewalls.
"Internal" business processes defined by ws-choreography will address
this problem.

Best Regards,
Yoko

---
Yoko Seki
Hitachi, Ltd.
mail-to:y-seki@sdl.hitachi.co.jp
tel:+81-44-966-9111(ext:3219)
 
> -----Original Message-----
> From: Stephen White [mailto:swhite@SeeBeyond.com]
> Sent: Tuesday, March 18, 2003 9:58 AM
> To: public-ws-chor@w3.org
> Subject: RE: Internal/External questions - scribed from f2f 1
> 
> >From the discussions last week, it is clear that we want to do
"external,"
> even though the details have not been defined. What is not clear is
whether
> we should do "internal" at the same time.
> 
> I think that a technical justification for either position can be found in
> the relationship between the specifications that can be developed for each
> of them. Other factors, such as practical factors, can be addressed later.
> If you consider a stack of specifications, with WSDL as the baseline, then
> an "internal" and "external" specification could be layered on top of
WSDL.
> The question is whether the two are side-by-side or are layered with
> "external" above WSDL and "internal" above "internal." I have included a
> simple diagram to show these relationships.
> 
> If the two specifications can be demonstrated as being side-by-side, in
> spite of some overlap (Version B in the diagram), then the goal of this
> working group should be to only work on the "external" specification. But,
> if the two specifications are truly layered (Version A in the diagram),
then
> there is an argument that both specifications should be addressed.
> 
> -Steve
> 
> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Tuesday, March 18, 2003 3:06 AM
> To: Jim Hendler; public-ws-chor@w3.org
> Subject: 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 Wednesday, 19 March 2003 13:59:34 UTC