I am looking for some guidance on a couple of distributed design
issues, specifically using XML Web Services vs. .NET Remoting to pass
our business data/entities back and forth in a new, distributed
application we are developing.

Sorry for the overly long post, but a little background:

1.    Our business entity/data is represented by a custom object.  Other
types of data representation (datasets, typed datasets, XML) didn't
really work for us too well due to the nature of the entity.
Currently, our object model dictates that this custom object contains
variables representing other custom objects.  CRUD behavior is not
present in the entity.

2.    The only client that can actually update our business entity and
save the data is a single WinForm .NET application (although in the
future this may change to multiple .NET clients).  All other users of
the data will be getting the data represented in XML (so that means we
need to have a XML WS).  These other clients aren't necessarily .NET
aware.

3.    This is an intranet-only type of application all running within a
trusted Windows domain.  While this is internal only,

From our research and discussion with MS, it seems they strongly
recommend going the XML WS route.  Obviously, trying to use the
XMLSerializer, we are running into problems serializing our custom
business entity due to the fact that it contains some private
variables or public, read-only properties and references to other
complex objects (and they may have private variables, etc.).

Some of these data structures of the custom object are integral into
defining how the custom object is represented and/or created.  For
example, read-only public properties that must be read-only, or
private data collections of some sort that are populated back at the
business/data layer that come from other domains (we obviously don't
want to have the client re-contact those domains to get data for the
entity).

What are our alternatives in this matter?  As I see it:

1.    Modify our custom business entity to have as many of these integral
fields able to be represented in XML serialization.  This irks me from
an OOP standpoint but it is only the one client that really needs the
custom object for updating purposes so maybe we just trust in the
client developers not to necessarily modify things they shouldn't (and
we could put in blocks for this as well).

2.    For our one client, have that use .NET Remoting instead.  Obviously
this would be more work to come up with two service interfaces.

3.    Change our entity representation to something else entirely:
dataset, typed dataset, etc.  The problem is that our entity doesn't
necessarily fit well into the whole dataset relationship model.

I am assuming that .NET Remoting is the way to go, but there are a
couple of issues (beside the extra work and complexity):

1.    We had an engagement with MS at one of their Technology Centers and
the consultants that worked with us strongly suggested we go the XML
route (we didn't really know enough at the time to discuss the
limitations with our custom entity).  They mentioned that one of the
chief .NET guys mentioned during a presentation that while .NET
Remoting will be supported, XML WS is where it's at in terms of
ongoing development and growth.  Comments?

2.    Obviously .NET Remoting introduces a little bit more complexity.
Is there any way we can use the WS we need to setup anyway to service
.NET remoting requests?

So is .NET Remoting the way to go in this situation?

Again, sorry for the long post.  Any and all responses are
appreciated!

Thanks,

-David