2009/12/13 Ashraf Galal <[email protected]>:
>
>
> Please see my comments in-line.
>
> Anne Thomas Manes wrote:
>> +1 Steve.
>>
>> Ashraf -- I don't think I could disagree with you more.
>> While I think BPM and SOA ( or more precisely, process orientation and
>> service orientation) are complementary, a good architect always
>> recognizes that all "orientation" mindsets must be used appropriately.
>> And you should also recognize that these mindsets are based on
>> analysis and design principles--not on technologies.
>
>> BPEL is
>> irrelevant to both BPM and SOA.
> How come?!!
>
> *BPMN enables us to draw the representation of a business process, which
> is then mapped into the executable BPEL code, and executed directly on
> the SOA platform.
> *
>
> *SOA is about business content, business processes, aligning IT with the
> business, and optimizing the business processes.*

Having two sentences with the word "business" in them doesn't mean
they are linked.  SOA is about _thinking_ of solutions in a service
oriented way.  If you consider BPMN as the important piece and the
primary approach then you are doing PROCESS oriented architecture
(POA)

>
> Please correct me if i am wrong.
> **
>> As Steve says, you may decide to
>> implement a service using BPEL, but you could just as easily do so
>> using Java, C#, Ruby, or Erlang. Techology selection is a
>> project-specific decision that occurs very late in a BPM project.
>>
> I am sorry I disagree with you.
> This is a technology point of view. Not from the enterprise point of view.
> How the Java or other languages can support the human interaction, as
> for example, if we build a business process ?

You are kidding right?  How does Java, a technology which is behind a
huge amount of websites out there and which is the execution engine
for most process engines.

Human interaction is easy in Java.

> Please notice that these languages is low-level compared to business
> processes.

Partly true but also have you ever tried doing complex business rules
in BPEL/BPMN?  It really doesn't work.  Have you tried doing complex
layouts for user/human interaction?

ALL implementation technologies are low-level in areas where they
aren't appropriate.

>
> Therefore, we sometimes refer to them as ‘*programming-in-the-small’*.
>
> *SOA approach to development is sometimes called
> /programming-in-the-large.  /*
>
> Composition of services (using BPEL) has been designed for such a purpose.

Indeed it has, this doesn't mean that its the only technology or the
most important one.

Some solutions require composition, others require orchestration
others require co-ordination.

>
>> Key "technologies" that support BPM include Six Sigma and Lean
>> methodologies, swim lanes, process maps, ARIS, Visio, etc. These are
>>
>> the tools business people use to analyze existing processes and
>> explore/simulate new ways to accomplish their work and achieve their
>> desired business outcomes. Some aspects of their proceses can be
>> automated. Others can't. Some aspects of achieving business outcomes
>> are delivered via better insight -- not through processes. (in which
>> case adopting a purely process-centric perspective is detrimental)
> If you speak about flowcharts, it is ok.
> But business needs more than that, business want to reduce the IT gap time.
>> After analyzing their processes, business people submit requests to IT
>> to implement application software to automate certain aspects of the
>> process. IT people then use a variety of modeling notations to design
>> solutions, e.g., BPMN or UML. From there, they write/produce code.
>> Some people attempt to generate code from their models. I have yet to
>> find anyone who supports that code who still believes in the
>> model/code roundtripping myth.
>>
> I can tell that I reversed engineering Java code when I joined a project
> at its end stage on 2004, to understand the project and to finalize it
> and deliver it to their end user.
> It takes a few weeks and lot of efforts but without that it would take a
> months.
> I modified some of the model and forward engineer it to code again, and
> with little support from the developers, we achieved our goals.
> I do believe in model/code roundtripping myth and I think there are some
> believe on it too.

Its not a myth but it does require a huge amount of management
overhead and tends to become unstable in support unless the support
people are incredibly high level.  It also tends not to be
roundtripping but a unidirectional generation.

Steve

> It is not just a theory, but we have to open our minds up to new
> concepts, study them without precluding anything, then we can select the
> best fits us.
> I think I learned that from you Anne.
>
> All the best
> Ashraf Galal
>
>> Anne
>>
>>
>>
>> On Sunday, December 13, 2009, Steve Jones <[email protected]> wrote:
>>
>>> Lets plan planet fail....
>>>
>>> 2009/12/13 Ashraf Galal <[email protected]>:
>>>
>>>> The key technology of SOA is BPEL.
>>>>
>>> #FAIL
>>>
>>> Even if we say that SOA is a technology thing its really rather hard
>>> to say that a PROCESS language is THE key technology of SERVICE
>>> orientation.  Its like saying that procedures are the key technology
>>> of OO.
>>>
>>>
>>>> This language minimizes the semantic gap between the process model and
>>>> the actual execution code.
>>>>
>>> I might let you have this one, its not right (it can reduce it a bit
>>> in certain cases rather than being a blanket statement)
>>>
>>>
>>>> BPEL enables business processes to be executed directly.
>>>>
>>> #FAIL
>>>
>>> See "Christmas SOA" which explains why what you execute is rarely what
>>> the business process is, this is the difference between the perceived
>>> process and the executed process.  BPEL works at the executed level.
>>>
>>>
>>>> Process models, preferably developed in BPMN, can manually,
>>>> semi-automatically, or automatically be translated into BPEL.
>>>>
>>> Not a fail but....
>>>
>>> BPMN can also be translated into Java, C, assembler or many other
>>> languages.  Now its _sometimes_ easier to do it into BPEL but that
>>> doesn't mean
>>>
>>> Also "manually" translated means there are significant gaps.
>>>
>>>
>>>> With BPEL, various activities, called partner links, are performed by
>>>> services.
>>>>
>>> I really think we all know this stuff.  Are you Scott Nudds?
>>>
>>>
>>>
>>>> Therefore, an important aspect is the decomposition of the business
>>>> process and its mapping to the services.
>>>>
>>>> Services are the central artifacts of SOA architecture. We use services
>>>> to model automated business activities or human tasks.
>>>>
>>> #FAIL
>>>
>>> Nope, the CAPABILITIES model the activities or tasks, the SERVICES
>>> provide the mechanism for accessing those capabilities.
>>>
>>>
>>>> SOA enables much tighter integration between business processes and
>>>> software architecture. Many tools on the market today provide
>>>> bidirectional lifecycle support.
>>>>
>>>> This means that changes made to the model (BPMN) are automatically
>>>> propagated to implementation (BPEL), and vice versa.
>>>>
>>> #FAIL
>>>
>>> Ever worked on a project that used these things?  You export from BPMN
>>> then you have to tweak the BPEL and from that point onwards the
>>> roundtrip is almost always doomed.
>>>
>>>
>>>
>>>> If we do not use SOA and Services we will end up with a lot of problems
>>>> because BPMN is designed specifically for SOA.
>>>>
>>>> There is nothing perfect, but we have to set up our goals and work to
>>>> achieve them.
>>>>
>>>> Also we have to recognize that SOA changes the traditional development
>>>> life cycle. instead of analysis, design, implementation and testing, we
>>>> will have business process modeling using BPMN, composition, testing and
>>>> monitoring.
>>>> SOA changes our life and people do not accept change easily.
>>>>
>>> #FAIL
>>>
>>> What you are talking about is _not_ change its simple the old school
>>> of "technologies first" implementation which also assumes some form of
>>> mystical technology stack which has a vendors current hot ticket item
>>> at the top.  In your case you see it as BPEL/BPMN but others would
>>> look at CEP as being another option for that top stack.
>>>
>>> The key piece of SOA is thinking about the services FIRST and then
>>> thinking about which of the capabilities of those services are BEST
>>> delivered using processes and which are BEST delivered in other ways.
>>>
>>> In this way you look at the business first and don't assume the 
>>> technologies.
>>>
>>>
>>>
>>>> All the best
>>>>
>>>>
>>> Planet #FAIL population:
>>>
>>>
>>>> Ashraf Galal
>>>>
>>> Cheers
>>>
>>> Steve
>>>
>>>
>>>>
>>>>
>>>> cordau wrote:
>>>>
>>>>> Ashraf,
>>>>>
>>>>>
>>>>>> With these two technologies, plus some additional ones, SOA provides:
>>>>>>
>>>>>> - A language—BPEL—for direct execution of business processes
>>>>>>
>>>>>> - Round-trip mapping between the process models in BPMN, and their
>>>>>> executable representation in BPEL
>>>>>>
>>>>>> With this, SOA considerably reduces the semantic gap between the
>>>>>> business processes and application systems.
>>>>>>
>>>>>> BPMN enables us to draw the representation of a business process, which
>>>>>> is then mapped into the executable BPEL code, and executed directly on
>>>>>> the SOA platform.
>>>>>>
>>>>> You should know that not all BPMN processes are mappable to standard
>>>>> BPEL (let alone being able to roundtrip). See
>>>>> http://www.brsilver.com/wordpress/2009/11/19/bpmn-vs-bpel-are-we-still-debating-this/
>>>>> <http://www.brsilver.com/wordpress/2009/11/19/bpmn-vs-bpel-are-we-still-debating-this/>
>>>>> for details.
>>>>>
>>>>> Active Endpoints, a BPMN and BPEL tools vendor, had to introduce a
>>>>> proprietary extension to BPEL in order to support some BPMN processes.
>>>>> See
>>>>> http://www.activevos.com/indepth/f_technicalNotes/aa_ExtendingBPEL/ExtendingBPELWithLoopingTransitions.pdf.
>>>>> <http://www.activevos.com/indepth/f_technicalNotes/aa_ExtendingBPEL/ExtendingBPELWithLoopingTransitions.pdf.>
>>>>>
>>>>>
>>>>>
>>>>
>>>> ------------------------------------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>>
>>>>
>>> ------------------------------------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>>>
>>>
>>
>>
>> ------------------------------------
>>
>> Yahoo! Groups Links
>>
>>
>>
>>
>>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/service-orientated-architecture/join
    (Yahoo! ID required)

<*> To change settings via email:
    [email protected] 
    [email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/

Reply via email to