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/OperationContra ct 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]]

Re: WCF Advice

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]
- mvp@spam.guard. caspershouse.co m

"Bill McCormick" <wpmccormick@ne wsgroup.nospamw rote in message
news:OwLIsQQQJH A.1012@TK2MSFTN GP04.phx.gbl...

Hello cSharpies,
>
I'm trying to get up to speed with WCF services.
>
Does a service need to have a ServiceContract/OperationContra ct 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]

Re: WCF Advice

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 OperationContra ct? Or
b) call an OperationContra ct that returns an object (reference) to the
client, fill in the data, then call the "do something" OperationContra ct?

Thanks,

Bill

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

Re: WCF Advice

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]
- mvp@spam.guard. caspershouse.co m

"Bill McCormick" <wpmccormick@ne wsgroup.nospamw rote in message
news:491492A5.7 0007@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 OperationContra ct? Or b)
call an OperationContra ct that returns an object (reference) to the
client, fill in the data, then call the "do something" OperationContra ct?
>
Thanks,
>
Bill

[Bill McCormick]

Re: WCF Advice

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 OperationContra cts: one for
sending a collection objects (defined by a CollectionDataC ontract 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 OperationContra ct "A" passing the collection as a
parameter. When receiving, the client app will connect and call an
OperationContra ct "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.d ll and ServiceContract s.dll, where the client app only
uses the DataContracts.d ll and the host app uses both?

Thanks,

Bill

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

Re: WCF Advice

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]
- mvp@spam.guard. caspershouse.co m

"Bill McCormick" <wpmccormick@ne wsgroup.nospamw rote in message
news:upc6tecQJH A.1164@TK2MSFTN GP03.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 OperationContra cts: one for sending
a collection objects (defined by a CollectionDataC ontract 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 OperationContra ct "A" passing the collection as a
parameter. When receiving, the client app will connect and call an
OperationContra ct "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.d ll and ServiceContract s.dll, where the client app only uses
the DataContracts.d ll and the host app uses both?
>
Thanks,
>
Bill

[Bill McCormick]

Re: WCF Advice

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 "Programmin g WCF Services" just landed on my desk and seems to have
more/better info; I'll work with that.

Thanks,

Bill

[sloan]

Re: WCF Advice



You can see my "separation " technique here:
http://sholliday.space s.live.com/Blog/cns!A68482B9628 A842A!158.entry

.........

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



"Bill McCormick" <wpmccormick@ne wsgroup.nospamw rote in message
news:OwLIsQQQJH A.1012@TK2MSFTN GP04.phx.gbl...

Hello cSharpies,
>
I'm trying to get up to speed with WCF services.
>
Does a service need to have a ServiceContract/OperationContra ct 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