[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-cppa] RE: [ebxml-cppa-negot] RE: BSI distinguishing success,failure, and transition conditions
Tony,
(copied to CPPA list)
Some comments below.
Regards,
Marty
*************************************************************************************
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
*************************************************************************************
"Tony Fletcher"
<tony_fletcher@btope To: "Nickull, Duane \(ebXML\)" <duane@xmlglobal.com>, "BCPS \(list\)" <ebtwg-
nworld.com> bcs@lists.ebtwg.org>, Martin W Sachs/Watson/IBM@IBMUS, "bhaugen" <linkage@interaccess.
com>, "John Yunker" <john.yunker@bleuciel.org>
08/15/2002 06:00 PM cc: "Anarkat, Dipan" <DAnarkat@uc-council.org>, <ebtwg-bps@lists.ebtwg.org>
Subject: RE: [ebxml-cppa-negot] RE: BSI distinguishing success, failure, and transition
conditions
Dear Marty, Thanks for your helpful responses to my messages. I have note
posted this message to any of the CPPA lists, please post to those, or not,
as you feel appropriate.
Dear All,
There have been two many messages for me react to - and I would have like
to
react to most of them!
A few quick points:
1. It seems to me that we do not have a clear specification of the BSI in
the ebXML architecture, although some of the ebXML documents do mention it.
MWS: Actually, the BPSS spec does define that BSI function that is needed
to support collaborative choreography.
I suspect my idea of what it might be is different from most other peoples
and that everyone else is assuming everyone else has the same view as they
do! Coming to think of it, it seems to me that part of the problem is that
that the current UeB Architecture document only really shows the
specifications under development at present within ebXML. It is very weak
(only has a short non-normative section) on an overall implementation
architecture. If this existed properly then it would show and describe the
BSI (if it becomes an agreed and specified component) and where the driving
application sits.
MWS: The problem here is walking the line between properly describing the
function in each part of ebXML and overly constraining implementations.
2. I view a BPSS instance as providing configuration information for a
business engine (BCP?). It gives the states, etc. and when signals can be
sent, but note that it does not provide content for the request and
response
(because that has to come from the driving application, nor whether a
positive or negative signal is sent (so to answer Bob H - see mail way
below: a driving app may not be able to syntactically construct a signal -
that may be done in BSI / BCP, but surely it must invoke the signal, saying
pos or neg and maybe provide some parameters.
3. I notice few people seem to mention or position BCP
4. Bob your layer model is a start on a proper implementable architecture
for ebXML
<Bob>I think the layers (from the bottom) include:
* Message handler
* Transaction manager
* Collaboration manager
* Collaboration business objects
(what eBTWG-BET is working on)</Bob>
What about BCP (I assume it is Transaction manager + Collaboration
manager).
Would not the Collaboration business objects not be a separate layer, but
rather be off the side of the Collaboration manager. Need to show the
driving application
5. I have hauled in a piece from John Y
<JY>A definition of Business Service Interface? First we need to define
Application Service Interfaces.
An Application Service Interface enforces the technical content and timing
of messages contained in the interface specification, and provides standard
APIs for applications to access and trigger interface instances.
A Business Service Interface sits on top of an Application Service
Interface, enforces the business rules contained in the interface
specification, and provides standard APIs for business to monitor and
control business interaction instances
At this point in time, our interface specifications are short on the
descriptions of business success, and long on descriptions of message
technical compliance.
We are very new on the road towards Business Service Interfaces.
</JY>
This seems to prove the point about everyone having rather different ideas!
This seems to have the BSI well up the stack above an ASI and certainly not
incorporating messaging, Tx Manager, etc.
6. I have copied this message to Duane, as I think my main point is that
it
would be very helpful if the architecture document actually did 'come
clean'
on what you need to do to implement ebXML - give the overall conformance
roadmap if you like. To help start this debate I attach a couple of
slides,
the first shows the current informative implementation architecture and the
second a proposed normative one. It shows BCP and Business Objects and
business data and the positioning of the two key APIs. While the APIs are
not currently specified in ebXML (but could be as JSR for instance) and the
business application never would be (as an ebXML spec), the remainder are
(or are on the way). It does not include BSI because we do not have a
spec.
for it or even one in the making - could identify it with BCP or perhaps
the
lower half of BCP or maybe the BCP - messaging API.
Having (I hope) kicked of a debate on the ebXML implementation architecture
I am now going on holiday for a couple of weeks - be interesting to see
whether we have converged on an agreed diagram while I am away.
Best Regards Tony
A M Fletcher
Cohesions 1.0 (TM)
Business transaction management software for application coordination
Choreology Ltd., 13 Austin Friars, London EC2N 2JX UK
Tel: +44 (0) 20 76701787 Mobile: +44 (0) 7801 948219
tony.fletcher@choreology.com <mailto:tony.fletcher@choreology.com>
(Home:
amfletcher@iee.org <mailto:amfletcher@iee.org> )
-----Original Message-----
From: Martin W Sachs [mailto:mwsachs@us.ibm.com]
Sent: 15 August 2002 16:36
To: bhaugen
Cc: Anarkat, Dipan; ebtwg-bps@lists.ebtwg.org; Tony Fletcher
Subject: Re: [ebxml-cppa-negot] RE: BSI distinguishing
success,failure,andtransition conditions
Bob
I was a bit fuzzy because I overlooked the business signals. The receipt
ACKs etc. can clearly be generated by application-independent middleware
provided that it is properly instructed by, say, the BPSS instance.
However in my fuzzy way of thinking, the choreography is really driven by
the business-application documents; the signals are supporting function and
drive the choreography to the next step but the signals are the result of
business-application document flows.
By the way, getting back to your earlier question: One way to think of the
functional split between application and middleware is this: The upper
interface of the B2B middleware is the API which would be used by a
collaboration-aware business application. From this viewpoint, the
connector that is used to enable a collaboration-unaware application to
collaborate would be in the application domain. As to "What's in a BSI",
one of the ebXML specs actually does define it from its own viewpoint. The
BPSS defines the function in a BSI as the monitoring function plus
generation of business signals. Such a BSI might be right on top of the
MSH but there will most likely be other middleware components between the
BSI and the application.
Regards,
Marty
****************************************************************************
*********
Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287; IBM tie line 863-7287
Notes address: Martin W Sachs/Watson/IBM
Internet address: mwsachs @ us.ibm.com
****************************************************************************
*********
bhaugen
<linkage@interacc To: Martin W
Sachs/Watson/IBM@IBMUS
ess.com> cc: "Anarkat, Dipan"
<DAnarkat@uc-council.org>, ebtwg-bps@lists.ebtwg.org, Tony
Fletcher
<tony_fletcher@btopenworld.com>
08/15/2002 10:57 Subject: Re:
[ebxml-cppa-negot] RE: BSI distinguishing success,failure,a ndtransition
AM conditions
From: Martin W Sachs
> That's getting right to the heart of the matter! No, I have never
seen a
> spec of a BSI (other than Stefano's original proposal and IBM
Research's
> BPF) nor have I ever seen a spec of the upper interface of a MSH.
Some aspects of a spec will be forthcoming from the
eBTWG Business Collaboration Protocol group.
> The lack
> of such specs has caused us untold amounts of confusion and wasted
> discussion over the past couple of years because none of us have the
same
> view as anyone else about the functional distribution above the level
of
> putting messages on the wire and taking them off at the other end..
I fully agree, and said so when Stefano first made his proposal.
> All of
> the functions you list are middleware functions of some kind. Without
a
> spec of what a BSI does, it's hard to say if all of them are in it.
The
> bottom line is still that all this stuff is driven by messages that
> originate (in some form or other) in a business application, not by
some
> middleware being driven by the BPSS instance.
Either you're going fuzzy, or I partly disagree.
Let's say one business app is a purchasing app,
and its counterpart on the seller's end is order mgmt.
For example: in an offer-acceptance transaction
where the first message payload is a purchase order,
the PO may have originated in the purchasing app,
but the receipt acks and responding acceptance
or rejection document probably did not originate
in any of the business apps, because they don't
know how to generate them. Those messages
originated in the collaboration middleware.
-Bob Haugen
----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.ebtwg.org/ob/adm.pl>
#### Tech_Arch_Comments2.ppt has been removed from this note on August 15
2002 by Martin W Sachs
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC