Bruce,
I think this is crucial - it's about developing
robust patterns
for business interactions - that have clear
business
functional characteristics. Right now
this is being
obfuscated and downplayed by the marketing folks
IMHO.
I do not care if you are using http-binding or
foobar - I do
want a consistent way of representing the QoS
and
interaction profiles. That way I can compare
apples
to apples.
More importantly if my business need
requires
a reliable service - I can guarantee I'm getting
one -
whereas right now people only *think* they
are
getting this - whereas in reality that only
applies
on sunny days with light winds!
Handling the exception conditions in a
robust
and deterministic way is challenging.
That's why I like the patterns that BPSS
is
allowing me to develop. It's clear and
inituitive
what is going on - and that's what we
need
right now - good profiling of complex
technology.
DW
----- Original Message -----
Sent: Wednesday, June 16, 2004 9:19
PM
Subject: Re: [bcm] Web Services and
Process definitions
Certainly - HTTP 404 - your
message didn't go through...
"The server has not found anything matching
the Request-URI. No indication is given of whether the condition is temporary
or permanent."
And why did you bring up email???? A
RESTful doesn't use email - does "http-binding interface?"
The return to the post contains all information
required.
Keep it simple. The BCM dialog seems to be
doing a deep dive into complexity/technology.
- Bruce
----- Original Message -----
Sent: Wednesday, June 16, 2004 1:42
PM
Subject: Re: [bcm] Web Services and Process
definitions
Bruce,
Absolutely! Those are all built-in to BPSS - but
not to a http-binding interface. You would need to add those
capabilities.
Notice while you can add in those capabilities
its weak.
Example - I'm paying by CC online - and it says "Click
here to authorize payment and wait...".
So eventually if everything
goes OK - you get a screen saying - Payment Approved - and an email
confirming that.
However - what happens if you get a
HTTP404 instead? Did your payment go thru? And what if you
get no confirming email? Is the email hung-up somewhere - is the
email address OK - did it get zapped by anti-spam gateway?
Obviously
using an ebMS client gives you much more control over the
process.
DW
----- Original Message ----- From: "Bruce Peat"
<BPeat@eProcessSolutions.com> To: "David RR Webber" <david@drrw.info> Cc:
<bcm@lists.oasis-open.org> Sent: Wednesday, June 16, 2004 11:50 AM Subject: Re: [bcm]
Web Services and Process definitions
> I certainly do know if
the information has passed - what are you talking >
about?? > > I first know if I got to the URL, and then I can build
in a business > acknowledgment. You haven't forgotten checking if
the message can be > interpreted correctly AND MAKES SENSE have
you? > > - Bruce > > > ----- Original Message
----- > From: "David RR Webber" <david@drrw.info> > To:
"Bruce Peat" <BPeat@eProcessSolutions.com>; <bcm@lists.oasis-open.org> > Sent: Wednesday, June 16, 2004 10:47 AM > Subject:
Re: [bcm] Web Services and Process definitions > > >
Bruce, > > We are going to have to send you in for some
re-education! > > RESTful is passe - its now called
http-binding. > > Jean-Jacques issued a huge rant this week on
BPSS list - vis > this topic. Basically - how do I put this
politely? - http-binding > isn't worth squat when it comes to reliable
stateful business > interactions. You have no way of verifying
anything happened, > that anyone got anything, nor what state a process
has reached. > Apart from that - its great!! ; -) > > JJ was
actually recounting his e-banking experience with a > major bank - and
his credit-card bill and their use of webpages > and emails - same
grab-bag. The bank *thinks* this is all > reliable messaging
services - when in fact its not. And they > don't care - because
they just apply late charges anyway!! > > So - http-binding - and
its just fine for things like query to > registry - information pull -
but be very careful otherwise... > > Cheers, DW. > >
----- Original Message ----- > From: "Bruce Peat" <BPeat@eProcessSolutions.com> > To: <bcm@lists.oasis-open.org> >
Sent: Tuesday, June 15, 2004 10:58 PM > Subject: Re: [bcm] Web Services
and Process definitions > > > > I prefer RESTful services
myself - simpler. > > > > - Bruce > > >
> > > ----- Original Message ----- > > From:
<nwasserman@adaptiveservices.com> > > To: <MIKE.LUBASH@DFAS.MIL>;
<bcm@lists.oasis-open.org> >
> Sent: Tuesday, June 15, 2004 4:58 PM > > Subject: RE: [bcm] Web
Services and Process definitions > > > > > > I
think it's important to distinguish web service, as a technical
means to > > capture loosely coupled, encapsulated interactive
components, from > business > > services or business service
components, which can be delivered with a > > number of different
vehicles (automated on the web, outsourced, human). > > Since web
service has become embedded as a term of art for the automated > >
vehicle, I don't think it's wise to change its usage. > > >
> For the technical web service, loose coupling works. But for
the business > > service interaction, it may be useful to think of
the service in terms of > > "rich coupling", by which I mean that
the service can respond to a complex > > set of information
characterizing the needs of the service recipient. > > There may be
differing degrees in the "richness" of the coupling. Using a >
> biological metaphor, not all organs have to be equally adaptive to
the > > outside environment. Likewise, some service components
may be specialized > > to support interaction with complex service
recipients like human beings. > > Other service components can get
by with less rich interactive > > capabilities, such as those that
deal with standard databases, and > > communications protocols.
In between these poles would be service > > components such as
semantic brokers. Not to make things too complicated, > >
maybe there is a spectrum of interactivity with "process" at the >
procedural > > end and "service" at the service-recipient-oriented
end. > > > > Neil > > > > > >
-------------------------------------------------------------------- >
> mail2web - Check your email from the web at > > http://mail2web.com/ . >
> > > > > > > To unsubscribe from this mailing
list (and be removed from the roster of > the > > OASIS TC), go
to > > > http://www.oasis-open.org/apps/org/workgroup/bcm/members/leave_workgroup.php. > > > > > > > > To
unsubscribe from this mailing list (and be removed from the roster of >
the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/bcm/members/leave_workgroup.php. > > > > > > > To
unsubscribe from this mailing list (and be removed from the roster
of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/bcm/members/leave_workgroup.php. > > > > To unsubscribe from this
mailing list (and be removed from the roster of the OASIS TC), go
to http://www.oasis-open.org/apps/org/workgroup/bcm/members/leave_workgroup.php. > >
|