Data Persistence and Communication

Hi,
Here's a system for which I am in the process of evaluating the architecture design options in .NET

Server Application
1. Communicate through a socket connection to receive expected data
2. Persist the expected data on server objects
3. Listen on a COM Port to get the actual data from Scanners, and trigger a refresh on the client application

Client Application
1. Access the server object to retrieve the expected data
2. Receive a periodical trigger from the server to refresh screen with actuals.

The architecture design options with the pro(s) and con(s) is the objective. The 2 challenges are 1) Persisting Data and 2) Server/Client Communication

One option we can think about is Remoting for communication in distributed environment using singleton objects.

MSMQ can also be an available option. As for distributed environment, web service communication can also be an option.

What are the other feasible options we're left with? And how can a server application trigger off a client to make it appear event-driven?

Any inputs will be of great help.
Thanks,
Jemima.

Still need help with this?

Although the project got into a completely different approach to keep things simple, some of the options we finally laid down were:
1. Using MSMQ for persistence and triggering
2. DataBase storage and timer based triggering
3. .NET Remoting for persistence and remoted events for triggering
4. Files for persistence and file system watcher concept..

None of these were fully accepted. The approach that was finally given to us was using Database for storage and directly letting the clients talk to the scanners, risking the chance of losing data on any kind of outage situation.

Still, if there's something you can add to the above, it will definitely help us to learn more.

Thanks,
Jemima.

Maybe I can add a little. I'm not sure about the MSMQ. I can just tell where I'm at. We needed our clients (HMIs) to appear Event driven in a Client-Server based architecture, where the server generates Events from a PLC.

So something will happen on the PLC, and all the Clients will instantly know about it. I made an Event Transmission Architecture in DCOM using VB6. A Singleton was required on the Server. Now, all our Client HMIs in the system have lights that light up when something happens on the PLC. Also, I made Command Buttons on the HMI that push information back down to the server.

So I've got it all up and running and I am happy with it, but I want to leave the COM-DCOM world and re-implement the whole thing in .NET land.

I researched .NET Web Services, and they are insufficeint to implement this kind of Event-driven responsibility.

So now I am researching .NET remoting and am about to embark on a .NET Remoting implementation of the same thing.

I really didn't have too much to add, more interested in discussing your thoughts on all this. It sounded like you chose not to go the route of .NET Remoting. Why? It seems like the cleanest approach.

.NET Remoting is apt for your requirement if we want to trigger off clients from a server app. In our case, in addition to this, we had to persist data, in the form of object instances, in memory. The reason we ruled out remoting was for the latter option. In fact, it was a straight NO from our Clients (I work for a services company) as their architects were adviced by Microsoft not to use remoting at this point. What I can imagine is maybe there's some inconsistency in its performance and MS is going to release a better version of it. Just my guess, though. Cos I know of other companies using remoting extensively.

In the POC we tried, we achieved the triggering part by remoting events and using delegates. The app would send out a trigger to all clients that were listening on a port. We didn't succeed in trying to trigger only 1 client out of a group; that's just when the project was called off.. so no progress was made beyond that..

If the choice was ours, I'd have strongly suggested MSMQs for this scenario as it offers a lot of the required functionality, in built.

Jemima.

Quote:

---

Originally Posted by JemimaChadwick

In the POC we tried, we achieved the triggering part by remoting events and using delegates. The app would send out a trigger to all clients that were listening on a port. We didn't succeed in trying to trigger only 1 client out of a group; that's just when the project was called off.. so no progress was made beyond that..

---

Too bad. I got this to work and I am extremely happy with the results. What you have to do is create not only an Event Delegate, but also an Event Filter on the server side. My clients do not interact directly with the Event Delegate. Rather, they subscribe to Named "channels" which directly correlate to a Named Event. In this case, they only hear the event that is meant for them. The Events are Broadcasted like

VB Code:

RaiseEvent Message(Name, Value)

Quote:

---

If the choice was ours, I'd have strongly suggested MSMQs for this scenario as it offers a lot of the required functionality, in built.

Jemima.

---

How modern is MSMQ? Is it a recommended architecture, given the recent mass-migration to .NET? Support for DCOM is dying/dead, so that's why I am looking for something new to replace it with. I'd hate to find the same thing happen if I would jump to MSMQ...

That being said, I really like what I see in MSMQ. I found this msdn article so I will read up on that:

http://www.microsoft.com/windows2000...mq/default.asp

Do you have any direct experience with MSMQ?

Dave

Oh Good.. I should try this out when I find time.. and I'll get back to you if I had doubts.

As for MSMQ option, it best suited our requirement cos the system itself was functioning in a first come first serve basis.. so when we have the datastructure implemented for us, why go in for a different approach and implement the queue?
I'm not able to comment on how modern it is with respect to the new architecture but we still use MSMQ in our projects when necessary, the way we used to during good old VB/ASP days. Specifically in our websites when some processing takes more time (likely example would be online order placement), a message is posted on the queue and a listener instantly picks it up and does the necessary processing as a background process.. that way the load on the web page is reduced and its a smooth ride for the user.. ofcourse if something went wrong, the listener would send a mail to the user. So I guess MSMQ is gonna stay!

Jemima.