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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

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


Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract Requirements for State Alignment


Martin,

That is why I've been careful here to ensure this is
really an extended set of functionality - with
checks and controls at a fine level - so by
default this is *not* the norm.  Frankly
I only expect a few people to use this - for
special needs and criteria - because the
tried and proven request/response with guards
works very nicely already.

I've certainly modelled it that way.

But my sense is here - is this is as much about
marketing and PR as anything else.  If BPSS
can do this - then 'nay sayers' will be persuaded
that its not just some flimsy modelling approach -
but can actually be a full-up production solution
that can be integrated into todays existing
environments such as JBoss, BEA, etc.

I believe this is a vital message for us to drive
home with V2.0 as an OASIS standard.
OASIS has that mark that says
"Implementation Ready", and we certainly saw
that this made a big difference for ebMS and
Registry too.

Thanks, DW

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <david@drrw.info>; <Monica.Martin@Sun.COM>; <anderst@toolsmiths.se>;
<yunker@amazon.com>; <nagahashi@fla.fujitsu.com>; <jeanjadu@Attachmate.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, June 15, 2004 11:35 AM
Subject: RE: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
Requirements for State Alignment


Hi,
I know I am not partaking much these days but on this subject I
have some views.

beginsWhen and endWhen were effectively comments on the
transaction in 1.01 and the CEFACT 1.1.  Moving away from this to show
some other flow or usage needs to be very, very carefully thought
through.  I would be unhappy to see that these are used as a back door
event based solution.  I know that is what they were aimed at
originally, it is just that the implications of this are to make the
processes more complex.

Martin Roberts
xml designer,
BT Exact
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info]
Sent: 15 June 2004 15:29
To: Monica J. Martin; Anders W. Tell; Yunker, John; Kenji Nagahashi;
Jean-Jacques Dubray
Cc: ebXML BP
Subject: Re: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
Requirements for State Alignment


Monica,

Not wanting to preempt discussion on Friday - but just wanting to throw
out some technical ideas.

What if we linked the signals to the begins/endsWhen conditionals on a
BT?

Just like with my proposal around linkage to context statements using a
nameRefID - we could easily point to a named signal (it has that
attribute already) and it would be either then boolean true or false.
eg:  beginsWhen="#mysignal-Is-On"

This still leaves how the signal itself gets set of course!  Seems like
Dales post earlier may fit / hint into that category...since the only
attribute in the signal right now is the URI - how does one actually
turn a signal on?!

If we can crack that "glue" then I believe we can provide
what we need here.

Am I also right in thinking that essentially used in this way the
signals actually constitute the equivalent of an immediate "break"
command so familiar in procedural languages to escape into/out of the
current logical block.  In our case that is of course a BT.

DW

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "Anders W. Tell" <anderst@toolsmiths.se>; "Yunker, John"
<yunker@amazon.com>; "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>;
"Jean-Jacques Dubray" <jeanjadu@Attachmate.com>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Tuesday, June 15, 2004 1:53 AM
Subject: [ebxml-bp] [ebBP] Tell 6/14/2004: Business Contract
Requirements for State Alignment


> Today's ebBP call surrounded how we ensure (as much as practical)
> state alignment. Kenji Nagahashi proposed we provide additional
> constraints on web services (top-down approach - business process to
> web services).  We would like to more fully discuss the business
> contract requirements related to: State alignment and business
> signals.  Here are some of the questions that arose (from John Yunker
> particularly):
>
>     * How do signals give you state alignment? How do we get certainty
>       from a business perspective?
>     * How does the contract layer use the state alignment will help us
>       relate the special business timeouts to the technical signal
>       receipt.BPSS provides a semantic to the contract layer.  The
>       business level timeouts in addition to the protocol level have
to
>       be recognized.
>     * How does the contract layer use the state alignment. This will
>       help us relate the special business timeouts to the technical
>       signal receipt. [1]
>
> The bullets above can form the agenda (subject to team input).  Any
> member is welcomed to attend. Those expressing an interest today were:

> Yunker, Dubray, Nagahashi and Moberg (and myself).
>
> You have indicated you would be available Friday and Monday (6/21).
> Let's try, as discussed:
>
>     * 877 330 9868, international 909 472 3386, when prompted hit **,
>       then passcode 09868.
>     * Time: 9 a.m. PDT, 6 p.m. CET, 18 June 2004.
>     * Agenda above.
>
> Thanks.
> [1] Steve Capell, RedWahoo question.
>
>
>




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