[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]