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] IBM to Support BPEL-Based Web Services


ZB,

I'm just trying to get the easy bits working!

However - if you have excellent modelling tools for
describing BPSS - then I believe you have shown
that it is in fact a strong technology for describing the
business process flow - and this indeed is the crux
of what V2.0 and then V3.0 are delivering IMHO.

We first encountered this in the AutoTech scenarios -
see:

 http://drrw.net/visualscripts/#ebXML

Making these fully functional in BPSS is the challenge,
and I am certain that with BPSS V2.0 this is now
possible - just my models need some attention to
fix them - and that's my goal here - to use BPSS
V2.0 and validate the scenarios.

Thanks, DW.

----- Original Message ----- 
From: "ZBarch" <zbarch@rcn.com>
To: "David RR Webber" <david@drrw.info>; "Kenji Nagahashi"
<nagahashi@fla.fujitsu.com>
Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Sunday, April 18, 2004 5:59 PM
Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web Services


> David,
>
>
>
> It seems to me Kenji meant under "automation" the ability of BPSS to be a
>
> so called "configuration" file for Business System Interface (BSI) - i.e.
> automation
>
> of runtime execution of business transactions. If BPSS will be able to
> define
>
> such configuration file,  it will, in turn,  allow building of  the
generic
> BSI application,
>
> which will be simply configured for each particular instance of eBusiness
> implementation.
>
> The Business process flow definition doesn't look like the strongest side
of
> BPSS in its present status.
>
>
>
> What IBM has done is very simple - based upon BPEL they've built some
EJBs,
> included them into
>
> Websphere plus Web Service support (kill two rabbits with one bullet).
It's
> a strong market pitch, taking into
>
> account the current mind set of CIOs and CEOs.
>
>
>
> ZB
>
>
> p.s. By the way, I could build a prototype of this generic BSI in 4-6
months
> having a sponsor with spare $200K -250K.
>
> ----- Original Message ----- 
> From: "David RR Webber" <david@drrw.info>
> To: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
> Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
> Sent: Friday, April 16, 2004 10:54 PM
> Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web Services
>
>
> > Kenji,
> >
> > I would disagree here.
> >
> > I have built a BPEL editor as well as a BPSS one.
> >
> > BPEL - as John Yunker so rightly noted - represents
> > climbing Mount Fuji - just to make a cup of tea
> > every morning.
> >
> > Joe Chiusano has come the closest I've seen to
> > defining a simple approach to BPEL - but that
> > suffers from being too simplistic.
> >
> > Don't forget before you can write any BPEL - you
> > first have to learn and write WSDL.  It could not
> > be more complicated if you tried!
> >
> > BPEL really is in danger of being a mini-4GL -
> > and then there are three ways of doing most
> > things - so which one do you pick and why?
> >
> > Now of course Microsoft and IBM have tried
> > to hide all this underneath GUI interfaces that
> > write it all for you.  The snag then is that the
> > BPEL it creates will only work inside their
> > toolset (naturally!) and nowhere else.
> >
> > Maybe you can reserve judgement on just
> > what kind of lowlevel trickery is needed in
> > BPSS - my sense is not much.
> >
> > My experience is that for building
> > eBusiness process definitions BPSS has
> > an excellent feel to it - and the right level
> > of detail and control mechanisms to make
> > it attainable by business designers (this was
> > John Yunkers another point).
> >
> > That is why I am focused on the editing
> > tool as the way to bring realization to the
> > marketplace.  Once business designers
> > realize they can do this themselves quickly
> > and easily and are not beholden to a
> > classic situation where BPEL programmers
> > have to dictate everything to everyone else,
> > as technology, not business - then the
> > better off everyone will be.
> >
> > I believe there is every much chance that
> > the marketplace will reject BPEL as being
> > too complex and too arcane.  I say this
> > because I've seen alternative process control
> > scripting built by another market leader in
> > this space - and their approach was compelling
> > and simple.   Therefore my conclusion is
> > that's only a matter of time before we have a
> > Python style event horizon and someone like
> > a James Clark is talking up their simpler easier
> > method....
> >
> > DW.
> >
> > ----- Original Message ----- 
> > From: "Kenji Nagahashi" <nagahashi@fla.fujitsu.com>
> > Cc: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
> > Sent: Friday, April 16, 2004 10:00 PM
> > Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web Services
> >
> >
> > > Hi,
> > >
> > > David, I think you're misisng Duane's point... He's talking about
> > > prioritization for greater market.
> > > I see there are views on BPSS: One view puts higher priority on
> > > "documentation", and the other puts higher priority on "automation".
> > > For automation purpose, we need to define very formal and detailed
> > > computational model for the language, pretty much like BPEL is doing.
We
> > > need lots of implementation experience for this goal...
> > >
> > > And my personal view is that "automation" almost always gets greater
> > > market share.
> > > See how BPEL is doing.  BPEL attracted many people for the ability to
> > > automate the process and some BPEL engine has been built before any
> > > design tools. If language can provide automation with good level of
> > > abstraction, people just use it even if no good GUI is available for
it.
> > > How people used C compiler before Visual C?. How people used HTML
before
> > > any web authoring tools?
> > >
> > > I'm not saying "automation" view is right and "documentation" view is
> > > not. "documentation" is an important usage of BPSS. And it is also
> > > important to think about what BPSS can do for "automation". I'm just
> > > wondering if many in ebBP are interested in this aspect.
> > >
> > > Duane, thanks for your kind words for our Ottawa presentation... It
was
> > > a great opportunity for both of us!
> > >
> > > Regards
> > > Kenji
> > >
> > > David RR Webber wrote:
> > >
> > > > Duane,
> > > >
> > > > Its a Catch22 - and also resources.
> > > >
> > > > However - I can build the designer tools for V2.0 in a few days.
> > > >
> > > > Once I have those - then that creates more of a compelling
> > > > reason for the announce on the open source BPSS engine.
> > > >
> > > > DW
> > > >
> > > > ----- Original Message ----- 
> > > > From: "Duane Nickull" <dnickull@adobe.com>
> > > > To: "David RR Webber" <david@drrw.info>
> > > > Cc: "Matthew MacKenzie" <mattm@adobe.com>; "ebXML BP"
> > > > <ebxml-bp@lists.oasis-open.org>
> > > > Sent: Friday, April 16, 2004 4:01 PM
> > > > Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web Services
> > > >
> > > >
> > > >
> > > >>
> > > >>David RR Webber wrote:
> > > >>
> > > >>
> > > >>>My top priority coming few weeks is to get BPSS V2.0
> > > >>>editing tools done - so people can build their
> > > >>>process models easily.
> > > >>>
> > > >>>Next up we need someone to announce an open source
> > > >>>BPSS engine... room for a joint collaboration on this
> > > >>>me thinks.
> > > >>
> > > >>This is highly illogical.  Who would have a need to have BPSS design
> > > >>tools or BPSS before you have an engine to run them.  I would argue
> for
> > > >>execution engine first, then the designer toolsets or at least at
the
> > > >>same time.
> > > >>
> > > >>Fujitsu demonstrated some pretty cool stuff in this space in Ottawa
> last
> > > >>month.
> > > >>
> > > >>Duane
> > > >>
> > > >>
> > > >>
> > > >>-- 
> > > >>Senior Standards Strategist
> > > >>Adobe Systems, Inc.
> > > >>http://www.adobe.com
> > > >>
> > > >>
> > > >>
> > > >>
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>



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