Those are not properly speaking "attribute". An SOAPElement may live in certain namespace or in a null namespace... That is what happens for GetParameter, request, MonCode etc...
Note also that the re-use of bodyElement, paramsElement may cause confusion at times... I can't say it is absolutely discouraged, but certainly not encouraged, as long as you can keep them on track - it is up to you.
The package javax.xml.soap provides extensions to org.w3c.dom to help control of many aspects of the message which are not considered generic or universally significant to an xml compliant to the recommendation. They help coders to simplify certain non-generic manipulation much easier than otherwise available directly to xml processing in general. For instance, the choice of prefix should not be a generic thing one may be concerned of, say a choice of default SOAP-ENV (for soap 1.1) or env (for soap 1.2) should be 100% comfortable for anyone than a choice of soap - but it does not mean the library necessarily intends to dictate and force these choices upon you...
The things you're asked can be done relatively easily with javax.xml.soap packages.
- how to addition this information in begin
<?xml version="1.0" encoding="UTF-8" ?>
The SOAPMessage class provisions two fields that you can set at your discretion. One of them is WRITE_XML_DECLARATION, defaulted to "false". You can add this line after establishing SOAPMessage object.
- deleted "-ENV"
You actually mean in general to change the default choice of "SOAP-ENV" to "SOAP", or, in fact, could mean to change to any other prefix for the matter.
You can do it by a method setPrefix() inherited from org.w3c.dom interface but you have to apply the method inherited from SOAPElement removeNamespaceDeclaration() to eliminate the original namespace declaration left over and rendered useless, hence a cleanup is probably more elegant rather than straightly necessary. You have to do on every wrapping element proper to SOAPMessage: Envelope, Header and Body. Like this.
and you're done. There are other ways to do this as well at different stages of the process of invocation but those may be way too complicated conceptually and code-wise to entangle the issue directly.
...and deleted "<SOAP-ENV:Header/>"
Here you sometimes have to be careful on dealing with Header. Within the package when an instance of SOAPMessage is created, an empty Header element is automatically created. This may not be the case for other libraries... Having said, soapHeader is never null in this approach and you can spare the control of it. To eliminate the optional Header, you simply do this.
That's it as simple as that and it is also documented in the documentation.
I can only comment on the code shown: I am not so sure, and I don't think so. The SOAPAction would not and could not be set that way. It is not an ordinary MimeHeader. It can be set via the Dispatch object. Setting MimeHeader(s) via SOAPMessage won't help in that regard. So if it (or anything) works, it works probably because of some other code not shown.
..., BUT first 2 variant returned error
The error is what sends back from the server. They are by themselves not capable of that kind of "error". If eventually what is dispatched without the correct SOAPAction, and that in consequence the server does not know what operation to dispatch to, the server could send you back fault code as that. But all these are caused by the dispatching and invoking code, unrelated to the construction of the SOAPMessage as request, I think, as I don't see the whole picture.