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.
Related
Hi i would like your help so i can decide on what to do with this matter. The thing is that at my work we are currently migrating from Web Services to using WCF, now the thing is that when we used web services we had one web service that was in charge of invoking the business logic now the thing is that i would like to know what is actually the best way to achieve the same functionallity with WCF, using one unique service to call the different business logic classes or have multiple services to call the different business logic classes? also i have to clarify that when i say one unique service i mean that this will have just one method that one way or another will be capable of invoking any of the business logic classes depending on certain parameters and will also have other methods but for other different tasks, now i would like to know which would be the best approach for this, by the way the reason we have consider using one service like i told you is to manage from there the commits or rollbacks necessaries when something blows when making an operation on the db and have it just from one place, not all over the place, thanks in advance and well i'm kind of new with wcf.
You can migrate your existing service structure into WCF and still have the same functionality. You'll need to create and expose the service(s) according to WCF, but the architectural structure can remain how you have it in Web Services. You may want to revisit your design. There are many features at your disposal, including Entity Framework, that allow you to manage commits, rollbacks, etc.
I'm looking to create an Application Object Server that is sitting between Window form client and SQL 2008R2 Database, it handling application business rule and support CRUD, I have achive this with WCF and WCF dataservice in the past, It would be better if we can combine those two kind of WCFs into one.
Do you know any way to achive this? or we should go back to the WinSock day.
Awaiting for your thoughts
WCF Data Services are based on the REST-style WCF services (webHttpBinding) - so those are quite fundamentally different from the traditional SOAP-style WCF bindings.
I don't see how you could easily combine WCF Data Services with a traditional SOAP WCF service (assuming that's what you're trying to do).
What you could do is:
create an entity data model as basis for both services
create the WCF Data Service on top of that EDM
separately create a set of WCF SOAP service methods, based on the same EDM
But SOAP and REST are quite different, at a very basic level:
REST tends to work with resources - you have a Customer (also in your URL), and you can fetch it, edit it, update it, delete it
SOAP on the other hand tends to work more with operations - you have your customer, but then you expose methods like GetCustomer, UpdateCustomer etc. - your basic building blocks are methods that take parameters
I have an existing set of Services and Repositories I use in an MVC application that leverage the Entity Framework 4.1 Code First.
I want to create a couple of WCF Services that use the existing architecture, but it seems to have a hard time serializing the object graphs.
I realize that there are some circular references to deal with, but I really don't want to litter the Domain Objects with WCF attributes, so should I just create View Models like my MVC app uses? And if so, should I create the View Models to be able to be used in both?
Any other ideas? - Thanks!!
I prefer keeping my domain model and the WCF data contract separate by defining Data Transfer Object classes as the data contact of the WCF server. They are tailored specifically to carry the right data across the wire. A good DTO design will keep the number of WCF service call roundtrips from the client down. It will also separate your internal domain model from the contract with the client.
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.
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.