Axis user community, Last year I implemented a service oriented architecture on one of Paymentech's core, internal, systems (an HP NonStop, i.e. Tandem, system). It worked extremely well. The system has not had any defects, and has not been cycled since its initial production rollout last September. Part of the reason for the success was that we consciously utilized a leading-edge, but not bleeding-edge, strategy for the technology. I used Axis 1.1, with simple data types (Strings and ints) and rpc/encoded style. Using that approach, we were able to achieve interoperability between .NET, Oracle and Java clients running against Axis on a Tandem system.
Now we are ready to move to the next step. We have more projects in the queue, and we wish to do more sophisticated things. All the interoperability folks say "use doc/literal" style, and "avoid rpc/encoded". But, having followed the various axis mailing lists, I'm not yet convinced this is the time to make the transition. Summarizing, here is my question to the community: Should we stick with Axis 1.1 and rpc/encoded style for a while longer, or should we make the jump to Axis 1.2 and doc/literal? Or should we make the jump to Axis 1.2 but stick with rpc/encoded style? Thanks in advance for your opinions, Sam Ayers Learn more about Paymentech's payment processing services at www.paymentech.com THIS MESSAGE IS CONFIDENTIAL. This e-mail message and any attachments are proprietary and confidential information intended only for the use of the recipient(s) named above. If you are not the intended recipient, you may not print, distribute, or copy this message or any attachments. If you have received this communication in error, please notify the sender by return e-mail and delete this message and any attachments from your computer. ..
