Will SOAP Web Services work for me?

[hernan silberman]

I work on Java Client/Server system that went online in late 1995 (go Java 1.0!). At one extreme end of the architecture is an Oracle database which speaks to a tier of Java servers which in turn handle requests from a collection of one hundred or so Java clients written as stand-alone applications. The system's gone through various revolutions over the years, but the core architecture would still make sense to the original engineers.
The computing environment we work in is populated mostly by PERL, C/C++ and Python programmers on Linux, Irix and Windows hosts. The information managed by our application is very interesting and useful to people in these environments and since the communication that occurs between our clients and servers is entirely proprietary, we're not able to grant them programmatic access to this information as they have been requesting.
After a few weeks of research, it seems clear to me that exposing some of our useful server APIs using a SOAP-compliant web service would be the knee-jerk solution to this problem but I'm struggling with a couple of grey areas in my understanding:
Assuming we go through the trouble of acquiring an application server and funneling our server logic into J2EE land, including the creation of SOAP services for the important APIs we would like our PERL, C/C++, and Python developers to have access to, how much of our effort will be spent on the client side for each of those computing environments? I know Perl::Lite exists, but how natural will it be to manipulate our data objects in PERL? How cumbersome or nice is the representation of these objects likely to be in PERL, Python, C or C++? How likely is it that we'll have to write client code to do all of the SOAP client work and build a layer to protect our PERL programmers from the SOAP client work and any necessary data manipulation? Of course, we'd love to not build Python, PERL, C, and C++ code but I'd love to know how realistic it is to think our developers will be able to use what PERL::Lite, SOAPy, and other SOAP client toolkits hand them. This seems like the promise of standards like SOAP and good SOAP client toolkits.
Also, I wonder what the right approach is when writing a web service assuming it will be accessed using SOAP by users on various operating systems using various programming languages. Even though I'm a Java programmer, it doesn't appear that I will be able to "abstract away" the details of SOAP behind a nice Java API. In other words, I won't start by building Java classes, I'll start by building XML Schema data models for the data objects I will be using in my web service. Those XML documents will be the "lingua franca" of my application and will have to exist independent of the Java classes I write.
If it helps understand the situation, our application is used within our company only, we have lunch daily with the potential users of these services.
Any insights would be most appreciated. Thanks for reading all of this!
Hernan Silberman

[Ramesh Nagappan]

Originally posted by hernan silberman:
I work on Java Client/Server system that went online in late 1995 (go Java 1.0!). At one extreme end of the architecture is an Oracle database which speaks to a tier of Java servers which in turn handle requests from a collection of one hundred or so Java clients written as stand-alone applications. The system's gone through various revolutions over the years, but the core architecture would still make sense to the original engineers.
The computing environment we work in is populated mostly by PERL, C/C++ and Python programmers on Linux, Irix and Windows hosts. The information managed by our application is very interesting and useful to people in these environments and since the communication that occurs between our clients and servers is entirely proprietary, we're not able to grant them programmatic access to this information as they have been requesting.
After a few weeks of research, it seems clear to me that exposing some of our useful server APIs using a SOAP-compliant web service would be the knee-jerk solution to this problem but I'm struggling with a couple of grey areas in my understanding:
Assuming we go through the trouble of acquiring an application server and funneling our server logic into J2EE land, including the creation of SOAP services for the important APIs we would like our PERL, C/C++, and Python developers to have access to, how much of our effort will be spent on the client side for each of those computing environments? I know Perl::Lite exists, but how natural will it be to manipulate our data objects in PERL? How cumbersome or nice is the representation of these objects likely to be in PERL, Python, C or C++? How likely is it that we'll have to write client code to do all of the SOAP client work and build a layer to protect our PERL programmers from the SOAP client work and any necessary data manipulation? Of course, we'd love to not build Python, PERL, C, and C++ code but I'd love to know how realistic it is to think our developers will be able to use what PERL::Lite, SOAPy, and other SOAP client toolkits hand them. This seems like the promise of standards like SOAP and good SOAP client toolkits.
Also, I wonder what the right approach is when writing a web service assuming it will be accessed using SOAP by users on various operating systems using various programming languages. Even though I'm a Java programmer, it doesn't appear that I will be able to "abstract away" the details of SOAP behind a nice Java API. In other words, I won't start by building Java classes, I'll start by building XML Schema data models for the data objects I will be using in my web service. Those XML documents will be the "lingua franca" of my application and will have to exist independent of the Java classes I write.
If it helps understand the situation, our application is used within our company only, we have lunch daily with the potential users of these services.
Any insights would be most appreciated. Thanks for reading all of this!
Hernan Silberman

First, I want to make it clear that "Web services is not a solution for all and not an alternative for all". I understand your architecture involving "High Volume Servicing".
If you want to expose your applications as services accessible over internet using "firewall-friendly protocols" and enable them to interoperate with Heterogeneous applications, then you may consider to adopt Web services as a solution. Otherwise, you may think of Web services as an additional service channel. In all these situations, choosing a SOAP implementation is important - meaning it meets your requirements in terms of "Systemic Qualities" like availability, reliability, latency, secutity and so on. In addition, you also need to make sure you adopt standard based apis and environment to ensure that you don't get drenched in proprietary vendor solutions.

[hernan silberman]

Quote:
"
First, I want to make it clear that "Web services is not a solution for all and not an alternative for all". I understand your architecture involving "High Volume Servicing".
If you want to expose your applications as services accessible over internet using "firewall-friendly protocols" and enable them to interoperate with Heterogeneous applications, then you may consider to adopt Web services as a solution. Otherwise, you may think of Web services as an additional service channel. In all these situations, choosing a SOAP implementation is important - meaning it meets your requirements in terms of "Systemic Qualities" like availability, reliability, latency, secutity and so on. In addition, you also need to make sure you adopt standard based apis and environment to ensure that you don't get drenched in proprietary vendor solutions.
"
I am considering web services as possibly providing an additional "service channel" as you put it nicely. I don't need to pierce firewalls, but I do need to service a heterogeneous set of parties interested in using the business logic in our application. After lots of research, SOAP seems like the right answer but I was hoping to get a better understanding of the usefulness "out of the box" of the SOAP client toolkits currently available, from the perspective of the Java software engineers in this forum.
thanks...
Hernan