Kevin McGuire wrote:
Hi guys,
Good discussion thread. We are
definitely open to improvements here.
Just recently, James Moody and I
were
discussing the very same issue about the partner for an
invoke/receive/reply
not being easely understandable from the diagram alone. I notice
that whenever I try to explain a BPEL process to someone by looking at
the editor, I have to rely on either my memory or hints in the activity
names.
In a previous incarnation of the editor (in WSAD-IE 5.1) we had an
added
layer with partner and var lists down the side. Selecting an invoke
would draw a line to the corresponding partner, selecting a partner
would
show all activities which use it, etc. That turned out to be, well
to be honest, terrible. The diagram quickly became incomprehensible
with these lines all over the place and it was difficult to implement.
So we just backed out of it completely in the new editor.
The concept of connecting activities on the process map to pl elsewhere
on the screen (in either swim lanes on the sides, or some partner link
place holders on the side etc) is just too much information. We had
played with these concepts too and I think it really does not work,
especially once you have big process maps. The end result is that you
have top-to-bottom flow and right-to-left invoke/reply/receive
"connections". The map starts to look like a mutating virus.
Big process maps are a challenge in themselves as we all know. But
that's a general problem with any diagramming tools. As long as you can
see "most of" of the process map things are OK. As it gets bigger, you
begin to feel as if though you are looking at the Mona Lisa through a
key hole. Add the partner link invocation diagramming on top of that
and things get much more confusing.
Adding more information on activities in the process map can lead to a
Christmas tree effect, especially if you adorn them with icons. So that
approach is also a little screwy.
Beyond the things Kevin had mentioned below, I would add the following:
1) Some things that we tried with mixed results are in-map dialogs or
alternate views of an activity if you say double click on it. So an
Assign, might just list the copy rules, one per line (just a simple
list). An Invoke might list the partner links. Not necessarily a full
inspector view, but more information that is useful, hidden under a
double click.
2) Breaking up complexity of the diagram. There are natural places
where things can be broken up in the BPEL diagram. Functionally, a
scope might be such a thing (which leads to macros). Exceptions might
be another. The idea is that these nodes are not shown inline but
rather on a separate "layer". Perhaps this is something similar as the
tabbed approach Kevin mentioned below. Conceptually though, you are
really in the single editor window and are just jumping in and out of
these view fragments. You obviously allow the user the dictate where to
break the diagram (which scopes are inlined for example, and which ones
are not).
At the end of the day, I also feel that processes ought to become a
first class citizen. Breaking up complexity be refactoring to a process
for example, then later having that "process" on a a palette for a
quick composition might be a path to making this problem less painful.
-michal
Still, we recognize the
need for this
information to be part of the diagram.
Some random thoughts:
- A simple solution I suggested was
that we print the partner name in the activity itself.
- As for the interface, perhaps the
partner list is the place to do that, rather than showing that at the
activity
level.
- Bruno, we discussed at some point
a long time ago a tabbed view approach. We've generally stayed away
from tabbed views in WebSphere Integration Developer (from whence this
code came), so that's the history, but its worth considering anew.
- A related issue is one of
publishing.
The more you can make the diagram self-explanatory, the easier it
is to publish since just printing the diagram is almost enough.
- However, Bruno as you mentioned, a
big concern whenever we play with the information shown in the
activities
is that as the diagram becomes larger it quickly becomes unreadable,
especially
as you add more and more scopes. You end up only being able to
realistically
see a small part.
- We could consider mechanisms for
able
to optionally show additional information in the activities (e.g. a
toggle
which shows interfaces), but generally speaking such mechanisms are
tricky
to pull off that they don't become a burden for the user to manage.
What I'd suggest we do is come up
with
an initial list of the most important information that one needs to be
"evident" in order to understand a BPEL diagram. Is it
just partner? Is it partner and interface? Var access?
Cheers,
Kevin McGuire
WID & WSADIE UI Development Lead
Hi,
I would just like to add
my
two cents to Philipp’s suggestion. Adding information about partners,
namespaces, etc. to the process map is a great idea until you get users
who develop really large workflows with hundreds of activities and
dozens
of partners. To cater for such cases, you would need to figure out how
to represent this information without leading to a (further) explosion
of the graphical representation and making the information easily
accessible
at the same time; this could be a tough one.
An alternative might be
to
have a tabbed editor providing an overview page that contains
representations
about partners, global variables and namespaces. This page can then
also
allow you to explore each of these elements in more detail. An activity
figure or its properties view should then provide you a link to these
elements
(i.e. partner, variables) for convenience. That’s just one possible
idea
though and I am sure there are many other ways.
Regards,
-- Bruno
From:
bpel-dev-bounces@xxxxxxxxxxx
[mailto:bpel-dev-bounces@xxxxxxxxxxx] On Behalf Of Philipp
Tiedt1
Sent: 10 March 2006 11:47
To: bpel-dev@xxxxxxxxxxx
Subject: [bpel-dev] Show more details
Hi,
One of the concerns I heard about the BPEL designer is that there is
not
enough information displayed in the canvas of the editor.
http://philipptiedt.blogspot.com/2006/02/quick-view-on-bpel-designer.html#links
Looking at other visual editors (e.g. Class diagramm editor) you will
find
more details displayed in the figures which gives you a more detailed
insight.
I was just wondering if this could be of any value for the BPEL editor
as well.
I could imagine having the partner of an invoke activity displayed in
the
figure as well as displaying the interface for recieve and reply.
Propbably
this would be customizable, so the user could decide which details they
actually want to see and which should be hidden. Any more ideas?
Is anything planed like that?
Regards,
-philipp
Mit freundlichen Grüßen / Best regards
- Philipp Tiedt
_____________________________________
Software Engineer II4BPEL
Information Management
IBM Deutschland Entwicklung GmbH
Schoenaicher Str. 220, 71032 Boeblingen
Phone: +49 (0) 7031-16-2786
Mail: philipp_tiedt@xxxxxxxxxx
Blog: http://philipptiedt.blogspot.com
"Throughout the centuries there were men who took first steps down
new roads armed with nothing but their own vision"
-- Ayn Rand
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
_______________________________________________
bpel-dev mailing list
bpel-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/bpel-dev
--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321
"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
|
