The ideas of services tasks is that you can provide your own implementation. Web Service comes in different flavors and usually required domain specific classes to work an be compiled. For that reason IMHO, it's almost impossible to have a generic web service work item handler that deals with "web services" in the generic sense.
When I used BPEL I think I didnt need any classes, just wsdl, xsd of input and output data, an end point and it worked.
Ok so every Domain-specific tasks are considered serviceTasks and a handler is resolved by "Name" property. And if I wont to use a specific web service I must create custom WorkItemHandler and register it in WorkItemManager. And in my WorkItemHandler I use whatever login I need to use that WebService.
That's right. BPEL was designed to work with web services only. That's why you can use it natively there. in jBPM5 because we support any type of interaction you need to create a new WorkItemHandler (or reuse one) for each type of interaction. You can try creating one abstract enough to be used in different scenarios via some parametrization or configuration.
I'm not sure to understand completly your last paragraph (it was a question?). But in a brief yes, you create a WorkItemHandler that it's associated using a String to a specific runtime. That means that you can have different runtimes that uses different handlers, this is usually very interesting to deal with a process execution in different environment, like for example: developement, testing & production without changing anything inside the process.