Matt,
IBM Global Services do not do $4B business a
quarter by
not shipping a few copies of MQ-Series
occasionally!
You forget I was weaned on IBM mainframes - you
think
I know something about MQ-Series, eh? ;
-)
I totally agree about the need to get tools and
message
out there.
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.
DW
----- Original Message -----
Sent: Friday, April 16, 2004 7:19
AM
Subject: Re: [ebxml-bp] IBM to Support
BPEL-Based Web Services
David (& Monica, I guess):
These slides are helpful.
Thank you.
Regarding MQ...you would be very surprised just how
ubiquitous it is. I don't say anything about agreeing with the
MQ-for-everything mentality that seems to be running rampant :-)
The
fact is that BPEL is going to compete with BPSS in ways that it shouldn't,
purely for reasons of ignorance and market penetration. The same thing happens
with ebMS and queue based solutions. And ebR and UDDI. The story that you guys
are starting to tell below has to get circulated widely,
soon.
-Matt
On Apr 16, 2004, at 12:06 AM, David RR Webber
wrote:
Matt,/smaller>/fontfamily> Monica
has some interesting slides for the F2F in New Orleans./smaller>/fontfamily> My
take is this./smaller>/fontfamily> o
BPEL === EAI with XML scripting instead of Java coding/smaller>/fontfamily> +
internal process mechanisms that typically/smaller>/fontfamily> are
not shared externally/smaller>/fontfamily> +
limited transaction handling capabilities/smaller>/fontfamily>
+ no context mechanism - instead coding to/smaller>/fontfamily>
suit bespoke needs/smaller>/fontfamily> +
roll your own patterns/smaller>/fontfamily> +
very programmer-centric/smaller>/fontfamily>
+ WSDL dictates a huge chunk of its behaviour/smaller>/fontfamily> pattern./smaller>/fontfamily> o
BPSS === inter-enterprise collaborative
processing/smaller>/fontfamily>
with mature models and patterns builtin/smaller>/fontfamily>
+ uses classic fullsized transaction based exchanges/smaller>/fontfamily>
+ supports context driven and role driven/smaller>/fontfamily>
mechanisms/smaller>/fontfamily> +
very business-centric/smaller>/fontfamily>
+ binary collaboration and multi-party collaboration/smaller>/fontfamily> patterns
with signals and flow control/smaller>/fontfamily>
+ conforms to international business law
patterns/smaller>/fontfamily> +
mostly neutral to transport layer/smaller>/fontfamily> So
- depending on who you are in the solution matrix - its/smaller>/fontfamily> pretty
easy to see which toolset you will
prefer. /smaller>/fontfamily> /smaller>/fontfamily> EAI
integrators - BPEL, eBusiness solution providers - BPSS./smaller>/fontfamily> And
nothing to stop you using both in tandem - with more/smaller>/fontfamily> support
for that coming in BPSS V3.0 - some (WSDL) in/smaller>/fontfamily> V2.0
already./smaller>/fontfamily> As
to MQ-Series being the uquitous solution - not really!/smaller>/fontfamily> BizTalk
server is more aimed at the common man than/smaller>/fontfamily> MQ-Series
- which is definately top endian. Then/smaller>/fontfamily> notice
that Cyclone, Sterling, and raft more solutions/smaller>/fontfamily> are
aimed at the significant market of people
choosing/smaller>/fontfamily> not
to buy things like MQ-Series./smaller>/fontfamily> DW/smaller>/fontfamily> -----
Original Message -----/x-tad-bigger>/fontfamily> /x-tad-bigger>From:/x-tad-bigger>
/x-tad-bigger>Matthew
MacKenzie/x-tad-bigger>/color> /x-tad-bigger>/fontfamily> To:/x-tad-bigger>/fontfamily>
/x-tad-bigger>David RR
Webber/x-tad-bigger>/color> /x-tad-bigger>/fontfamily> Cc:/x-tad-bigger>/fontfamily>
/x-tad-bigger>Duane Nickull/x-tad-bigger>/color> ; /x-tad-bigger>ebXML BP/x-tad-bigger>/color>
/x-tad-bigger>/fontfamily> Sent:/x-tad-bigger>/fontfamily>
Thursday, April 15, 2004 11:24 PM/x-tad-bigger>/fontfamily> Subject:/x-tad-bigger>/fontfamily>
Re: [ebxml-bp] IBM to Support BPEL-Based Web Services/x-tad-bigger>/fontfamily>
Everyone knows that I am a
huge ebXML proponent, but I must say that BP is the one component of our
stack that I am ambivalent towards. Why? First, its taken a long time to get
baked (although I applaud the process since the CEFACT/OASIS schism, and
think you people should be proud of your accomplishments). Second, pretty
much any good BP framework/standard can be integrated with the other ebXML
specifications. I think the winner in this space will be whoever gobbles the
most market share.
....and that ocean liner that is MQ-Series is
ubiquitous...and WSIF + BPEL makes J2EE architects and developers very
happy...and BPEL will be picked up by MSFT too. We have the makings for a
ubiquitous solution that people can use soon, and often.
I'd be
interested in an objective compare/contrast of what ebBP is doing versus
BPEL. What are the synergies, if anything. How can those of us who are
moderates in this debate promote ebBP in conjunction with
BPEL?
-Matt
On Apr 15, 2004, at 8:07 PM, David RR Webber
wrote:
Duane,
I never said it was vaporware!
I just
was stating there is nothing *interesting* here.
IBM has always
looked to be middle of the road - and rarely reaches to be wildly ahead
of the curve.
Paying $2B for Rational was a huge gamble for
them, and MQ-Series can hardly be viewed as a revolutionary product
set - its been around for 15+ years - and is the benchmark in
conservative integration tools.
Why would I think this
interesting, eh?
I know alot of those same ex-r's now working on
the Eclipse team too. ; -)
What I find interesting is technologies
that provide an open simple and agile infrastructure that enables a
broad and diverse marketplace.
MQ-series is an ocean liner - I'm
looking for something a little more nimble... ;
-)
DW.
----- Original Message ----- From: "Duane Nickull"
<dnickull@adobe.com> To: "David RR Webber"
<david@drrw.info> Cc: "ebXML BP"
<ebxml-bp@lists.oasis-open.org> Sent: Thursday, April 15, 2004 7:43
PM Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web
Services
David:
Let's not be negative on this. We will
likely be seeing more direction in IBM and other companies tooling
expanding from driving infrastructure toward a broader view of the
technical/developer's need. IBM is increasingly providing a comprehensive
set of both development time tooling for developers and an open-standards
based runtime expanding beyond a traditional application server on all
platforms. Their recent foray into the process area of the stack is
admirable IMO. A process driven, service oriented architecture (re Joseph
Chuisano's post) is being developed and converging or embracing other
ideas benefits everybody. I happen to have friends who can rebuke your
claims that it is marketing fluff and would back up the fact it is real
useable software. The real proof will be in the delivered developer
tools.
I was interested in opinions. I have noted that you believe it
is vaporware. Does anyone else care to comment?
Duane
David
RR Webber wrote:
Duane,
Still un-news - of course they are
providing a home-spun mix of Rational-Rose UML and using that to generate
BPEL and talking up process integration.
And MQ-Series itself has
a chunk of GUI configuration stuff that is required by human direction -
not to mention inputs from FAX, IVR or similar servers.
My
experience with these news puffs is - what you are reading into this is
nothing like what the sales guy who wrote the puff is thinking - even
though he uses words you think are cues to stuff that relates to your
work - they are not.
I bet if you called a local IBM sales office
and asked them they'd tell you - yeah that human stuff is our IVR
server interface - or similar.
Cheers, DW.
----- Original
Message ----- From: "Duane Nickull" <dnickull@adobe.com> To:
"David RR Webber" <david@drrw.info> Cc: "ebXML BP"
<ebxml-bp@lists.oasis-open.org> Sent: Thursday, April 15, 2004 3:13
PM Subject: Re: [ebxml-bp] IBM to Support BPEL-Based Web
Services
I found it most interesting. The ability to
incorporate "human or manual" processes in the midst of a automated
exchange, the runtime monitoring and execution debugging, bringing Web
services and BPEL execution to its iSeries and zSeries servers, the fact
that IBM is moving its' entire WebSphere product line to a more process
centric methodology all interested me.
Ignore it if you want but
the rest of this group might possibly consider what the ramifications are
to BPSS etc and at a larger level to ebXML. I have my own story but am
interested to know what others see.
Duane
David RR Webber
wrote:
Duane,
This just seems like a product pitch
for IBM - and an un-news item as clearly they wrote the darn spec' why
wouldn't they have it implemented?
Was there a specific
"interest" item here? I did not see anything.
DW.
-----
Original Message ----- From: "Duane Nickull"
<dnickull@adobe.com> Cc: "ebXML BP"
<ebxml-bp@lists.oasis-open.org> Sent: Thursday, April 15, 2004 2:31
PM Subject: [ebxml-bp] IBM to Support BPEL-Based Web
Services
Interesting read....
IBM to
Support BPEL-Based Web Services on iSeries in Q3 [good clear article on
some of the latest IBM websphere announcements]
BM's Software Group
is bringing Web services and Business Process Execution Language (BPEL)
execution to its iSeries and zSeries servers. IBM committed to deploying
WBISF 5.1 on z/OS during the second quarter of the year, and on OS/400
during the third quarter. The product is already supported on Linux
running on those two
server platforms.
http://www.midrangeserver.com/fhs/fhs041304-story03.html
-- Senior
Standards Strategist Adobe Systems,
Inc. http://www.adobe.com
-- Senior
Standards Strategist Adobe Systems,
Inc. http://www.adobe.com
-- Senior
Standards Strategist Adobe Systems,
Inc. http://www.adobe.com
___________________________ Matthew
MacKenzie Senior Architect IDBU Server Solutions Adobe Systems
Canada
Inc. http://www.adobe.com/products/server/ mattm@adobe.com +1 (506)
871.5409
___________________________/bigger>/color> Matthew
MacKenzie /bigger>Senior
Architect IDBU Server Solutions Adobe Systems Canada
Inc. http://www.adobe.com/products/server/ mattm@adobe.com +1 (506)
871.5409/smaller>/color>
|