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 15:25:26 UTC