I've been struggling with just this problem in the last few weeks. We also want our integration API to be accessible from XML integration servers, so it really has to be flattened extents in web services.
Our plan is to implement a helper facade to instrument the proxy generated by Axis and .NET for our service. This facade would provide a "idiomatic" transactional interface for programmers on top of the data access provided by the proxy generator. Key responsibilities would be: - process key/keyref constructs into object dereferences over the extent-of-extents result set. - cache by oid/type objects returned in the extent - provide a factory that would build new objects with identities recognizable on the server - trap mutations to create change records for submission back to the server - build change messages to return to the server I spent a bunch of time looking into strategies in Axis to make building this layer easier, including posting a number of times to this list without any response. At the moment it looks like I'll have to build an additional extra code generator :-( Some things that Axis could do to help (and it has occurred to me I could become a contributor): - separate interface/impl generation so dynamic proxies can be used to trap methods - I could not for the life of me get the type mapping override to work at the service level, I had to postprocess the Axis-generated binding stub code - a message context that lasts through deserialization so one can stash a closure there for caching - native key/keyref support would be even better :-) - extensible java source for XML schema generator - it looked like in the code that there is an override model but it only works for WSDL declarations JAXRPC2/JAXB2 promises some of these things: separate interface/impl, complete key/keyref support, but it won't be out for a while. Has anyone else tried to build a general-purpose "relationalesque" integration API using AXIS? Peter --- "Soti, Dheeraj" <[EMAIL PROTECTED]> wrote: > > > > Message > > > > > size=2>Tim, > > size=2> > I > agree that web services is great for heterogeneous environment, specially when > you have to expose legacy systems. > class=540213318-15042005>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. > > size=2> > There > are some .NET to J2EE bridges available (like > href="http://www.jnbridge.com";>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). > > size=2> > > size=2>Thanks > > size=2> > > size=2>Dheeraj > > > > face=Tahoma size=2>-----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: > > [EMAIL PROTECTED] > type="cite"> > > > 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 > >
