Beginner question regarding upgrading a current framework from .net remoting to wcf

Hi.

Is there an eqivalent to System.Runtime.Remoting.ObjRef in wcf?

Basically I want to be able to serialise information regaridng the
endpoints of a service to a remote registry, where other services/
clients can query to find a servcie interface without worrying about
the actual physical location of the service. This allows me to move
services to different machines without configuring other services/
clients etc.

So with my requirmeent known, if ObjRef has no equivalent in wcf - how
would i achieve my requirement using the new wcf model?

Thanks

Tony

Hi Tony,

I have exactly the same problem. In our remoting-based infrastructure, we use a "Service Manager" to provide transparent access to our services.
This manager holds a list of ObjRefs.

Now we are going to migrate to WCF.
What I want to do is to use the ServiceEndpoint information instead of an ObjRef to pass info about an endpoint to the clients. This ServiceEndpoint instance can be used in the ChannelFactory constructor to create a channel.
That's the plan. But I've to to say that I don't know if ServiceEndpoint is serializable.
Did you find a solution in the meantime?

Cheers
brix

On Oct 22, 5:07 pm, brix <brix.2yv...@xxxxxx-mx.forums.net> wrote: I did some reading around and found that you can obtain some service
metadata for a service that could be serialised to a service broker.
However I can't for the life of me remeber the classes involved. I
believe ServiceEndpoint is not serialisable (that was my first port of
call).

Even though I have not really specced out anything concrete for a wcf
broker I am thinking that jumping right down into the messaging layer
of wcf would be the way forward as you could implement something very
similar to a remoting objref yourself and simply write a set of
channels that send out the objref onto a pgm network etc. That way
your service borker could actually be part of peer to peer mesh
(useful if you have disaster recovery requirements or high
availaibility requirements etc).

If I ever get around to implementing something I'll gladly post it for
you to use if you want.

I have also found some websites that claim that remoting is 'faster'
than wcf in certain scenarios. Where 'faster' may mean more messages
throughput per second...I guess before I start any new framework for
my firm's services (all internal by the way) I will need to have a
'real world' wcf servcie setup in a similar way to how our services
currently need to be setup...i.e. NO soap or http formatter/transprt
combos only binary and tcp (because we are microsoft only here for
everything) and then compare and contrast performance, working set
sizes, msg throughput rates etc.

Tony

That would be great. I'll post new results as well.

There are some MSDN articles about WCF performance
like A Performance Comparison of Windows Communication Foundation (WCF) with Existing Distributed Communication Technologies
In this article, they state WFC " is at least comparable to the other existing Microsoft distributed communication technologies".

Anyhow it is a good idea to make some tests on your own.

brix

I did some research and here is what I found:

• A client needs to create a ChannelFactory to access a service.
• The ChannelFactory instance must be created by using a ServiceEndpoint instance.
• The ServiceEndpoint is usually created by using three things:
  1) The contract (Service Interface)
  2) The binding (type)
  3) The EndpointAdress
• The Contract ( 1) from above) is known to the client.
  So only 2) and 3) must be provided by a "service broker".

The information about binding and endpoint can be easily obtained (on server side) by using the ServiceDescription class (see ServiceHost.Description).
Essentially, only a Type and a String must be transferred to the client. These can be easily serialized and used as a new kind of "ObjRef".

brix

Hey Tony,

On Oct 22, 11:50 pm, tonyandj...@xxxxxx wrote: Check out UDDI and WS-Discovery (http://wcf.netfx3.com/files/folders/
protocol_channels/entry7909.aspx).

UDDI solves the problem above by publishing information about a
service -- e.g., it's contract, policy, and other such info usually
made available by a service using WS-Metadata Exchange (MEX) -- to a
know location (i.e., a service registry). Others only have to know
about the location of the registry, and they will be able to find
different services at runtime and bind to them. On the other hand,
services that use WS-Discovery solve the problem above by broadcasting
their arrival to others on the network. Those who are alive, receive
the message about the newly arrived services and can begin consuming
it if needed. This protocol is usually used in bootstrapping
scenarios and is analogous to DHCP.

--

Regards,

Travis Spencer