OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

bcm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [bcm] Web Services and Process definitions


Title: Message
It seems that I need to get back into BCM.  I have been doing 'back to basics' with SOA and web services.  Maybe soon on one  of our telcons I can share just 15 minutes of what they are. 
 
I agree with Bruce of not complicating things more than need be.  Focus on the business, web services are only enablers to us to provide services.  I am seeing too much focus on technology out there again without regards to the business.  So, our duty in this BCM is to focus the industry, community back on business. 
 
I will be joining back,  so will catch up next call.  Let me know what the number to call and the time. 
 
Looking forward to getting back involved you all,
 
Laila Moretto
-----Original Message-----
From: Bruce Peat [mailto:BPeat@eProcessSolutions.com]
Sent: Wednesday, June 16, 2004 9:20 PM
To: David RR Webber
Cc: bcm@lists.oasis-open.org
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 -----
From: "David RR Webber" <david@drrw.info>
To: "Bruce Peat" <BPeat@eProcessSolutions.com>
Cc: <bcm@lists.oasis-open.org>
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.
>
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]