W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

Re: internal vs external

From: Jon Dart <jdart@tibco.com>
Date: Mon, 05 May 2003 11:23:22 -0700
Message-ID: <3EB6AC1A.40001@tibco.com>
To: "Champion Mike" <Mike.Champion@SoftwareAG-USA.com>
CC: public-ws-chor@w3.org

This was discussed at the F2F, without resolution.

IMO there are situations where there is a clear distinction and it is 
non-problematic. One such class of situations involves B2B interactions. 
If I am dealing with business transactions over the Internet, even with 
trusted parties, I am typically fairly paranoid about exposing internal 
systems to said parties. For example, in servicing an incoming request, 
I may interact with systems (possibly web service-enabled, possibly not) 
to which I don't give external parties any direct access. In fact, I 
enforce that they have no direct access by employing a firewall.

Another less clear case is one where certain parts of my processing of a 
request may expose parts of my business I regard as proprietary or 
confidential. For example, I may have outsourced credit checks to a 
third party. Perhaps I don't want the world to know which third party I 
am using. Technically speaking the third party is part of my overall 
choreography; but I want it to be invisible to my business partners.

So one possible definition of "external" is related to visibility. If a 
party interacting with me can know about an interaction I have with a 
third party, or with some internal system I control, then that part of 
the choreography is "external". Otherwise it's internal, with respect to 
the party that is viewing and interacting with the choreography.

The "relativity" of this definition may be bothersome, however.


Champion, Mike wrote:

> Sheesh, having spent WAY too much of my life trying to define "web 
> service" and more recently "synchronous" and "asynchronous" 
> there ain't NO WAY I'm going to try to define "internal" and 
> "external."  :-)   
> But from my limited unstanding of the situation (not having been at the 
> F2F and not deeply understanding all that BPEL is trying to do), here's 
> the way I see it:  BPEL is a "business process execution language" if 
> the acronym still has any meaning.  I think of the implementation of the 
> business process in BPEL (or some other language) as the "internal" 
> definition, whereas an "external" definition would specify what an 
> outside party would need to know to participate in the business 
> process.  It's analogous to "interface" [external] vs "implementation" 
> [internal] in OO.    It is, however, more complicated because the 
> "caller" can't just send an RPC message invoking the interface API (not 
> caring what it is bound to) and getting an answer back; the "caller" has 
> to understand the various responses and how to respond to them 
> appropriately.
> My gedankenexperiement / example is a robot that is asked to go get me a 
> cup of coffee.  It can go to the cafeteria and interact with humans, or 
> to any number of vending machines, or send a SOAP message to Starbucks, 
> or whatever.  In either case, let's say that all parties agree to follow 
> a pre-agreed choreography that would specify the steps: place an 
> request, get confirmation that the request can be fufilled and the 
> price, allow N iterations of alternate requests, confirm the order, 
> receive the product, pay the price, done. [Or whatever, I'm making this 
> up!]  The robot shouldn't have to be aware whether Starbucks implements 
> this with BPEL or Python or whatever, or whether the vending machine is 
> hardwired or software driven, just how the steps of the "external 
> interface" choreography are "bound" onto an underlying protocol ("press 
> the buttons, look at the lights, etc." vs "send a SOAP message X, get 
> response Y or Z"). 
> So, the agreed upon choreography with messages, replies, and shared 
> state description is the "external" interface.  The impelentation in 
> terms of BPEL, hardwiring, or a Cafeteria Procedure Manual is 
> "internal."   I suspect that there are all sorts of ratholes here when 
> we start thinking about real web services rather than thought 
> experiements and that these distinctions will be blurred in reality, but 
> that's how I think of the issue.
> If this is totally wrong / trivial / irrelevant / unresponsive to the 
> question, my apologies ... I'm at least as confused as everyone else, 
> but offer this as a strawman.  Set it aflame if you wish ,,,
Received on Monday, 5 May 2003 14:23:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:00:58 UTC