You might use a Java/XML binding framework, such as Castor or JiBX, to automatically map your object structures to and from XML.
Anne On 4/15/05, Soti, Dheeraj <[EMAIL PROTECTED]> wrote: > > Tim, > > I agree that web services is great for heterogeneous environment, specially > when you have to expose legacy systems. But the fact that I have to flatten > my objects and then again turn them into OO poses a good amount of work. > Ideally I would expect web services to do it for me. I have an OO > environment and if I need to send my objects over the wire then it should > take care of flattening it out and converting it back. Something like what > happens when I use JDO for persistence. I just give it my object and then it > takes care of it. > > There are some .NET to J2EE bridges available (like www.jnbridge.com). They > claim that they can go across the firewalls. Did you evaluated any of those > options for your project? I am leaning towards having two different > solutions. One for the .NET based UI clients (bridge kind of thing) and > another having the published API using web services (this will be a much > more flatter version). > > Thanks > > Dheeraj > > > > -----Original Message----- > From: news [mailto:[EMAIL PROTECTED] On Behalf Of Tim K. (Gmane) > Sent: Friday, April 15, 2005 11:11 AM > To: [email protected] > Subject: Re: .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
