I have Modification, Retrieval and Administration operations that are implemented by WCF services. I would like to separate them. The first thing that came to mind was to have three interfaces IRetrieval, IAdministration and IModification and create endpoints based on these interfaces. However, another developer said something about using different bindings or ports. I don't think that's possible - my understanding that WCF binding only defines how the data is treated over the wire and is not fit for logical separation. Am I in the ball park? Are there any other ways to separate the functionality besides the interfaces?
There are only two ways to separate functionalities: separate contracts implemented on the same service or separate contracts implemented on separate services. The difference between these two are more like logical and physical separation. For example default WSDL generation exposes metadata from all implemented contracts in a service. So if you implement all contracts in the single service and expose a metadata endpoint, each client will know an exact description of your administration methods and what security is used.
Related
I want to create an application that will need several calls to webservices to get data for persons, companies, etc. What is the best practice for that:
Create one SVC file / WCF webservices with several methods
or
Create for each entity (person_webservice.svc / company_webservice.svc) a webservice file with only the methode related to that entity?
If you need to manage the visibility, security, transport or other configurable details for each WCF separately then go for multiple WCF's, if all the services are related, share same server, do not need isolation then managing multiple services will get complicated over time and could end up with duplicate code easily.
WebAPI is the modern version of your split WCF idea, each API controller defines the actions specific to a single entity but all belong to the same 'endpoint' or base url.
I am just trying to get to grips with using WCF, and I am wandering if someone could tell me if I have the right idea with endpoints.
I have been working through the videos on msdn, and now I am wandering about the way to configure WCF Service. The scenario is if I have multiple IServices, e.g. such that I have an IThis and IThat, and the client needs the access both (note: they will be using net.tcp),
IThis handles database querying and,
IThat handles calculations independent of the database,
I assume that I have to define separate Endpoints for IThis and IThat, that are referenced in the client separately. Or would I create an overall IThisAndThat Service that gets referenced in the client and contains the functionality for both??
Or is are the other ways for developing and handling WCF Services with multiple IServices? While I'm asking can you define base address for tcp or only http?
~Thanks all, any help or pointers would be great.
I assume that I have to define
separate Endpoints for IThis and
IThat, that are referenced in the
client separately. Or would I create
an overall IThisAndThat Service that
gets referenced in the client and
contains the functionality for both??
You can do both:
you can create a separate service implementation class - one for IThis, another one for IThat
or you can create a single service implememtation class that implements both IThis and IThat
That choice is entirely up to you.
For every service implementation class that you have, you can define any number of endpoints you wish to have. So if you have an ThisService implementing IThis, you can define a HTTP and a TCP endpoint for that, and you also have a ThatService that implements IThat for which you define a TCP endpoint. That's totally up to you.
BUT: you can only define your endpoints for each service implementation class - if you have a ThisAndThatService implementing both service contracts, you cannot define 3 endpoints for IThis and two different ones for IThat - the endpoints you define are per service implementation class.
While I'm asking can you define base
address for tcp or only http?
Yes, absolutely - you can define a base address for each of the various addressing schemes (http, net.tcp, net.msmq, net.pipe and so forth).
Some basics:
Each service has one or more endpoints. The endpoints are specific to their relevant service, i.e. each endpoint can only belong to one service and cannot be shared between services.
An endpoint defines an entrypoint to the service - it includes an address, binding and contract that can be utilized by a client.
Different endpoints must have different addresses, and can have different bindings and contracts (i.e. they do not have to). Typically, different endpoints have different bindings - that is, transport protocol. They can have different contracts if particular clients are only supposed to have access to certain operations.
Finally, your service must implement all of the contracts that its various endpoints expose.
Here's a very concise and straightforward MSDN page which describes these concepts. http://social.msdn.microsoft.com/Forums/en-US/wcf/thread/9f4391e9-8b9f-4181-a081-860d42b992a9/
There's a lot of information on WCF on the web, and there's a lot to learn. Best to look at some tutorials or guides which focus on what you are trying to do.
I have just started evaluating whether or not I should be using OData influenced wcf data services or a standard WCF service application as the primary data source for Silverlight applications. I would like your thoughts on which is a better way under what situation/circumstance. What is lighter over the wire, easier to maintain, etc.
What I have gathered so far is:
There are no Wcf data service templates in VS2010 that I know of, and I will need to create a asp.net web project first and then add a wcf data service, so its going to affect how I structure my projects.
WCF Data services expose actual table names over the service. I don't know yet of a way I can alias them and I'm not sure its a good idea to let the world know my table structure
In a standard wcf service I will need to write linq queries against the EF or Domain service classes on the service side, while in a data service I can move that processing logic to the client.
At first glance examining the classes exposed by the wcf data services seem easier to read and understand than those exposed by the EF
Do add your thoughts on this..
Thanks for your time.
There are no Wcf data service
templates in VS2010 that I know of,
Not project template - just an item template (for use inside an ASP.NET web site or web app). WCF DataServices are very tightly coupled to HTTP, so they only make sense in a web site/app.
WCF Data services expose actual table
names over the service.
NO ! At least not necessarily. The whole point of EF is that you can decouple the actual physical structure of your database from the (conceptual) model that gets exposed. You can totally rename entities, you can map several entities onto a single table, split up an entity over several tables, you can leave out attributes - anything you like!
At first glance examining the classes
exposed by the wcf data services seem
easier to read and understand than
those exposed by the EF
I doubt it - because by default, WCF Data Services will use a Linq-to-SQL or EF model as their basis, really. You can make that as simple or as complicated as you like.
Using a "regular" WCF service allows you to use the netTcpBinding for much faster performance (thanks to binary message encoding vs. textual messages for other bindings), when using your Silverlight 4 app in a company-internal network (doesn't work for internet scenarios) - not something you can do with WCF DataServices.
The main difference in my opinion is the SOAP vs. REST difference:
SOAP (traditional WCF) is oriented towards methods - you think and design your system in terms of methods - things you can do (GetCustomer, SaveOrder etc.)
REST (the WCF DataServices approach) is all about resources, e.g. you have your resources and collections of resources (e.g. Customers) and you expose those out to the world, with standard HTTP verbs (GET, POST, PUT, DELETE) instead of separate specific methods that you define
So both approaches have their pros and cons. I guess the most important question is: what kind of app are you creating, and what kind of user audience are you targetting?
Update:
for intranet / internal apps, I would think the advantage of a netTcpBinding (binary encoding) would justify using a classic WCF service - also for data-intensive apps, I personally find a method-based approach (GetCustomer, SaveCustomer) to be easier to use and understand
for a public-facing app, using HTTP and being as interoperable as possible is probably your major concern, so in that scenario, I'd probably favor the WCF Data Service - easy to use, easy to understand URLs for the user
I have 2 contracts (cA & cB) implemented by a single WCF service with 2 endpoints (epA & epB).
This is not for security purposes, but purely for reasons of clarity/organization, I'd like to only "see" ContractA's operations when I discover the service via endpointA; and likewise, only see ContractB's operations via endpointB.
I don't need to "protect" these operations per se. The scenario is such that any given client only needs one "side" of the service, never both (but, the operations themselves share resources, so it makes sense to have a single service rather than 2 services).
It seems that any given service basically gets 1 WSDL, ergo all operations are exposed to all endpoints. Is that the way it works, or is there a way to "shape" an endpoint by occluding operations not defined by the endpoints contract?
By default, you're right - one service implementation class gets one WSDL which contains all service methods (from all service contracts) that this service class implements.
There are no ways present (as far as I know) to "shape" the WSDL in any (easy) way - WCF does offer ways to get into the process of creating the WSDL (statically or dynamically), but those aren't for the faint of heart. It would be much easier for you to just split the implementation of the service contracts into two separate classes and then you'd have two separate services, separate WSDL's and all.
Marc is absolutelly right. I'm just adding why this happens in WCF. In WCF all metadata related functionality are based around service metadata behavior and mex endpoint. Both these features are defined on service level. So you can't take higher granuality (unless you write a lot of custom code) and specify metadata per endpoint.
WCF service (class) is directly mapped to wsdl:service element which exposes each contract as separate wsdl:port (in WCF known as endpoint). This is the main point in answering your question. If you don't want your second contract in that wsdl:service you can't implement it in the same class.
You have mentioned that your service contracts share resources. In that case your WCF service probably also contains business logic. That is a reason for your problems. The good design for implementing WCF services is to create them only as wrappers around separate business logic classes.
Is sharing a project containing the wcf interface and datacontracts and using these via ChannelFactory to consume the service against SOA principles?
My architect is advising that generating a proxy using Add Service Reference is preferable.
I guess that depends on a some things: your infrastructure, security policies, governance, etc.
We design our WSDLs (service and message contracts) and XML Schemas (data contracts) and then use svcutil.exe* to generate a proxy. At that point, we have code we can either use to consume or stand up a service. Of course, I am just talking about the code, the output.config will be modified with proper behaviors, bindings and endpoints as those are decided.
Once the service is stood up, it's fronted by an XML gateway. At which point we can begin testing the services using the 'Add Service Reference...'. If you're just looking to save some time and hand someone else your pre-generated proxy or your WSDLs aren't exposed (as they're behind an XML gateway that does not echo them), then what you're doing seems fine.
Otherwise, I'd expect consumers to be able to 'Add Service Reference...' and generate their own clients.
*Java-based applications use something else (WSDL2Java/ClientGen/built-in IDE tool).
Sharing pre-packaged service interfaces along with datacontracts isn't against SOA principles as long as consuming services are not expected to use it. This is exactly what enables potential clients to speed-up development against an existing 3rd-party service, or begin development against one which is yet to be built. Providing interfaces/datacontracts in code format will be less ambiguous than describing these things via documentation only (of course they may not be useful if the client is using a different programming language).
However, if some sort of pre-packaged implementation of the service interface is provided in the shared package, and this implementation is required to be used to successfully use the service, then this would be against SOA principles unless an implementation was written for all types of clients. Being pragmatic though, this can be a good idea so the clients can be more loosely coupled against things such as transport choice, service contract changes and service versioning.
I would recommend using the ChannelFactory (from a dotnet client of course) whether consuming the services via a shared pre-packaged interfaces/datacontracts project or dll, or generating your own proxy (via 'Add Service Reference' or 'svcutil.exe'). This will allow you to code against the service interface and therefore your client will be much more friendly to using concepts such as dependency injection for stubbing, testing, etc.
Both methods of generating a proxy are valid, it depends on how much control you wish to have over the proxy, and if you own both sides of the code. A third option also exists, you can hand craft your own proxy. Let me explain further:
In SOA we pass messages, this is a different paradigm to passing pointers to objects on a heap/stack which is the norm in OO world.
Thus in SOA, the contract (what you can do) and the message (the state to act upon) are important and need to be shared with the consumers of the service so they can all agree on the contract or "rules of engagement" here we have the most basic form of SOA.
Enter WS-* a set of specifications for adding more functionality to our service call (distributed transactions, security etc...) but if we do this we all need to agree on the rules and the flavor of the type of interaction we intend to use, so the service and its clients need to agree exactly on how this is to occur so it to needs to be shared.
The combination of the contract definitions and WS-* specifications is called a WSDL and this typically is what get shared between clients and services, this is in line with the SOA tenants that we share schema and contract, not class, and that Compatibility is based on policy (WS-*).
So if you use channel factory you generate the proxy based on the interface definition you have and the config you have set up on the fly, if you use add service reference you let the IDE generate a proxy class based on the WSDL of the service as it exists then.
If you hand craft the proxy, you have full control over how this happens and you can jump into the interception chain and do things on the client side to manipulate the call.
Depends on what you want to do.
The standards we have carefully considered and adopted at my company, are that we distribute service contracts is two ways. As a shared assembly when delivered to teams within the company, and as a WSDL when providing to clients and other third parties. It is a standard we discussed with Microsoft during a design / process review and they agreed was the correct approach.