RE: internal vs external

I don't know if this has been mentioned, but I was under the impression
that in certain industries, specifying your internal steps (e.g. as a
supplier to Boeing) was very part of the contract for regulatory
reasons.

I also think that there is a very important set of scenarios that can be
modeled and managed by ws-chor which involve "firewall transparency". In
other words, I want to be able to describe choreographies where
sometimes, I require the services of a partner, and sometimes, I can do
it myself (sounds very common during design activities where sometimes
you contract the design to suppliers), as a matter of fact both cases
can happen in the same unit of work (e.g. designing a car) at run-time.
So the border line between what is external or internal can only be
resolved at run-time. 

IMHO, being able to define both public, and semi-private choreographies
is a requirement. Semi-private would at least match the two use cases I
have given above.

JJ- 
 
 

>>-----Original Message-----
>>From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]
>>On Behalf Of Assaf Arkin
>>Sent: Monday, May 05, 2003 3:23 PM
>>To: jdart@tibco.com
>>Cc: Champion Mike; public-ws-chor@w3.org
>>Subject: Re: internal vs external
>>
>>
>>This of course raises the question what is ment by exposed?
>>
>>Let's say you want to rent an apartment and you go to some rental
agency
>>service. Some renters insist on obtaining a credit report from a
credit
>>agency. The fact that they do so has legal implications. First, they
>>need to alert you that they will obtain that information and in
essence
>>ask for your permission. They cannot do so unless you have completed a
>>state clearly indicating that the next step would involve them
obtaining
>>a credit report. Second, a record of the query is made in your report
>>and there are some implications to having too many queries within a
>>given time frame. And third, if the request is rejected based on lack
of
>>credit you are entitled to receive a free credit report from that
agency.
>>
>>So the fact that a credit report is being obtained is of interest to
>>you. How the credit report is being obtained is definitely not
>>interesting and not something a rental agency would be happy to tell
>>you. It may be a person calling up the credit report company on the
>>phone and asking for details, they definitely don't want to tell who
>>that person is. The messages exchanges are absolutely not of interest
to
>>you. You should never receive a credit report from the rental agency,
if
>>you need it you should contact the credit agency.
>>
>>So now you have three things that could potentialy be exposed:
>>
>>1. The fact that something happens that has a direct/indirect effect
on
>>you described as one of the steps that will take place
>>2. How that thing will happen, i.e. who will actually be contacted,
how,
>>when, etc
>>3. What actually happens, i.e. the actual information that is being
>>exchanged
>>
>>I am hard pressed to think of any use case where you would want to
>>expose #3 i.e. magically making the message exchange between X and Y
>>available to Z (snooping?), other than by sending Z all the relevant
>>information. Sometimes the information in #2 is interesting, i.e.
which
>>credit report has been contacted (the one you should call to get your
>>free copy), but that should be communicated to you explicitly, other
>>information like who contacted them and when is not interesting. In
>>fact, if I remember correctly it's the credit report that gets your
>>contact information and sends you a notice. But #1 is interesting and
>>there are other cases along these lines, usually involving the fact
that
>>your information is presented to some 3rd party or the fact that
>>interaction with a 3rd party is made on your behalf.
>>
>>The rule I stand by is "what you don't need to expose should not be
>>exposed. period". I would not be interested in supporting a language
>>that forces me to expose to any party how I happen to do things when I
>>service their requests. Except in those case where I do need to expose
>>that information for the benefit of these parties as agreed upon by
all
>>parties involves (in this case customer, rental agency, credit
agency).
>>My question is therefore how do I deal with those cases that do
require
>>some specific steps to be exposed in a controlled manner as dictated
by
>>the business scenario?
>>
>>arkin
>>
>>
>>Jon Dart wrote:
>>
>>>
>>> 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.
>>>
>>> --Jon
>>>
>>> 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 ,,,
>>>
>>>
>>>
>>
>>
>>--
>>"Those who can, do; those who can't, make screenshots"
>>
>>----------------------------------------------------------------------
>>Assaf Arkin                                          arkin@intalio.com
>>Intalio Inc.                                           www.intalio.com
>>The Business Process Management Company                 (650) 577 4700
>>
>>
>>This message is intended only for the use of the Addressee and
>>may contain information that is PRIVILEGED and CONFIDENTIAL.
>>If you are not the intended recipient, dissemination of this
>>communication is prohibited. If you have received this communication
>>in error, please erase all copies of the message and its attachments
>>and notify us immediately.
>>

Received on Monday, 5 May 2003 16:09:37 UTC