Client/Server decoupling

  • Thread starter Thread starter Ken Allen
  • Start date Start date
K

Ken Allen

I am relatively new to .Net and C#, but I hav ebeen programing in other
languages and done some COM work for a number of years. I am attempting to
understand how to map an older program architecture into .Net -- not looking
to do it at this time, just to understand how I would achieve it.

In the old environment, we had two classes, a client and a server class,
that managed a data object. The server object knew how to interface with the
data store (a database) and it also contained the server-side business
processing logic for that object. The client object held a copy of the same
data and contained the client-side logic (including the business rules that
the front-side needed to understand in order to avoid too many trips to the
server). We used a generic factory that was a client-server class that knew
how to contruct both the client and server class objects and tie them
together (each client object contained a reference to the remote server
object). One of the more significant benefits of this approach was that only
one copy of the server side class object would exist for a specific entitiy
(say, a Customer record) regardless of the number of client class objects
(in different client computers -- within the same client application only
one instance exists for a specific record, regardless of the number of
references to that record) existed, and when the server object changed, the
changes were 'broadcasted' to all instances of the client object
automatically -- and the client side base class contained generic methods to
trigger udpates to the user interface when such changes were reported.
Actions invoked from the user interface were passed to the client class
instance, which sent these through the COM layers to the server class, which
then performed the work and reported the results, including any changes in
the data content, back to this and all other clients holding an instance of
the class object for that record.

I simply cannot see how to achieve this in .Net! I can see that there would
likely need to be three (3) -- if not four (4) -- classes defined: client
class, server class, common class, and possibly a factory or interface class
of some sort. What I cannot see is how I can have one instance of a specific
server class for a specific record, permit multiple client class instances
to exist for the same record, and have the client and server classes aware
of each other.

All of the books and documentation that I have accessed speak to the Web
Service model and make no reference of how to achieve any of the aspects of
this approach. I cannot even find a reference to how I might, from multiple
points in the client (user interface code) end up with multiple references
to the same instance of a class object for a specific record unless I
explicitly keep track of the instances myself (the old approach used the
concept of 'monikers' and did a lookup in the local 'dictionary' before
asking the server/factory to create a new instance for a specific record).

Is this approach even possible in .Net? Or is it possible but so incredibly
difficult to code that one may as well not bother? Or am I missing some
obvious aspects?

-Ken
 
Let me see if I understand.
Client1 makes a change to something. Once reflected on the server you want
to have all the other active clients updated with the change that Client1
did?
 
Hi Ken
The situation you mentioned can be done using .net
remoting services. I can't tell you how in just short post. Still the
issue is not by any way complicated, (in fact it is much more easier than
other ways. I would suggest you read about remoting. And you can try
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/htm
l/cpconaccessingobjectsinotherapplicationdomainsusingnetremoting.asp
And there are some good examples on code project as
http://www.codeproject.com/dotnet/clipsend.asp
Hope that would help
Mohamed Mahfouz
MEA Developer Support Center
ITworx on behalf of Microsoft EMEA GTSC
 
Anyhow, if I understanded well all you have to do is to use the asynchronous
communication between your clients and your server:

Let's say that initially everyone is synchronized. There's some control
value on server (could be the time), same on clients that flags that.
All the clients have to request asynchrounously the update by invoking a
WebMethod through Begin... (in proxy), and passing the control flag.
The server receives the requests, but as long as nothing is changed in the
common data (the control flag is the same) does not respond.
Now Client1 makes an update on the server.
The Server updates the common data, modifies the control flag and responds
to all pending requests that were invoked with a different control flag.
The asynchronous callback associated with End.... (in proxy) will be fired
for all the clients and you can make the updates to the clients (on data and
flag). Immediately after that call again the asynchronous Begin... method.
 
I have checked out those examples, and I still do not see what I am looking
for, unless the basic story is that I have to do it myself based on
lew-level building blocks rather than standard facilities.

Permit me to define the specific process in more detail. Note that this is
how the old 'enterprise application' I worked on functioned.

1. The client code, in response to some action from the GUI, determines that
a new data object for a specific set of information (sa Customer record
where CustomerID=1234) needs to be created.

2. A request is sent to a class factory on the server, which, since no
records exists for this specific customer, creates a server-side class that
encapsulates the data for that record and retrieves it from the database.
This server-side class has "automation" methods as well as local methods
that are meaningful only on the service.

???? How does one permit multiple instances of a class to be remotely
instantiated but still restrict this so that only one instance for a
specific record (Customer) is created?

3. The factory informs the server class about the new client that requested
this instantiation, and the server class 'remembers' this; in fact, the
server class instance remembers all of the clients that are currently
connected.

4. The encapsulated data is serialized inside a wrapper that denotes the
class information and returned to the client where a client-side class
instance is created for the same data; this client side object has its own
methods that are distinct from those in the server-side class. The
client-side class is derived from a base class that permits it to contain a
'remote reference' to the server-side class.

5. If the same client makes a request for the same Customer record, the base
class makes a check on the client (using a moniker dictionary) and returns a
reference to the same class instance.

???? Aside from implementing my own 'moniker dictionary', how do I ensure
that multiple requests for the same client-side record reference the same
record without a request being passed to the server?

6. If one or more other clients make a request to the server for the same
Customer record, the server, using a similar moniker dictionary, determines
that the instance already exists, and adds the client to the interface list
for the server instance. As before, the encapulated data is serialized back
to the client system where a client-side class is instantiated to contain
that data.

7. If one of the clients changes the record, then a method on the client
class invokes an "automation method" (remote method in .Net?) that passes
information to the server class instance. There are actually two modes for
this: one mode simply invokes a methods that passes some parameters that
result in specific processing on the server; the other mode sends all (or a
subset) of the encapsulated data to the server as a 'save or update'
request.

8. The server object receives these automation calls and processes them,
likely updating the database and the contents of the encapsulated data. When
this is complete, if the encapsulated data changed, then all clients except
the one initiating the request are sent a refresh copy of the encapsulated
data; the invoking client is sent either an updated copy of the encapculated
data or the output parameters and result of the automation procedure call
(or both).

9. When a client releases the last reference to the client-side instance of
the class, the server is informed and removes the client from the interface
list.

10. When the last client connection is removed from the server-side class
instance, then the server-side instance is also released.

I know that .Net is a very different paradugm, and most of the focus is on
web services, which are generally stateless, but there are still a large
number of facilities where the above architecture (or some variant of this)
is still value and useful.

All of the references that I have come across seem to indicate that
'pushing' from the server to the client is fraught with problems (again
because almost all of the books and articles focus on web services and not
the classical client/server approaches), but that what I need is a some way
of instantiating client and server classes that encapsulate the same data
but with different methods in the classes, but where each class knows how to
communicate with the other (which implies a type of chicken and egg
scenario) -- the client would know how to communcate with one server object;
but the server object would know about zero or more client objects (on
different client computers). A factory class may be required to get the
initial objects created somehow.

Does this clarify the approach I am thinking of? Is this even possible
without me having to develop all of the framework myself? Is there another
approach in .Net that will give me the same results?

-Ken
 
No, this requires that the client polls the server for any updates. Please
see my response to another post in this thread for more details.

-Ken
 
Ken Allen said:
I have checked out those examples, and I still do not see what I am looking
for, unless the basic story is that I have to do it myself based on
lew-level building blocks rather than standard facilities.

Permit me to define the specific process in more detail. Note that this is
how the old 'enterprise application' I worked on functioned.

1. The client code, in response to some action from the GUI, determines that
a new data object for a specific set of information (sa Customer record
where CustomerID=1234) needs to be created.
Click to expand...


1. Nothing special

2. A request is sent to a class factory on the server, which, since no
records exists for this specific customer, creates a server-side class that
encapsulates the data for that record and retrieves it from the database.
This server-side class has "automation" methods as well as local methods
that are meaningful only on the service.

???? How does one permit multiple instances of a class to be remotely
instantiated but still restrict this so that only one instance for a
specific record (Customer) is created?
Click to expand...



2. You can do that on the server side. "Automation" later. Just use
Application variables to store the common objects.

3. The factory informs the server class about the new client that requested
this instantiation, and the server class 'remembers' this; in fact, the
server class instance remembers all of the clients that are currently
connected.
Click to expand...



3. You can identify the clients by SessionID('s) on server side and have
server statefull facilities through Session variables that are binded to the
client, all you have to do is to create a global cookie container on the
client. It is a minor issue to bind a Session variable to the server
instances of your classes (the ones in Application variables).


4. The encapsulated data is serialized inside a wrapper that denotes the
class information and returned to the client where a client-side class
instance is created for the same data; this client side object has its own
methods that are distinct from those in the server-side class. The
client-side class is derived from a base class that permits it to contain a
'remote reference' to the server-side class.
Click to expand...



4. This is what the proxy class that interfaces the SOAP client
communication and server are for (the one that .Net automatically makes when
you create web refferences). All you have to care is to ensure that the
fields in the object you want to pass are serializable, the proxy will
contain only the serializable info (basically fields); you can inherit it
and create client-side methods.

5. If the same client makes a request for the same Customer record, the base
class makes a check on the client (using a moniker dictionary) and returns a
reference to the same class instance.

???? Aside from implementing my own 'moniker dictionary', how do I ensure
that multiple requests for the same client-side record reference the same
record without a request being passed to the server?
Click to expand...


5. This is probably something you need to implement, a simple dictionary of
instances.
6. If one or more other clients make a request to the server for the same
Customer record, the server, using a similar moniker dictionary, determines
that the instance already exists, and adds the client to the interface list
for the server instance. As before, the encapulated data is serialized back
to the client system where a client-side class is instantiated to contain
that data.
Click to expand...


6. Get it from Application variables. Application IS a collection
(dictionary).

7. If one of the clients changes the record, then a method on the client
class invokes an "automation method" (remote method in .Net?) that passes
information to the server class instance. There are actually two modes for
this: one mode simply invokes a methods that passes some parameters that
result in specific processing on the server; the other mode sends all (or a
subset) of the encapsulated data to the server as a 'save or update'
request.

8. The server object receives these automation calls and processes them,
likely updating the database and the contents of the encapsulated data. When
this is complete, if the encapsulated data changed, then all clients except
the one initiating the request are sent a refresh copy of the encapsulated
data; the invoking client is sent either an updated copy of the encapculated
data or the output parameters and result of the automation procedure call
(or both).
Click to expand...



7,8. That is the "automation" that I've described in my first response.


9. When a client releases the last reference to the client-side instance of
the class, the server is informed and removes the client from the interface
list.

10. When the last client connection is removed from the server-side class
instance, then the server-side instance is also released.
Click to expand...


9,10. Very simple to implement a method for asking the server to release the
object binded to a client. Probably you'll need some sort of client counter
binded to the object stored in Application to release it when the last
client relaease it.


Horatiu Ripa
 
Back
Top