Remoting or Web Services

Hello,

I need to create server and client software, but I do not know the right way to go.
Communications between applications would be through internet and only server would have reachable IP address.

Main concepts of application working:

Third-part vendor would be responsible of order receiving. After order received, order’s data would be passed to my server application (perhaps, here web services are ideal to use).

Idea of comunication have changed. See next post.

Quote:

---

Server should save order in DB and pass it to logged in client (client application). After client is logged in to application, the orders would be passed in.

Steps of order processing:

1. Order received (other vendor)
2. Order passed to server
3. Server passes order to any (randomized) logged in client.
4. If client do not accept order in 15 seconds order is passed to next logged in client. This circle is preceded while the order is not accepted by any client.
5. Response is sent to order receiver after order is accepted by any client.
*. Number of active threads must be limited to logged in clients number. If there are more orders, than clients – order are placed in query.

---

Hope you understood main requirements of the needed software.

I seek for advice of creating such software. Is it very hard? What technologies and methods to use? When to use web services and when remoting? I must point that security and attainability is comma also.

You advices would very valuable for me.
Regards in advance.

Andrius

Hi,

The idea how Server/client comunicates have changed.

The same list with all pending orders must be transfered to all clients. If order ir accepted by any client, list must be updated to all clientes in real time.





Any suggestions?



Regards

Look into System.Net.Sockets.TcpListener and System.Net.Sockets.TcpClient in msdn.

and/or use a database and query it every so often to see which orders have been accepted and/or which ones are outstanding.

From a security point of view, web services hosted in IIS allow a richer authentication mechanism, and also the passing of the user credentials (even the Windows credentials).

In .Net 1.1, a great deal of plumbing has to be put in for remoting over a TCPChannel if you wish to achieve the same result. However, TCP remoting with .Net 2.0 has a good deal of this plumbing already implemented in the Framework.

As regards state, persistent objects can be used with remoting, whereas a web service is a one-call, stateless operation.

One can also use remoting via an HTTP Channel. This is slightly slower than using the TCPChannel, but allows a good deal of the security functionality of using a web service.

Another useful security tool for web services is the Web Service Extensions (WSE). You can implement encryption and digital signatures, using certificates. Together with the functionality of IIS, this is probably the most complete security solution of all options. More and more clients are asking for security at the message layer.

Web services, WSE and HTTPS are standard across platforms (Java, .Net etc.) allowing Java to talk to .Net, whereas remoting uses proprietary formats for communication.

Hope this is useful

Chris Seary

Thank you, oldbear.

What differences is between web services and WSE?

Because Web services, WSE and HTTPS are standard across platforms I'm thinking of using one to retrieve orders from vendor.

After I retrieve order, it must be forwarded to all connected clients the same time. Here I think of using sockets or .net remoting. After any of clients accepts order, other clients must update their list removing taken order.

There would be ~60 (200 max.) clients. Security and performance is very important.

You said that I can use remoting via an HTTP Channel? Isn't it stateless?

I'm new to networking and for now working with .NET, but thinking of trying to use .NET 2.0.

Maybe you can give me more suggestions and maybe provide some online resources?

Hi Norkis

Web services refer to sending SOAP documents across HTTP and HTTPS. Generally, in .Net this refers to files created using .asmx. Remoting via HTTPChannel is also a web service, but this use of remoting has a lot of proprietary Microsoft related information. Rewmoting via HTTPChannel is, as you said, stateless. This means that any method calls have to be designed to run in a stateless fashion.

A standard (ie. not using remoting) web service can also have be WSE enabled, allowing the use of digital signatures, passing of credentials and encryption. However, the richness of authentication is not available (for instance, you can't use certificates to authenticate against Active Directory via WSE, as you can with HTTPS). However, there's nothing to stop you using HTTPS (for authentication) as well as WSE (for digital signatures), or other combinations.

Web Services conform to standards which apply across platforms. So do web service extensions. Using WSE and HTTPS would be an excellent choice for communicating with vendors.

Here are some references:

WSE and .Net 2.0
http://msdn.microsoft.com/msdnmag/is...n/default.aspx

WSE in general:
http://msdn.microsoft.com/webservice.../building/wse/

OASIS standards for SOAP Message Security
http://docs.oasis-open.org/wss/2004/...curity-1.0.pdf

Remoting can also take place over a TcpChannel. In .Net 1.x, no authentication information is passed, unless you set up a custom sink. However, .Net 2.0 has rectified this and allows Windows credentials to be passed across:
http://msdn.microsoft.com/msdntv/tra...ranscript.aspx

Remoting via a TcpChannel is very efficient. However, this is not the only way to kove data between hosts. You could also look at using Microsoft Message Queue. This is not quite as fast, but passing messages in a disconnected fashion will usually increase scalability.

Hope this helps

Chris Seary

Thank you very much, Chris.

It's enough information to me to start learning these things.
I do not close this thread as I hope to continuous this discussion with you and others after I have new questions.

Thank you again.

Best regards,
Andrius Norkaitis

After reading some articles I have new question about .NET remoting.

What to use: sockets or .NET remoting and pass object with values and methods to clients?

If I use sockets, everythink is clear - server/client comunicates by sending binary data, that can be serialyzed object or just a simple command with few parameters. In this way I need to read more about asyncronous call to send commands to all clients the same time and not wait while previous command to complete.

If with .NET remoting, I need to understand few things more.
Etc. there is class with fields and methods created in server. After client connects, it asks for this object by reference. He gets the same object as in server (etc. orders list) Then, if any client change any of the fields, such object is changed to all of others clients? If yes, it's simpler, becouse I do not need worry about sending data, accepting some commands and I just code one class with fields and methods. If this is the method how .NET remoting is working over TCP using binary may it run using HTTP? I know, that HTTPis stateless, but I found on MSDN that .NET Remoting can be used over HTTPeven with callbacks? What this means? Does his mean that if client changes the object, server is notified, but if server changes the object client isn't notified, becouse of how HTTPworks (request/response)?



Thank you in regards.

Hi Norkis

For asynchronous calls, you could try calling the web service using a delegate - the Wrox book 'Professional ASP.Net Web Services' has a good chapter on this.

Essentially, you make the call using a delegate so that your application doesn't hang around waiting for the result. This allows the implementation of a CallBack function that will handle the completion of the call. Here's a URL giving a fairly good explanation:

http://msdn.microsoft.com/library/de...b_services.asp

You can use two types of remoting - well known or client activated. Well known is a type of call that doesn't allow state to be persisted between calls. Client-activated allows the server component to maintain state.

Well known objects can be either single call (a new object is created for each call) or singleton (one object services every call).

It sounds like you might want to consider message queuing for a more robust asynchronous solution? This would keep messages persisted to disc in a transactional manner.

...........and here's a link to some programming guidelines for MSMQ.

Hope this is useful

Chris Seary

.....this time with the link (whoops!)

http://msdn.microsoft.com/webservice...g/default.aspx

Hello,

Thank you for help, oldbear, I appreciate it. I'm much cleaver about networking than before I started this thead :), but also this raised more questions.

If not talking about specific software functionality, I can list such things about comunication, what I need:

Communication between applications would be through WAN (internet), so optimal solution for network bandwidth and server resources is critical. In the beginning there would be ~40 clients and this number can increase to 100. Communication channel must be secure, that no one could read or change traveling data. Authorization is also required, that only particular clients may connect. Server would have static ip address, but about client network configuration I can’t say anything. They could use broadband, isdn etc. and may appear in front of NAT (LAN) and firewall.

1. Server sends messages to all connected clients.
This must be done in real time. If client is offline, messages shouldn't be delivered later. Also the time, then message arrives to clients must be same as near as possible (etc. if internet connection speed is same with all clients, massage should arrive to all clients the same time)
2. Clients send messages to server and other clients.

It would be orders processing system, but communication is like IRC .

Knowing that I’m thinking about such solutions:

a) Server listens on port n for TCP connections.
Client connects to server and retrieves initial data.
If new order is retrieved to server, server send message to all connected clients about this.
If client changes order details, client sends messages to server about it. After that, server notifies all other clients.
If using TCP I would need to know some more details:
Should I use .NET remoting and remote objects or just sockets (TCPChannel)? If with remoting, that I think it must be done with server activated object and using Singleton. Also such things like security, authorization should be integrated. To create this I need to know how to create server: I can use MSMQ, theads, IOCP (http://www.codeproject.com/csharp/managediocp.asp) which is new to me and I don’t know what is better. Also I think this solution would use server resources and network bandwidth heavily. Imagine that client changes some data about order and server and all other clients must be notified. What is happening than: client send data to server, server sends these data to all connected clients. So if there are 40 clients and just one client changes data, there would be 40 roundtrips in server.

b) Maybe to decrease network load I can use UDP protocol, for sending data to all clients. Server opens port n to which data is sent. All clients listen on server port for new data arrive. If client changes data about order, it can inform server using TCP or web service.

c) In these two solutions above, server is responsible for notification about if client changes order details. Maybe there is solution, that client could inform about order changes not only server, but also all other clients. In this case client network load will increase if it change order details.

d) I have just basic knowledge about MSMQ. Maybe I just need to create query which could be accessed by clients. In this case server communication with clients would be already done by MSMQ.

e) Maybe just use web servers? Then client starts program it asks webservice with no parameters and all current list is returned. So he new last items id. After some time n he asks for new list with two parameter, which is the first and the last item's ids in the list. Then only new and deleted orders are returned.

All these solutions are abstract. I do not know all details about it, there futures and lacks. Maybe there is another and better way to do such, like P2P?
Please advise me, which way is the best to do such things? I want to concern just with one technology implementation and not to miss the better one.


Thank you.

Hi Norkis

Sorry for the delay.

Communication between applications would be through WAN (internet), so optimal solution for network bandwidth and server resources is critical. In the beginning there would be ~40 clients and this number can increase to 100. Communication channel must be secure, that no one could read or change traveling data. Authorization is also required, that only particular clients may connect. Server would have static ip address, but about client network configuration I can’t say anything. They could use broadband, isdn etc. and may appear in front of NAT (LAN) and firewall.

(the above are your words, and should hopefully come out in italics).

If you need to authenticate and authroize, then make sure your server component is hosted in IIS.

As bandwidth is an issue, use remoting. Host your remoted server component in IIS. Use a binary formatter with the HTTPChannel, as the requests are smaller using binary. Many people think you can only use a SOAP formatter with remoting over HTTP, but this is not true. You can send binary data across this type of channel.

However, using remoting via IIS means that you won't be able to maintain any state in the object.

It is possible to raise events from the server if the objects are not hosted in IIS and they are client-activated, but the stability of the platform may not be what you need.

I'm not aware of a channel for remoting that uses UDP, but perhaps there is a third party one available somewhere. I think you want the reliability that TCP gives, however.

How about this - host your server as a Windows service. The clients communicate by placing messages on MSMQ. The server picks these up, processes them, and then places the results on a queue specifically for the client that made the call. The client, meanwhile, keeps checking the queue and does not proceed until the reply message has been returned.

The client also monitors another queue, or even a database, for any changes to information that has been changed by the server.

Making an application disconnected gives greater stability (as messages are saved to the disk) and greater scalability (just add more queues and servers to host them).

You'd actually be performing functionality that Biztalk was designed for. Perhaps you'd have a look at what it can do in MSDN? However, I understand that learning a technology like BizTalk may not fit in with the timelines for developing your application. I'm sure it would be worth you finding out about it at a later date, though.