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,

Another thing that popped to my head is that we perhaps ought to allow for some error reporting from the runtime on deployment. I don't mean here a 0/1 type of decision. We probably ought to consider that different runtimes may have (and probably do have) some error reporting/compliance checking mechanism as well.

Consider a simple case where an extension is present in the process that is not impl by the runtime. The process will check OK on the tool, but fail a check on the runtime. Something more then 0/1 answer from deployment ought to be present.

I am wandering whether we ought to consider doing a validate on runtime extension, a compile on runtime extension, and finally a deploy on runtime extension. The intention of deploy would be a successful compile + install of the process. A validate step may validate this against the runtime concept of BPEL for example. We could combine the validate/compile extensions but having something more to deploy would be nice.

-michal

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.

- 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).

- 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.

- 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.

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