RPC/Encoded support

[forkbomb]

I understand that JBossWS is now installed as the default JAX-RPC stack in JBoss 4.0.4. I have seen several postings that RPC/Encoded web services are not supported in JBossWS. According to the JAX-RPC 1.1 spec:

The JAX-RPC specification requires support for both encoded and literal representations of a SOAP message representing an RPC call or response.

How can you replace the default JAX-RPC stack with one that removes functionality required by the specification? We both publish and consume RPC/Encoded web services with 3rd parties, and are unable to upgrade to JBoss 4.0.4, and there is basically no migration path. Our only option is to downgrade to ws4ee. I honestly don't care about the Basic Profile, which is not a J2EE spec; if you want to claim to be a J2EE application server, you need to support the J2EE specification. Are there any plans to fully support the JAX-RPC spec in JBossWS?

[dust_puppy]

i have a similar question
i need to use a 3 party rpc/encoded webservice, so this cant be done in jbossws ?
what is your suggested solution to this problem ?

/Dust

[jason.greene]

forkbomb,

JAX-RPC 1.1 predates WS-I Basic Profile 1.0/1.1 which outlaws rpc/encoding.

J2EE 1.4 requires WS-I BP 1.0 compliance which effectively removes the JAX-RPC 1.1 requirement.

That said, there is actually support for it, although it is highly discouraged.

There is no tools support, so you will have to use sun's wscompile to generate proper descriptors.

-Jason

[thomas.diesler]

The reason why the BasicProfile-1.0 prohibts rpc/encoded is because there are inherent interop issues with with encoded (chapter 5 of the SOAP specification)

Even though some older stacks still support encoded, you will probably find that they have unfixable interop issues with non-trivial use cases.

[forkbomb]

I understand that the Basic Profile outlaws RPC/Encoded, and why. None of our new web services will be RPC/Encoded. The fact is that we have production clients that use RPC/Encoded. Unless the Basic Profile can rewrite their code, I'm pretty much stuck. Jason, just because J2EE 1.4 requires you to support the Basic Profile doesn't mean that it "effectively removes the JAX-RPC 1.1 requirement." You have to support both. That said, if I can deploy RPC/Encoded web services on JBossWS, that's great. I don't mind if I have to hand write the descriptors. I basically need a way to deploy the RPC/Encoded and literal versions at the same time so that clients have a migration path.

[maeste]

We also had the same problem, with very old web services used by a lot of our customers.
This time we are happy to have very very old implementation based on jboss-net because it can be deployed without conflict with jbossws.
We didn't upgrade to ws4ee some months ago because we are too busy, and we couldn't get time for a (complex) migration. Now with jboss-net and jbossws deployed on the same environment we can move softly to the new technology giving a path to our customer to migrate.
Anyway, jboss should consider that break compatibility could be a serious problem especially for technology used in b2b like webservice.

[burrsutter]

This may sound like an odd question but I?m curious to know how many Web Services do you/your corporation provide? The number of different WSDLs might be the easiest way to measure it.

I?ve been asking a number of enterprise architects for large corporations to get a feel for the overall expenditure of effort in the SOA space.

Thanks,
Burr
[e-mail]

[maeste]

I'm not sure if it's the right 3ad, but I'm happy to answer to the question about number of webservice, to give jboss developer an idea of the reasons of requests in this 3ad.
We have 37 different wsdl with a total of 191 methods in our production environment (with a lot of soap object of course) used mainly for b2b and integration in eterogenous system (java of course with .net, php mainly).
As already said we begin to devolp webservice with jboss-net in early 2004 and we start our b2b comunication in end of march of that year.
in this years we does a lot of businness aroud this protocol to interoperate with our customer and partner, and a lot of work to support them in implementation. But the hardest durty job had been to mantain the same wsdl and the same soap message to make transparent to our client we was updating jboss version and web service environment. We had to make some little coding on library to make that (mainly because we implemented ws using xdoclet) and we had to renounce to adopt ws4ee because we can't (easly) mantain compatibility.
Now we decide to make the migration to jbossws because jboss-net it's too old and too limited. But as already said and as you can understand it's very very important to give to our partners 6 mounth (at least) to modify their client and the opportunity to deploy together jboss-net and and jbossWS is the best way (not the only one because we use address virtualization, but for sure the most confortable for us and our clients)