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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

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


Subject: Re: [wsbpel] Gotos Considered Harmful?



I absolutely agree with the existence of (at least) two different roles in
specifying business processes: A business analyst and a "technical
modeller".  Typically what happens is that the technical modeller adds the
technical details to the business analyst's results that the analyst
doesn't care about (complex data structures, transforming textual
conditions into Boolean conditions, adding assignments etc etc).

But, please, let me emphasize again that the technical modeller should not
(!) redraw/reshape/... the business analyst's process model, but "simply"
extend it.  Reshaping the model will mostly result in semantic clashes - on
other words, if the business analyst and the technical modeller do not
share the same understanding about the behavior of the model ("operational
semantics") they do very likely mis-communicate, or the semantics of "the"
representation of the business process will change. This is unacceptable
for various reasons.

Thus, the language that the business analyst uses has to be a "subset" of
the language that the technical modeller uses.  The usage of quotes need to
be refined:  There are elements in the analyst's language that are to be
transformed by the technical modeller (textual conditions into Boolean
conditions, for example); and the analyst's language does include elements
that are not of interest to the technical modeller at all (e.g. artifacts
needed for simulation like cost information etc.).

I am fully aware that there are zillions of metamodels and corresponding
tools around that do target business analysts, and that these metamodels
are only partially (if at all) complying with the ideal sketched before!
The relevant artifacts captured by these BPR tools will have to be mapped
onto BPEL resulting in a "BPEL skelleton", and this case the technical
modeller will have to reshape the skelleton into valid BPEL. This is done
today by mapping from BPR tool representation to workflow/process-engine
vendor specific "technical formats"; and it is a real pain for the
customers if the tools metamodel and the workflow/process-engine metamodel
are not close. To cure this pain, a couple of tools already provide "modes"
that restrict the modeling capabilities provided by the original tool's
metamodel to the ones of the target workflow-system or process engine
avoiding the need for "redraw", "reshape" etc..

Regards,
Frank

-------------------
Prof. Dr. Frank Leymann, Distinguished Engineer
IBM Software Group
Member, IBM Academy of Technology

Phone 1:  +49-7031-16 39 98
Phone 2:  +49-7056-96 50 67
Mobile:  +49-172-731 5858
-----------------





To:    "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>
cc:    wsbpel@lists.oasis-open.org
Subject:    Re: [wsbpel] Gotos Considered Harmful?


Bernd,

    I think the distinction between "business analyst" and "technical
modeller" that you mentioned is an important one. They are separate
audiences, yet there is some need for them to collaborate, including
sharing artifacts. The usual model of this collaboration is that the
analyst first produces a high-level description of a process, and that the
technical modeller helps detail the process until it represents something
that is executable. It has been suggested here (by Prof. Leymann, if memory
serves) that customers should redraw unstructured process graphs as
structured ones. It seems logical that this transformation would be a task
for the technical modeller.

    It sounds like our audience (for BPEL) is the technical modeller,
rather than the business analyst. Does that make sense to everyone?

-Ron

Eckenfels. Bernd wrote:
      Hello Ron,

      in my experience a BP modeller does not wants to draw a business
      process with simple cyclic graphs.

      Most analysts (including customers who actually model their process
      specs themself) are well aware of the issues which may result in
      those kind of graphs (especially monitoring, receconditions,
      indeterministics, ...).

      Additionally, I think the use of a loop container (while, ...) is
      pretty intuitive, it even allows nice graphical represenations:
      "everything inside this square can be repeated until...".

      so first of all: I think support of loops by (only) block structures
      is not an issue for an modeller, and I agree with you, even if it is
      a valid requirement, it is totally against the primary BPEL goals.
      Besides, with current BPELs link semantic, i can not think of any
      alternative to allow cyclic process execution, anyway.

      Greetings
      Bernd

      PS: an unrelated side note: UMM has something called the "technical
      modeller" role, which is different from the busines domain expert and
      different from the busines process analyst. I think this distinction
      is important. BPM tools should only be used by persons who are able
      to fit the "technical designer" role. See 2.1.3 in UMM-N090 R10:
      http://webster.disa.org/cefact-groups/tmg/doc_bpwg.html



      -----Original Message-----
      From: Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
      Sent: Wednesday, July 09, 2003 6:55 PM
      To: Jim Webber
      Cc: wsbpel@lists.oasis-open.org
      Subject: Re: [wsbpel] Gotos Considered Harmful?


          I afraid we may be reasoning by anology here. Cycles in a process

      graph may "smell" like gotos to those of  us steeped in the lore of
       software engineering, but to a business analyst they are a natural,
      necessary construct. They describe how real business processes work.

          Trying to impose "fashionable" structured software concepts on
      another domain sounds like a  questionable exercise, if the objective
      is
      to model the business process at a high level. If this is not the
      intent, then let us by all means attempt to structure BPEL processes
      according to good software engineering practices, including being
      wary
      of unstructured constructs.

      -Ron

      P.S. Does anybody remember computed GOTOs in Fortran IV? If gotos are

      considered to be harmful, then the computed goto must be
      life-threatening!

      Jim Webber wrote:


            After hearing the arguments against Gotos on today's telcon, I
            have to
            (unfashionably) suggest that they're not so bad. See:
            http://www.ppig.org/papers/12th-marshall.pdf for a short
            argument in favour
            of not ignoring Gotos.

            Note it isn't BPEL-specific, but makes the general point that
            there are some
            places where a Goto is the right thing to use (though those
            situations are
            few and far between).

            Jim


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

            To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
            For additional commands, e-mail:
            wsbpel-help@lists.oasis-open.org







      ---------------------------------------------------------------------
      To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
      For additional commands, e-mail: wsbpel-help@lists.oasis-open.org


      ---------------------------------------------------------------------
      To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
      For additional commands, e-mail: wsbpel-help@lists.oasis-open.org









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