I'm trying to implement a WCF Service in my program , howevery I don't understand something:
According to the book "Programming WCF Services" , Juval Löwy 2007 O'Reilly Media,.
Appendix C. - WCF Coding Standard C2 - Essential :
1. Place service code in a class library and not in any hosting EXE.
I don't understand this, where should I put my code? all my class are defined in my form application , How should I call my classes of the winforms from the Class Library of the service.
Am I missing here something??
Thanks,
Eyal
I like to structure my WCF solutions like this:
YourProject.Contracts (class library)
Contains all the service, operations, fault, and data contracts. Can be shared between server and client in a pure .NET-to-.NET scenario
YourProject.Service (class library)
Contains the code to implement the services, and any support/helper methods needed to achieve this. Nothing else.
YourProject.ServiceHost (optional - can be Winforms, Console App, NT Service)
Contains service host(s) for debugging/testing, or possibly also for production.
This basically gives me the server-side of things.
On the client side:
YourClient.ClientProxies (class library)
I like to package my client proxies into a separate class library, so that they can be reused by multiple actual client apps. This can be done using svcutil or "Add Service Reference" and manually tweaking the resulting horrible app.config's, or by doing manual implementation of client proxies (when sharing the contracts assembly) using ClientBase<T> or ChannelFactory<T> constructs.
1-n actual clients (any type of app)
Will typically only reference the client proxies assembly, or maybe the contracts assembly, too, if it's being shared. This can be ASP.NET, WPF, Winforms, console app, other services - you name it.
That way; I have a nice and clean layout, I use it consistently over and over again, and I really think this has made my code cleaner and easier to maintain.
This was inspired by Miguel Castro's Extreme WCF screen cast on DotNet Rocks TV with Carl Franklin - highly recommended screen cast !
Yes, it's a bit confusing.
We're talking about the service implementation here. What Loewy means here is that the code to implement the service should be in a separate project. The code that hosts the WCF service (i.e. the class that implements your service contract) should do nothing but call that service implementation code.
So your Windows Forms client application uses a proxy, which in turn calls the WCF service application hosting layer, which in turn calls your service logic.
It's a very good idea to go further and have three layers on the UI side and four on the service side. The namespaces might be
Company.Project.UI.WinForms
Company.Project.UI
Company.Project.ServiceClient
Company.Project.ServiceHost
Company.Project.Service
Company.Project.BusinessLogic
Company.Project.Persistence
For simpler projects this would be overkill, but for anything more than (say) one form or two service methods it will make life much easier. Not least, testing each layer in isolation should be fairly straightforward.
Here's a typical project structure following Löwy's recommendation:
MyProject.Data
MyProject.Logic
MyProject.Services
MyProject.ServiceHosts
MyProject.Presentation
Then MyProject.ServiceHosts will reference MyProject.Services and exposes the services defined there. So in Löwy's language, MyProject.Services is the class library, and MyProject.ServiceHosts contains the hosting executable.
Related
We are developing multiple web services in C# using WCF, but we´re new doing it.
So, for what we have read and learnt, this is our approach:
We have a class library that we called CommonLibrary that has a few classes that are going to be used on all our services (language stuff, type of user connected and a common object that all the services are meant to return).
We have another class library called SecurityLibrary which validates the user that is consuming the method.
At the moment we have 2 services that are almost at 90% finished, both of them use CommonLibrary and SecurityLibrary.
Now the questions:
Is this a bad approach?
Are we violating the SOA principles of encapsulation and autonomy by using common/shared library with each of our services?
A third person told us to copy all the code of those libraries on each of our services so we have a 100% autonomous service, is this the right way? I think is hard for maintenance and shows a lot of duplicity. Any update made on one has to be replicated or merged on those other services...
No, it is not a bad approach?
If using libaries in your service, you should also keep away from the .NET-library. I am wonding why you are thinking that a service process is only allowed to exist of only one assembly.
Furthermore, copy-paste code is a very, very bad habbit. It is known as a anti-design-pattern. I duplicates the maintainance and also all the bugs inside it.
Sharing libaries does not make your service less "autonomous". I think it could make them more compatible if they are sharing types.
A good service is just a process, existing of one or more (shared) assemblies, with a well defined service contract. This service contract is never allowed to be broken.
BTW: In my answer I did not include problems which shared assemblies in the GAC. That is a feature or problem shared by all processes, not only services.
We currently have an application (Client/Server) that communicates through WCF. We would like to move away from the WCF approach and use a REST approach instead.
There are a few reasons for this, such as overhead (in terms of size) and the possibility to use the same access method for both our Windows client (currently a WinForm client) and mobile devices.
We are also sometimes running the server on the Mono framework, and even though we have it up and running, we have seen some differences regarding how WCF is working on the Mono stack compared to the .NET Framework (so I would not like to use the WebHTTPBinding in WCF to handle REST).
The service also needs to be self-hosted (i.e. not in IIS).
The problem when shifting from WCF to other alternatives is related to contracts. I would like to make it possible to unit test the REST calls, and I would like a contract to be involved, enabling the clients to use proxy classes that they do not have to create by themselves - pretty much like WSDL.
The main idea for handing out proxy classes to developers is that the clients should be able to rely on the service provider to get the correct proxy classes and that they should not need to care about the URLs used.
Is there any way this could be done automatically, and if so - using what framework or method?
Having looked brifely at WebAPI, I came across an example of generating a proxy (http://www.codeproject.com/Tips/535260/Proxy-Object-Generation-for-MVC-and-WebAPI-Control). This would simplify for the developers, but would mean that I manually need to create the proxy for the developers to use.
Any suggestions would be appreciated :)
For Client side unit tests, you should create mock for your rest service responses.
Otherwise You can create a static mock page with all of your service responses.
I have been asked to work on a project, based on SOA, using WCF. I have dabbled with WCF (Creating and consuming), but never with SOA. Am I right in saying that a single service would have the usual service layer, business layer and data access layer (if one's needed). The service layer would then expose methods.
Can Service A reference Service B, and service B reference service A?
And then a UI can access these services, via references - and that's essentially SOA? I am battling to find up to date, recent tutorials (Youtube), and the 'guides' I see online seem extremely complicated.
This Wikipedia entry is pretty clear I think?
Lets try a simple example. Say we have Library application that lets you check books in and out.
If you look at the "traditional" non-SOA way to approach n-tier systems then you have a service called MyService that has methods called something like CheckOutBook. This would go away and internally have a Book class and a Person class and would perform say Book.IsAvailable = False and Person.NumberOfBooks.
That is fine, but say you now have another application that wants to work with People. You can't just use the above service because the logic is tightly coupled with what you are doing, i.e. Library transactions. Instead you would have to copy / paste code into a new service "BookShop".
With SOA you would have a Book service and a Person service. The Person service would have an action such as Person.AssociateWithBook that both Library and BookShop could use without having to alter as it is simple enough to do the minimum. It is then down to the application to call the right service(s) to do the job required. This means that it is reusable without needing to modify the various services.
This is very simplistic but hopefully shows the architectural differences and get you going?
I'd skip question about SOA, since each one can call SOA whatever he understand SOA (Service Oriented Architecture) is. I mean, each architecture, using services, can be called SOA...
From technical aspect, I'd build it in next way:
IMO, Services by themselves should have as less logic as they can (like facade pattern), all there logic should be moved down to Business logic.
Service A using ServiceA.BusinessLogic, calls service B (proxy for service B is available for ServiceA.BL).
Same for Service B, calling service A.
This will give you bi-directional communication, without issues of Duplex (broken callbacks, ...).
UI should access the services as well - using UI.BusinessLogic ( I usually prefer think about service communication as sort of Communication Data Access Layer).
I have tried googling for an answer since last week and haven't found anything. Maybe I'm just searching with incorrect key words...
Basically, we have a running WCF service and then we have a separate dll with another ServiceContract in it. We want to know if it is possible to expose the separate dll in the current running service and if one can, how?
We are still new to WCF, so please excuse if this is a stupid question. :(
We are working with .NET 3.5 SP1 and C#.
Regards
EDIT:
We want to separate our service into "modules". So the service implementations (Methods, ect) and contracts (Interfaces) are all in separate libraries. So lets say you have a module called "Clients". We want everything related to Clients to be in the same separate library (DLL) instead of one big base class that inherits from multiple interfaces. This is a huge service and we need multiple developers to work on different sections of the same service at the same time. This is what I've been instructed to figure out, but if it can be done then it can't. I hope this makes more sens??
Assuming you are asking how you can implement a service contract declared in one DLL in a service running in a separate DLL/Application:
Edits to match post edits
add a reference to the DLL with the service contract to the application containing the service
In the .cs file with service implmentation add a using statement for the namespace of the service contract
derive the service from the service contract (you will have problems if you define your service contracts as concrete classes rather than interfaces and you want to expose multiple contracts on your service
If self hosting then create a ServiceHost passing the type object of the service in the other assembly, if IIS hosting create an .svc file referencing the class in the other assembly as the service
Add a service element in the config file naming the fully qualified name of the service
Add an endpoint to the service at a unique address for the new contract
When you take the other assembly (dll) as a reference in the "main" project, then add a using directive to the file where the WCF service is instantiated. Then you can simply use the referenced service contract to set up a running service with the right endpoints and binding(configuration).
I guess one work around is you have a main ServiceHost hosting your WCFMainLib and then all your clients will connect to WCFMainLib.
WCFMainLib then acts like a proxy to connect to all other WCFModuleLib on localhost (or other servers) to fetch data.
WCFMainlib will implement the IWCFModuleLib1, IWCFModuleLib2 etc service contract interfaces and expose them to the WCFClient. Actual implementation of interfaces will then be a call to the actual WCFModuleLibs.
This may introduce some overhead, but overall also introduces several "features" that may benefit your boss or service availability.
OR, if you are just wanting to delegate programming work, maybe you can tell each team to work with partial classes for your WCFLib with each service contract on a partial class then do a nightly compile.
Do you use auto-generated WCF service references in line of business applications? Or do you roll your own? And why?
EDIT
For anyone looking to roll their own, I found this article which may prove useful: Understanding WCF Services in Silverlight 2. There's another article on the site for Silverlight 3 which may be a useful addition: Understanding WCF Faults in Silverlight 3.
I typically roll my own, or tweak the ones generated by the auto-generated wizard.
I have two scenarios, most of the time:
I control both ends of the wire - in that case, I share the assembly with the service and data contracts between the service and client, and in that case, I write my own clients from scratch, as ClientBase<T> descendants or using a ChannelFactory<T>. Unfortunately, this is not an option with a Silverlight client, as far as I know :-(
I get WSDL+XSD from a third party - in that case, I typically use svcutil.exe to generate a first version of the client proxy, and then I tweak that to suit my needs (especially the configs generated by svcutil or VS "Add Service Reference" are horrendously bad.....)
I just like to have that extra control of doing it myself and totally knowing what's going on.
I haven't had to use Silverlight to access a service I didn't control, but in accessing a WCF service that I do control, yeah, I use the standard auto-generated WCF references. Rolling my own would just be too painful when the service is changing regularly.
If you control both ends of the service, you should also strongly investigate RIA Services, which implements a much more elegant way of keeping your Siverlight client in sync with your WCF service than having to manually regenerating your service references each time the interface changes.