Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [bpel-dev] Rutime Extension Point Requirements 
Bruno,

This is a great start. Thanks for taking a lead on this.

Please see comments below.

Bruno Wassermann wrote:

Hi All,

I have put together a (very high-level) list of requirements on an extension
point for third-party runtime support. This stuff is rather basic and maybe
obvious, but hopefully can help with developing such an extension point.
Please let me know what you think, questions, etc.
Simple is good. Unless otherwise stated, I would stick to the k-i-s-s principle (keep it simple ...) 
- Deployment wizard
	+ First page has a list of current engines process can be deployed
to 	in current plug-in configuration. Installed and enabled runtime
plug-	ins (extensions) should be added to this list/be able to add
themselves.
	+ Second page of wizard has a configuration page that extensions can
provide to allow manipulation of such items as host address, 	deployment
directory, transfer mechanism, etc.
	+ Progress view to indicate deployment progress (but this may just
be 	a requirement on an extension itself rather than the extension
point).
So the overall depl wizard is something that a runtime extension can plug into, right ?. That is "we" manage the extensions, their registrations, and the runtime extensions provide a mechanism to define transport and packaging structure and perhaps a step or two in the wizard "deploy" framework.
This is more of an impl note, but assuming the engines are remote and deployment protocols could be really anything (ftp, http, rmi you name it) we could be nice if they could use proxy settings from eclipse and other shared settings that they could. 
- Preference Pages
	+ Extensions can add their own engine configuration page to the
editor's preference pages to store the same type of information as
indicated above across projects/permanently.

- Access to Process Represenation
	+ Extensions can get hold of a copy of the .bpel file for the
process 	which is to be deployed.	
	+ Extensions can obtain access to an instance of the editor's EMF
model representing the process.
	+ Extensions can get hold of all WSDL files involved in defining the
process.

OK sounds good.

- Validation
	+ The editor should not allow user to deploy (i.e. display warning
message instead of deployment wizard), if there are any outstanding
validation errors.
	+ The editor should save the process and validate it in case user
requested deployment whilst editor state dirty. Or could just prompt
	user to do so.
	+ Extensions have access to problems view to communicate any engine-
specific validation problems to user.
I wonder if we could think of relaxing it a little in that some runtimes may be able to run a partially correct BPEL process - which may be useful for the whole design/run/debug cycle. All I mean here is that we allow a on/off switch to govern this.
One additional thing I would add to this is whether perhaps the deployment framework could be masqueraded behind an eclipse builder. It seems to me that you could add a builder to the project which would do the same thing as a deploy but with one keystroke. May be very useful during development time.
I wander if we ought to consider in parallel the reverse path that might be taken. That is, process already present in a runtime, gets to be imported into a project for example. This would fall under perhaps an import wizard category, but because it is tied to runtime it may be worth considering it at the same time. 
That's the first set of requirements I can think of. It would also be nice
to figure out how runtime extensions could enable a form of real-time
in-process map monitoring, but maybe that's something to think about at a
later stage.

Regards,

-- Bruno




______________________________________________
Bruno Wassermann Research Fellow University College London Tel: +44 (0)20 7679 0369 (Direct Dial) 
Dept. of Computer Science      Fax: +44 (0)20 7387 1397
Gower Street London WC1E 6BT http://www.cs.ucl.ac.uk/staff/B.Wassermann United Kingdom ______________________________________________ 
_______________________________________________
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