hmmm... just a link was not what I intended.
jBPM can call anything. pojo's, but if you write a good actionhandler, it can call webservices, legacy systems etc..etc...etc...
If you read the blog, you'll see that they, jpdl and bpel, serve a different purpose. In the company I work for, we call the processes we develop with jPBM (jpdl) business processes and the orchestration we do (will do in the near future) microflows. That makes it most clear to the business that they should not be interested in how we connect services (they seem to be allergic to things called micro or technical ;-) )
We never had a problem everything was not in one picture. The abstraction level of jBPM jpdl is good at the business process level (I only wish I can show the actions and timers graphically as well, but configurable)
Regarding the 'wrapping'. that is exactely what oracle does when they use the WSIF to get some performance in their bpel system, and what you could do in jpdl byt writing a kind of generic action handler.
Keep in mind that BPEL exposes service compositions as new services. When your jPDL process invokes a service, it might as well be invoking a BPEL process. The BPEL engine is already "wrapped" in service interfaces.
Calling back the jPDL process from the BPEL process does require the former to be wrapped in a service. As Ronald says, not being able to put it all in the same picture should not pose a problem. You *want* things to be modular and have different levels of abstraction.
jPDL is a workflow/BPM language at the programming level. You use it to implement a business function. BPEL is a composition language at the service level. You use it to wire together business functions exposed as services.