WCF Advice

[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

[Nicholas Paldino [.NET/C# MVP]]

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 Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Bill McCormick" <wp*********@newsgroup.nospamwrote in message
news:Ow**************@TK2MSFTNGP04.phx.gbl...

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 McCormick]

Nicholas Paldino [.NET/C# MVP] wrote:

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.

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

[Nicholas Paldino [.NET/C# MVP]]

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 Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Bill McCormick" <wp*********@newsgroup.nospamwrote in message
news:49************@newsgroup.nospam...

Nicholas Paldino [.NET/C# MVP] wrote:

>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.

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 McCormick]

Nicholas Paldino [.NET/C# MVP] wrote:

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.

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

[Nicholas Paldino [.NET/C# MVP]]

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 Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Bill McCormick" <wp*********@newsgroup.nospamwrote in message
news:up**************@TK2MSFTNGP03.phx.gbl...

Nicholas Paldino [.NET/C# MVP] wrote:

>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.

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 McCormick]

Nicholas Paldino [.NET/C# MVP] wrote:

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).

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

[sloan]

You can see my "separation" technique here:
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry

.........

Juval's book is one of the best.
My example uses one of his helper libraries.

"Bill McCormick" <wp*********@newsgroup.nospamwrote in message
news:Ow**************@TK2MSFTNGP04.phx.gbl...

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