WCF Advice

  • Thread starter Thread starter Bill McCormick
  • Start date Start date
B

Bill McCormick

Hello cSharpies,

I'm trying to get up to speed with WCF services.

Does a service need to have a ServiceContract/OperationContract to make
use of a DataContract?

I want to have a service that allows a client to create an object in the
service app and have the service app "do something" with the object.


Thanks,

Bill
 
Bill,

A DataContract is simply the way that complex constructs are sent across
the wire to endpoints in WCF. It's used to comprise the payload of the
message.

The service contract and operation contract make up the endpoint, which
every service needs. The endpoint is made up of the address of the service,
the binding (which defines things like expectations, like transactioning,
security, etc, etc, as well as protocol), and the contract, which exposes
the operations.

You need all of these to expose a service through an endpoint in WCF.
DataContract is simply a means to send a message to the endpoint (in both
directions).

You say that you want the service app to "do something" with the object.
That's simple, just define a method on your contract that will do something,
and then pass the object to the service through the proxy.

Mind you, all transfers in WCF are pass-by-value, so if you want to
change the object that is sent, then you will have to pass it by ref (WCF
should handle this for you), or return a copy of the object that you use
once it is modified.
 
Nicholas said:
Bill,

A DataContract is simply the way that complex constructs are sent across
the wire to endpoints in WCF. It's used to comprise the payload of the
message.

The service contract and operation contract make up the endpoint, which
every service needs. The endpoint is made up of the address of the service,
the binding (which defines things like expectations, like transactioning,
security, etc, etc, as well as protocol), and the contract, which exposes
the operations.

You need all of these to expose a service through an endpoint in WCF.
DataContract is simply a means to send a message to the endpoint (in both
directions).

You say that you want the service app to "do something" with the object.
That's simple, just define a method on your contract that will do something,
and then pass the object to the service through the proxy.

Mind you, all transfers in WCF are pass-by-value, so if you want to
change the object that is sent, then you will have to pass it by ref (WCF
should handle this for you), or return a copy of the object that you use
once it is modified.
Click to expand...

Thanks Nicholas,

So which is more efficient: a) to create the object at the client and
then pass the object as a parameter to the service OperationContract? Or
b) call an OperationContract that returns an object (reference) to the
client, fill in the data, then call the "do something" OperationContract?

Thanks,

Bill
 
Bill,

I would worry more about the design of the service. If the service
creates the object and returns it but the object doesn't need any specific
values set by the service, then this is a bad idea.

If the service doesn't require the values of the object you are passing
to it for the operation you are calling, then that's a bad idea.

Also, you might want to make sure it makes sense to mix your inputs and
outputs like that. It might not make sense from a design standpoint to have
the inputs and outputs mixed on the same object.

Take for example, if you had a method to get the name of the computer
the service is running on. If there is a string parameter that you pass to
it by reference, then that doesn't make sense, since there is no special
initialization of the string that you need to pass to the service.
 
Nicholas said:
Bill,

I would worry more about the design of the service. If the service
creates the object and returns it but the object doesn't need any specific
values set by the service, then this is a bad idea.

If the service doesn't require the values of the object you are passing
to it for the operation you are calling, then that's a bad idea.

Also, you might want to make sure it makes sense to mix your inputs and
outputs like that. It might not make sense from a design standpoint to have
the inputs and outputs mixed on the same object.

Take for example, if you had a method to get the name of the computer
the service is running on. If there is a string parameter that you pass to
it by reference, then that doesn't make sense, since there is no special
initialization of the string that you need to pass to the service.
Click to expand...
Yes, the design is what I'm focusing on at this point (sorry if I didn't
make that clear.) At the risk of appearing slow, I'd like to just follow
up with a sort of confirmation just to make sure that I understand; I
don't want to fly off in the wrong direction. :) Let me provide a little
more background:

A host application will have a number of different WCF services.
ServiceContacts will provide a pair of OperationContracts: one for
sending a collection objects (defined by a CollectionDataContract of
DataContract of class X) and another for retrieving a collection objects
(again, CDC of DC of class X).

So, the design in a nutshell: Both client and host applications will
reference a Service.dll which provides definitions for contracts. When
sending, the client app will create a collection of X, connect to the
service and call OperationContract "A" passing the collection as a
parameter. When receiving, the client app will connect and call an
OperationContract "B" that will return a collection of X.

So, am I starting off in the right direction? Am I missing anything
small or large? Would it be better to split the the Service.dll into
DataContracts.dll and ServiceContracts.dll, where the client app only
uses the DataContracts.dll and the host app uses both?

Thanks,

Bill
 
Bill,

Well, I would definitely have the data types and the contracts in one
dll. However, by contracts I mean the INTERFACES ONLY. The interface is
the representation of the contract in .NET, not the implementation. That is
separate on your service. The service and the client would share the dll
that has the interfaces and data structures that are passed between client
and service.

However, you don't HAVE to use the same DLL between the client and the
service if you don't want to. If you are publishing your metadata through
Metadata Exchange, then you can have VS.NET connect to your service and
create the proxy and all data types needed automatically. This is the
purpose of DataContract. It allows for objects that are different in the
..NET type system to be equivalent over the wire (this was primarily because
not all communication in WCF is .NET to .NET, so you can't exactly pass an
interface/structure around to a Java client, for example).
 
Nicholas said:
Bill,

Well, I would definitely have the data types and the contracts in one
dll. However, by contracts I mean the INTERFACES ONLY. The interface is
the representation of the contract in .NET, not the implementation. That is
separate on your service. The service and the client would share the dll
that has the interfaces and data structures that are passed between client
and service.

However, you don't HAVE to use the same DLL between the client and the
service if you don't want to. If you are publishing your metadata through
Metadata Exchange, then you can have VS.NET connect to your service and
create the proxy and all data types needed automatically. This is the
purpose of DataContract. It allows for objects that are different in the
.NET type system to be equivalent over the wire (this was primarily because
not all communication in WCF is .NET to .NET, so you can't exactly pass an
interface/structure around to a Java client, for example).
Click to expand...

OK. Thank you. That is a very clear explanation. I think publishing
Metadata is what I want to do over sharing the class via DLL. I have
been using "Essential WCF" by Steve Resnick et. al. but the section on
Metadata Exchange did not make it very clear how to use it. Juval Löwy's
book "Programming WCF Services" just landed on my desk and seems to have
more/better info; I'll work with that.

Thanks,

Bill
 
Back
Top