Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Fwd: Re: [bpel-dev] Minutes of call regarding BPEL validation]

Thomas,

I agree that we a have few moving targets here.

In summary:

1) User selects no runtime upfront to author. User adds an extension activity.  Selects runtime. Then problem (user has to re-author).
2) User selects runtime upfront. Only those runtime's activities are shown and available. Then no problem as user develops and deploys.

While I agree that (1) may be painful, however (2) is too restrictive. I think we ought to in the development environment allow as incomplete a process as we can (same problem is in validation, right, relaxed XSD schema ?) while at the same time guiding the user to fix the errors. That's primarily the reason why I think we need incremental validation because that allows you to drop activities and then correct them as you go along. Errors are not a big pile of goo that hits you in the end. In the same way, the user experience in (1) could be adjusted as follows.

If no target runtime has been picked, then we allow everything, however, we warn the user every-time they use an activity that is an extension activity with a message: "This is an extension activity. Your runtime may not support it. Do you still want to use it ?" with a check box next to it that says "Don't ask this question again" once the user has been conditioned to understand this.

Once a runtime has been picked, then we have context to provide more validation on these choices. We don't have to necessarily hide the activities on the palette, but once again we could guide the user by prompting on drop "This is an extension activity. The selected runtime(s) does not support it. Do you still want to use it ?" with a check box next to it that says "Don't ask me this question again.", once again to condition the user.

>From a development perspective, flagging an activity that is not supported by a runtime to me is equivalent to say when you use  List<Date> myList and then you switch to JDK 1.4. The validator ought to catch it.

Read on.

Thomas Schulze wrote:
Hi Michal,

regarding
"Would it make sense to associate a 1-N runtime descriptor id with every
activity on the palette for example ? If a targeted runtime is picked, the
process can be analyzed quickly to show which activities will not even
"run" on that runtime and be reported as potential problems. And as Bruno
points out, the palette items can be hidden if a process is "married" to
the runtime."

Hiding the palette items would be possible in both cases, when selecting
the target runtime while the process is created or when a process is
"married" to a specific runtime after it have been authored. I think the
main differences between these two approaches are:
- the additional analysis needed to flag not supported activities after a
runtime is picked (more work for us)
- the additionally needed re-authoring of the process (potentially more
work for the user)

Let's think about a process containing a mustUnderstand="yes" extension.
The extension provides the ability to author a new structured activity. The
authored process is not married with a runtime yet and the user makes use
of that extension activity. Now, if the user picks a runtime which does not
support this mustUnderstand extension, we would need to flag all
occurrences of that extension in the process, including the extension
activity, because the BPEL spec specifies (see chapter 12.7): "If the
processor does not support one or more of the extensions with
mustUnderstand="yes", then the process MUST be rejected.". So the user can
either chose another runtime which supports that extension, or he must
re-author the process.

When thinking about a process containing two or more mustUnderstand
extensions, which together are not supported by any runtime, the user must
re-author the process in all cases. My opinion is that this is not very
usable.

When thinking about the other approach, selecting one or more target
runtimes when the process is created, we and the user wouldn't have all
these problems. The editor is allowed to provide only extensions to be
included in the process which are supported by all selected target
runtimes. The user knows already when starting authoring the process which
extension activities he can use in the process. Re-authoring wouldn't be
necessary in all cases. If the extension plug-in performs all validation
checks in the designer which are performed while deployment on the server,
the process will be deployable in all cases on the server when it have been
successfully validated in the editor. I think that's what a user would like
to see.



regarding
"There are some hidden snakes here. Runtimes may have pluggable activity
models that allow a vertical set of activities to plug in into different
runtimes. But I think it would be prudent to at least think about it."

This is an interesting point. But maybe it can be resolved easily. Each
plug-in providing a new activity type for one or more runtimes would
require an plug-in for the designer to make the activity available at
authoring time. The author of the plug-in normally would design the plug-in
for a known set of runtimes, so he would need to let us know which runtimes
that are. If this runtime is available for the designer (plug-ins of that
runtime installed) we could generate a new entry for the possible "new"
runtime, saying for example "Runtime A, with additional extension E". Of
course the list would contain another entry saying only "Runtime A". So at
the end we would have all possible combinations in the list of the target
runtimes and the user can author processes only for "Runtime A" (when
selecting both entries or only the entry saying "Runtime A" as target
runtime) or processes for "Runtime A, with additional extension E" (only
when selecting exactly this entry).
  
Agreed. However, the probability that this will happen I think is pretty low :-)
Best regards/Mit freundlichen Grüßen,

       Thomas Schulze



                                                                           
             Michal                                                        
             Chmielewski                                                   
             <michal.chmielews                                          To 
             ki@xxxxxxxxxx>            "BPEL Designer project developer    
             Sent by:                  discussions."                       
             bpel-dev-bounces@         <bpel-dev@xxxxxxxxxxx>              
             eclipse.org                                                cc 
                                                                           
                                                                   Subject 
             03.04.2006 19:44          [Fwd: Re: [bpel-dev] Minutes of     
                                       call regarding BPEL validation]     
                                                                           
             Please respond to                                             
              "BPEL Designer                                               
             project developer                                             
               discussions."                                               
                                                                           
                                                                           




This bounced on fri due to eclipse.org meltdown

--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321

"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."


----- Message from Michal Chmielewski <michal.chmielewski@xxxxxxxxxx> on
Fri, 31 Mar 2006 11:01:10 -0800 -----
                                                                           
   To: "B.Wassermann" <B.Wassermann@xxxxxxxxxxxx>, "BPEL Designer project  
       developer discussions." <bpel-dev@xxxxxxxxxxx>                      
                                                                           
 Subje Re: [bpel-dev] Minutes of call regarding BPEL validation            
   ct:                                                                     
                                                                           

Bruno Wassermann wrote:
      Hi guys,

      Just a few thoughts on targeting a particular runtime at process
      modeling time.

      Is it okay to expect a user to specify the target runtime at process
      modeling time (i.e. before thinking about deployment) or would this
      introduce some usability issue?


That's an interesting point you make.

I think it is quite reasonable for the user to do that, as I presume, most
users will be, for a lack of a better word monogamous :-)

A runtime provider, would provide the runtime extensions and most likely
some element extensions to be authored into the process. One could further
assume that such extension might be unlike the extensions of any other
runtime, simply because they are either verticals or because the likelihood
of 2 people coming up with the same design are pretty close to 0.

Would it make sense to associate a 1-N runtime descriptor id with every
activity on the palette for example ? If a targeted runtime is picked, the
process can be analyzed quickly to show which activities will not even
"run" on that runtime and be reported as potential problems. And as Bruno
points out, the palette items can be hidden if a process is "married" to
the runtime.

This one seems particularly intriguing a point simply because we need to
run-time agnostic and help the user as much as we can once he does pick or
deploy to a runtime.

There are some hidden snakes here. Runtimes may have pluggable activity
models that allow a vertical set of activities to plug in into different
runtimes. But I think it would be prudent to at least think about it.

      Should a user be free to choose the vocabulary/constructs that best
      suits her modeling needs and then think about which runtime to employ
      or is this unrealistic (i.e. should we expect a user to only have one
      particular runtime available and should therefore provide support,
      during modeling, for valid processes for this particular runtime).
      However, if we don’t ask for a target runtime, we wouldn’t know which
      tools to offer in palette and which ones to hide. Then again, we
      mentioned in the runtime extension thread that there will be
      runtime-specific validation and feedback to the user at deployment
      time.

      It would be really cool to have some technology where we offer ‘write
      once, run anywhere’ without users having to reason about portability
      issues.

      Regards,

      -- Bruno


--
Michal Chmielewski, CMST, Oracle Corp,
W:650-506-5952 / M:408-209-9321

"Manuals ?! What manuals ? Son, it's Unix, you just gotta know."
_______________________________________________
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." 

Back to the top