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!