Title: Message
|
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
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
|
- RE: .NET to J2EE interaction Soti, Dheeraj
-
