True Portability of JAX-RPC

[Dushy Inguva]

Hi all,
Questions about Portability of JAX-RPC based implementation
1. Based on Monson-Haefel: Section 15.2.5, Page-444 (Most JAX-RPC compilers will generate the endpoint interface this way, provided that XML schema of purchaseOrder document uses only JAX-RPC standard XML schema types.) Does that mean some compilers are allowed to generate the endpoint interface in a different way? Doesn't that hamper my portability?
2. If i already have existing code using JAX-RPC runtime provided by Vendor A, If i plan to use Vendor B's runtime, do i have to generate all the endpoint interfaces again? Or can i give it the WSDL and the endpoint and ask it to "understand and perform the mapping". Doesn't this affect portability?
Thanks
Dushy

[Nicholas Cheung]

1. Based on Monson-Haefel: Section 15.2.5, Page-444 (Most JAX-RPC compilers will generate the endpoint interface this way, provided that XML schema of purchaseOrder document uses only JAX-RPC standard XML schema types.) Does that mean some compilers are allowed to generate the endpoint interface in a different way? Doesn't that hamper my portability?

For the interfaces, I think they will generate the same interface, otherwise, this not only affects the portability, but also the interoperability.

2. If i already have existing code using JAX-RPC runtime provided by Vendor A, If i plan to use Vendor B's runtime, do i have to generate all the endpoint interfaces again? Or can i give it the WSDL and the endpoint and ask it to "understand and perform the mapping". Doesn't this affect portability?

I think we need to re-generate the codes that are specific to a certain vendor. Come think about the case of EJB, we have the same Local/Remote interfaces, as well as the bean. However, if we port it from IBM WAS to BEA WL, we need to re-generate the stub.
Nick