Metadata and WCF Essentials - The Metadata Explorer
(Page 2 of 4 )
The metadata exchange endpoint provides metadata that describes not just contracts and operations, but also information about data contracts, security, transactions, reliability, and faults. To visualize the metadata of a running service I developed the Metadata Explorer tool, available along with the rest of the source code of this book. Figure 1-8 shows the Metadata Explorer reflecting the endpoints of Example 1-7. To use the Metadata Explorer, simply provide it with the HTTP-GET address or the metadata exchange endpoint of the running service to reflect the returned metadata.
Figure 1-8. The Metadata Explorer
Client-Side Programming
To invoke operations on the service, the client first needs to import the service contract to the client’s native representation. If the client uses WCF, the common way of invoking operations is to use a proxy. The proxy is a CLR class that exposes a single CLR interface representing the service contract. Note that if the service supports several contracts (over at least as many endpoints), the client needs a proxy per contract type. The proxy provides the same operations as service’s contract, but also has additional methods for managing the proxy life cycle and the connection to the service. The proxy completely encapsulates every aspect of the service: its location, its implementation technology and runtime platform, and the communication transport.
Generating the Proxy
You can use Visual Studio 2005 to import the service metadata and generate a proxy. If the service is self-hosted, first launch the service and then select Add Service Reference… from the client project’s context menu. If the service is hosted in IIS or the WAS, there is no need to pre-launch the service. Interestingly enough, if the service is self-hosted in another project in the same solution as the client project, you can launch the host in Visual Studio 2005 and still add the reference, because unlike most project settings, this option is not disabled during a debug session (see Figure 1-9).
Figure 1-9. Generate a proxy using Visual Studio 2005
This brings up the Add Service Reference dialog box, where you need to supply the base address of the service (or a base address and a MEX URI) and the namespace to contain the proxy.
Instead of Visual Studio 2005, you can use the SvcUtil.execommand-line utility. You need to provide SvcUtil with the HTTP-GET address or the metadata exchange endpoint address and, optionally, with a proxy filename. The default proxy filename is output.csbut you can also use the/outswitch to indicate a different name.
For example, if you’re hosting the serviceMyServicein IIS or the WAS, and have enabled metadata public sharing over HTTP-GET, simply run this command line:
SvcUtil http://localhost/MyService/MyService.svc
/out:Proxy.cs
When you are hosting in IIS and selecting a port other than port 80 (such as port 81), you must provide that port number as part of the base address:
SvcUtil http://localhost:81/MyService/MyService.svc
/out:Proxy.cs
With self-hosting, assuming the self-hosted service enabled metadata publishing over HTTP-GET, registers these base addresses and exposes the matching metadata exchange endpoints with a relative address ofMEX:
http://localhost:8002/
net.tcp://localhost:8003
net.pipe://localhost/MyPipe
After launching the host, you can use the following commands to generate the proxy:
SvcUtil http://localhost:8002/MEX /out:Proxy.cs
SvcUtil http://localhost:8002/ /out:Proxy.cs
SvcUtil net.tcp://localhost:8003/MEX /out:Proxy.cs
SvcUtil
net.pipe://localhost/MyPipe/MEX
/out:Proxy.cs
The main advantage of using SvcUtil over Visual Studio 2005 is the numerous options it offers through switches for controlling the generated proxies, as you will see later in this book.
For this service definition:
[ServiceContract(Namespace = "MyNamespace")]
interface IMyContract
{
[OperationContract]
void MyMethod();
}
class MyService : IMyContract
{
public void MyMethod()
{...}
}
SvcUtil generates the proxy shown in Example 1-15. You can safely remove the settings ofActionandReplyActionin most cases, since the default of using the method name is good enough.
Example 1-15. Client proxy file
[ServiceContract(Namespace = "MyNamespace")] public interface IMyContract
{
[OperationContract(Action = "MyNamespace/IMyContract/MyMethod",
ReplyAction = "MyNamespace/IMyContract/MyMethodResponse")]
void MyMethod();
}
public partial class MyContractClient : ClientBase<IMyContract>,IMyContract
{
public MyContractClient()
{}
public MyContractClient(string endpointName) : base(endpointName)
{}
public MyContractClient(Binding binding,EndpointAddress remoteAddress) :
base(binding,remoteAddress)
{}
/* Additional constructors */
public void MyMethod()
{
Channel.MyMethod();
}
}
The most glaring aspect of the proxy class is that it has no reference to the service-implementing class, only to the contract exposed by the service. You can use the proxy in conjunction with a client-side config file that provides the address and the binding, or you can use it without a config file. Note that each proxy instance points at exactly one endpoint. The endpoint to interact with is provided to the proxy at construction time. As I mentioned previously, if the service-side contract does not provide a namespace, it will implicitly use the http://tempuri.orgnamespace.
Next: Administrative Client Configuration >>
More Windows Scripting Articles
More By O'Reilly Media
|
 This article is excerpted from chapter one of the book Programming WCF Services, written by Juval Lowy (O'Reilly, 2007; ISBN: 0596526997). Check it out today at your favorite bookstore. Buy this book now.
|
|
/ 4 
