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] Fw: [wsbpel] FYI: BPELJ interview


IMHO, BPEL is a great concept to write model oriented business logic
(model as in Model-View-Controller).

In software engineering, there has been data structures and code since
the beginning of times. We have refined over the years how we define
data structures (it all started with a few registers sharing a few kb of
RAM with executable instructions) or write code, we have even combined
the two and labeled it OO. 

But a third construct has been introduced lately: the "message". It must
be raised at the primary citizen level because the level of connectivity
between processes has greatly increased. You can hardly find an isolated
process anymore and because of that the message must become a primary
construct of software engineering as more and more of the "code" deals
with exchanging messages with other processes. 

Up until now, messages have been hidden behind function/method calls (a
la CORBA) or APIs (a la socket). I don't think we have not quite yet
figured out the relationship between the 3. Pi-calculus says: everything
is a message exchange (i.e. by saying everything is a process, it
reduces everything to be a message exchange). This intellectual exercise
sounds elegant, but I quite don't buy that. I think that put this way it
shows how hopeless this direction is. I think that there is a formalism
(SO) that will combine all 3 three concepts just like OO combined data
and code. This will be the language of SOC. We have not just quite yet
figured it out. The closest the industry has gone is BPEL-J (I would
rather use JBPEL).

Now, how do you define business processes on top of an orchestrated
model? Well choreography/collaboration is IMHO, the closest way to think
about business processes: i.e. as a multi-party collaboration of peer
(orchestrated) entities.

I had discussion with Conrad Bock this week who explained me that UML
2.0 seem to suggest the same approach, we need to double check that we
are saying the same thing. 

Cheers,

JJ-



-----Original Message-----
From: David RR Webber [mailto:david@drrw.info] 
Sent: Friday, April 16, 2004 7:55 PM
To: BPSS ebXML
Subject: [ebxml-bp] Fw: [wsbpel] FYI: BPELJ interview

Errr.  As if to reinforce my point today.

Read on!

DW.

----- Original Message ----- 
From: "Ugo Corda" <UCorda@SeeBeyond.com>
To: <wsbpel@lists.oasis-open.org>
Sent: Friday, April 16, 2004 9:50 PM
Subject: [wsbpel] FYI: BPELJ interview


http://www.oetrends.com/news.php?action=view_record&idnum=324

Some interesting statements from the interview:

"BPEL sticks with core high-level logic, rather than drilling into
deeper, finer-grained, technical issues, such as data manipulation,
procedural logic, and integrating with non-web services interfaces".

"The whole world is not web services-based, so we have to ask ourselves,
does it make sense to wrap everything as a web services -- such as
access to files?"

"The idea of BPEL by itself is portability of process logic across
platforms and tools. But, I think the BPEL community understands that
that's only possible to a point".


So, are we giving up on BPEL interoperability and portability?

Ugo

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/wsbpel/members/leave_workgr
oup.php.




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