can a webservice reference a remoting object?

[Glowworm27]

I have an Remoting object, and as I understand it, the remoting object cannot be accessed by mobile or smartphones. They can only access webservices.

So I am creating a webservice front-end to communicate with the remoting object. My question is two-fold can the webservice call and interact with the remoting object, and can the remoting object run in singleton mode?

I have serveral clients that need to access the remoting object as if it were one server, because the object keeps track of each client connected to it.

Thanks in advance

George Oakes
Check out this awsome .Net Resource!

http://www.learnvisualstudio.net

 

[chrissie1]

Why not?

Christiaan Baes
Belgium

"In a system where you can define a factor as part of a third factor, you need another layer to check the main layer in case the second layer is not the base unit." - jrbarnett

 

[BoulderBum]

The web service code can access a remoting object as any other .NET code on your network should be able to, but if several of your clients are devices unable to support remoting, you may want to reevaluate the value of remoting in your architecture.

It may be that you can forego remoting altogether in favor of web services to simplify things a bit and avoid the extra overhead of remoting.

MCP, MCTS - .NET Framework 2.0 Web Applications

 

[Glowworm27]

problem with webservices is that they do not remain static, and die after a client connects. And cannot share information between clients

I want an object that will continue to remain active as clients connect and disconnect, and can share info.

A webservice object is created new for each client, where the singelton remote object creates one object that the clients connect too, and this is the functionallity we need, so webservice is out of the question.

Now a webservice that connects to a singleton remote object while it is creating an object for the client, the webservice is connecting to one object with many clients connected.

George Oakes
Check out this awsome .Net Resource!

http://www.learnvisualstudio.net

 

[BoulderBum]

Strictly speaking, web services are a part of your proposed solution, it's just a matter of the implementation behind the service. Also, as a slight correction, the web service doesn't "die" after a client connects, rather an individual request is disposed of.

There's nothing to say that the transient request can't reference a persistant object behind the scenes (which is what you're proposing), the question is, "Does remoting need to be part of the equation?". The concept of a singleton and shared state is not unique to remoting and can be implemented behind a web service with or without remoting.

In fact, there are some compelling reasons to do so: if there are any breaking changes to the remoting class and you have a variety of clients that reference an old version of the remoting class' assembly, then the clients will all break. You'd have to recompilae and redeploy every client.

The web service avoids this problem by abstracting the compiled singleton behind a service call. Making changes is therefore easier because the singleton object code need only be redployed to the web application host, not multiple clients.

There's also less configuration, greater portability and fewer firewall issues with a web service approach.

Mind you, your situation might warrant the use of a combination of remoting and web services, I'm just saying that a reevaluation of the use of remoting might be in order to ensure you're making the right choice.







MCP, MCTS - .NET Framework 2.0 Web Applications

 

[chrissie1]

problem with webservices is that they do not remain static, and die after a client connects. And cannot share information between clients

If you set them up as session-scoped then yes, but you could change the scope to application.

Christiaan Baes
Belgium

"In a system where you can define a factor as part of a third factor, you need another layer to check the main layer in case the second layer is not the base unit." - jrbarnett

 

[Glowworm27]

BoulderBum,

I agree, that it does not need to be a remoted object. In the original design phase we wanted a client on the wan (mobile units in the field via internet) to connect into the agency lan via port 80, because the firewall prevented other traffic. I wanted to use the remoting singleton model to allow it to keep track of units logged on at any one time. And be able to share data between them. So I knew the webservice alone would not work, which is why I went down the remoting path.

Further on into developement, after the application was being deployed in beta, a clint asked if we could write the application to run on PDA's and smartphones? Well the current Mobile 5 and Mobile 6 OS from Microsoft does not support remoting, only webservices, which is why I am now going down this path. And because I didnt want to modify the original client I wanted to see if putting a webservice front-end in the path between the Mobile 5/6 client and the remoting object would work.

In the future will eventually modify the original client to use the webservice, and the mobile unit will continue to do the same. but for now I just wanted to see if it were feasable.

Thanks all for your wonderfull insight.

George Oakes
Check out this awsome .Net Resource!

http://www.learnvisualstudio.net

 

[BoulderBum]

Makes sense, especially if you already have application infrastructure built around remoting.

MCP, MCTS - .NET Framework 2.0 Web Applications