Re: .NET to J2EE interaction

[Tim K. (Gmane)]

Title: .NET to J2EE interaction

I actually think it is the solution as long as you can build a layer on the .NET side to take the flattened objects required by WS and turn them into OO again (pretty much undo the flattening you did on the server side). This way the UI developers could work against a somewhat nicer OO API without even being aware of the WS behind the scenes (of course, this is great in theory, in practice you have to be careful how you design this OO layer and also the callers have to be careful to batch operations so that they don't do a network round-trip for every little thing the UI needs to do). We had the same problem with our project, we are exposing a WS API for integration purposes and .NET GUI clients, but the same API is available on the Java server side (J2EE) for our web interface and other protocol servers that run "in-process" on the server. The developers whined about it in the beginning but now they are used to it :) It would have been nice to have the time and have a nice OO API though ... I think the focus should be getting a robust WS API, solve all the interop problems (we are not there yet) and then worry about a nice OO layer. If you try to do them all at the same time, you will be working on it for a while, depending on your project size. I don't think you want to do something like CORBA if your .NET clients need to go through a firewall, etc. but you can take a look at it as an alternative. Tim Soti, Dheeraj wrote: Hi, I have two tasks at hand. Exposing the middle-tier (j2ee) API so that UI (.NET) clients can use it and publishing the public APIs so that anyone can build solutions on top of my platform. Initially I thought web services can be a way to do both of them but now I learnt that web services should not be treated as distributed objects. I am pure OO programmer using all the richness of its features like inheritance, polymorphism, overloading. I can achieve some of them through rpc/encoded but WS-I doesn't recommend it. Doc/literal wrapped is the recommended approach for interoperability but that forces me to flatten out my objects and become kind of non-OO (can't do overloading, polymorphism). Its fine to leave these features for published APIs but for my .NET clients this will be kind of going back to procedural programming era. J2EE & .NET are both OO aware so why should I have to flatten my objects for them to interact. So I am almost beginning to feel that web services is not the solution to my problem. Is someone aware of any better solution for this scenario (J2EE server and C# .NET client communication). Thanks Dheeraj Soti