[ome-devel] C/C++ client library for OME::Remote

[Harry Hochheiser]

Chris:

Ok, perhaps I'm being a bit dense here. Why would it be a "significant 
extension" to use SOAP? Admittedly, creating the WSDL descriptions 
would be some work, but it might be worth while.  However, switching to 
SOAP on its own should not be difficult.

Furthermore, I'd argue that service advertisement and stub generation 
would be worth a moderate amount of effort on their own.

harry

On Jul 19, 2004, at 1:12 PM, Chris Allan wrote:

> On Mon, Jul 19, 2004 at 12:21:59PM -0400, Harry Hochheiser wrote:
>>
>> Chris:
>>
>> yes, I know we're not currently using SOAP,  but the point is that we
>> could if we wanted to. In theory, we should just be able to swap 
>> around
>> a couple of libraries (some on the client and some on the server). If
>> there was enough value to be gained, this would be worth considering,
>> right? Or is there some inherent objection to even considering SOAP?
>
> We went down this road before with the first incarnation of the remote
> framework. It even worked simultaneously with SOAP and XML-RPC as a
> matter of fact. I fail to see what SOAP buys us other than service
> advertisment and automatic stub generation for our particular
> application. A migration to SOAP along the WSDL/UDDI lines would not
> just be a "swap around a couple of libraries" it would be a significant
> extension.
>
>>
>> -harry
>>
>>
>> On Jul 19, 2004, at 10:32 AM, Chris Allan wrote:
>>> Yes, yes and yes. All fine and dandy if you're using SOAP. I'm fully
>>> aware of all of the above in terms of what most web services
>>> integrators
>>> like to call "fair play." However, as I said we are not using SOAP 
>>> and
>>> are not likely, unless you're volunteering and would think it of 
>>> great
>>> benefit, to migrate the entire remote framework and Java client 
>>> library
>>> to SOAP.
>>>
>>> The grid computing world, ah yes, with the largest project re-writing
>>> its entire implementation twice and planning to do it again, I don't
>>> think we're likely to jump on that boat. Not to mention they've got
>>> their own extensions to SOAP to make it "secure."
>>
>
> -Chris
>