I have a Windows Service which performs a certain function, and then needs to send that information off to a webservice for processing. The webservice is hosted by a remote web application. I am trying to ascertain the best way to call the webservice(s) as each web application might be only 2.0, or 3.5 etc. In my windows service, I am defining each "client" in the app.config, e.g.
<Client WebServiceUrl="http://location.com/webservice.svc" Username="" Password="">
</Client>
The web application must implement two web services that are required for my windows service to run, however not sure the best way to implement the "rules" for the web application.
EDIT:
I'll try and rephrase..
The Windows Service runs every 30 seconds and obtains a list of information. The service supports multiple "clients" as shown above. When each client process is run, the data is collected and is then needed to be sent to the supporting web application.
The windows service does not know what to do with the data, it is just sending it. Each web application for a client would be in different locations, and could possibly be built in 2.0, 3.5, PHP, etc. All the windows service cares about, is that when it performs its processing for a client, it is able to send the data to the webservice location defined in the app.config of the windows service.
What I'm trying to determine is how to connect to the webservice (which I'm leaning towards WCF, however Basic or WS not sure), and what rules need to be defined for the web application in how to build the response.
If the Windows service is to support php applications etc, WSHttpBinding would not be an option, which would mean BasicHttpBinding would then work. The other thing to decide is whether or not to utilise a RESTful service or SOAP service.
Hope this makes more sense.
I'm not really clear on what you are doing.
It seems like you have 3 things: A Windows Service, and then a web service, hosted in a web app.
I think your question is, what to use, REST, ASMX, WSE or WCF, when interconnecting the Windows Service app with the remote web service.
ASMX, WSE and WCF are alternative programming models for the web service. REST is not a programming model. It is not like the other three.
ASMX and WSE will require that you use Web services and SOAP.
WCF can allow you to use Web services and SOAP, REST (XML or JSON) over HTTP, or a binary format over TCP, among other options.
Because it is flexible and current technology, I'd recommend WCF. ASMX is now termed "legacy technology" by Microsoft. Doesn't mean it won't work, but it will not get updates. (Much like WinForms versus WPF). WSE is no longer in mainstream support, as far as I know. For these reasons, I wouldn't recommend starting a new project on WSE, nor on ASMX.
WCF is more general than ASMX and can seem more complicated, for that reason. But once you make some choices and zero in on what you want (for example choose HTTP and REST, or choose binary and TCP), it's more powerful. WCF can be used as the programming model on both the client or sender (in your case, the Windows Service, I guess) and/or on the server (the web service hosted in the web app).
Using WCF on the client side does not imply you must use it on the server side, and vice versa. On the other hand, if you control the source code on both ends, I would recommend using WCF on both sides.
As for "how to implement the rules for the web app" - I don't understand what you are asking there. Maybe if you are more specific on the question there, someone will be able to help out.
Update: Based on your additional explanation, I'm going to suggest you look at the REST stuff in WCF for .NET 3.5. In PHP it's very easy to implement a REST-style service, and with WCF, the same is true for .NET. Now in your case the Windows service is the client and it is sending out a request, an update request, to various servers that reside on your customers' networks. According to REST principles, I'd make those outbound requests PUTs or POSTs, depending on the semantics of the call.
Then you could ship some example service code to your (uppercase) Clients, to get them started on building what they need to receive your outbound PUT/POST messages.
Security is a concern though. You didn't mention it at all, which is surprising. Security is not one of those things best deferred, so that you "add it on later". You should think about it early - it may affect the protocol choices you make. For example, if you need to mutually authenticate the clients and servers (the latter at your "uppercase" Clients' networks), then you may want to go with SOAP, which gives you good options on the protocol side for security. Secure Web services extensions (WS-Sec, etc) are well supported in WCF, but not sure about the status of this capability in PHP.
Related
I've been looking into WebAPI and really like what I see.
Is there are reason why NOT to use WebAPI? If so, in what scenario?
I initially thought in a cross-platform SOA architecture, WebAPI might fall short, but the more articles I read, the more I realise that WebAPI might beat WCF in almost every realistic scenario. It looks like you can use WebAPI for android, ios etc. and not just for .Net; even performance shows WCF REST to be slowest. http://weblog.west-wind.com/posts/2012/Sep/04/ASPNET-Frameworks-and-Raw-Throughput-Performance
Is there still an "obivous" reason where WCF is better?
Whenever you control the both the consumer and provider endpoints (for example back-end service-to-service communication) you should use WCF (or Sockets) for capabilities and performance. Hosting the service via WCF and then sharing binary contracts means 100% guaranteed matching, compiler-checked and type-safe (de)serialization between client and server.
If you also have full CI you all but eliminate the risk of releasing binaries with mismatched contracts. Web API serialization is more forgiving, and thus verification and testing is more involved (client can send data server does not expect, server can send data client does not expect.) WCF also supports contract versioning and extended data, this allows intermediary services that only know V1 contract can still accept and forward to a V2 or later message while preserving all data for services which understand V2 or later contracts!)
WebAPI is mainly for implementing HTTP-based services with minimal frustration, as such, WebAPI relies heavily on the asp.net HTTP Web Stack to function (whereas WCF and its underpinning's do not, matter of factly, some WebAPI features rely directly on WCF.. for example, exposing OData feeds via WebAPI.)
Similar to Web API endpoints, WCF endpoints can be configured to provide access via HTTP as necessary (among other protocols and technologies such as Secure Named Pipes, MSMQ, UDP, TCP, etc.) WCF is also extensible, and out of the box it provides transport implementations for duplex, bidirectional and reliable messaging, it provides both Transport-level and Message-level authentication using Tokens, Certificates, basic Authentication Credentials and more. There is additional support for service discovery, subscription, broadcasting, etc. (Admittedly, WebAPI provides some overlap, but not with the same level of control.)
Not only does WCF support all this, it is highly configurable allowing you to mix and match between MOST of the available transport, formatting/serialization, security, instancing, lifetime and other service settings through configuration files and code.
Moved two of your middle tiers together into same machine now? Switch to a named pipe. Swapping a server from .net to PHP? No problem, change binding config from using net.tcp to use soap. Where WebAPI stops, WCF continues.
However, as with any technology, WCF only shines as well as your developer's understanding of networking and infrastructure. Put in the hands of the mediocre or unwilling and you will get a complete mess that fails to perform. WebAPI is a little bit more fool proof, even beginner programmers can put it to use within minutes, and generally succeed at their task doing so.
2c
I need to create a web service to collect data from my customer’s applications.
Those applications are programmed with different technologies and they all have one thing in common: they can consume plain SOAP Web Service.
I already have a WCF Service that could be exposed but as it was built for internal purpose only, I never had to secure it.
I did read a lot of articles on how to secure WCF service and how to consume it from a Microsoft client application. However, I'm really concern about the customer’s non-microsoft applications abilities to implement a standard WCF Service security. I must keep in mind that some of them might be stateless and unable to hold on to a session or anything that might be required by a secure WCF Service.
So here are the options I have right now.
1) Add username/password parameters to each WCF function and perform a credential check on every call. (I do have an SSL certificate... is it enough to consider this option as secured?)
2) Drop my WCF Service and create a plain SOAP Web Service with username/password parameters as mentioned in option #1 to be closer to my customer’s applications capabilities.
3) Implement standard WCF security and let the customers find a way to deal with it on their own. (The real question here: is WCF security simple enough to be implemented by any SOAP client?)
4) Change my name and move to Jamaica with my customer’s money before they find out that I’m a Web Service security noob.
5) Something else…
So what is the my best option here?
Yes, I can offer the option we use. It sounds like you want basicHttpBinding.
We have a WCF web service using basicHttpBinding and set IIS to use basic http authentication.
Therefore non-.NET clients can consume it easily (basicHttpBinding) and we can give them an Active Directory domain account that allows them access via IIS. No usernames / passwords to constantly send back and forth through the web service and it runs over HTTPS for security.
It's currently being consumed by PHP, Java and .NET clients. Yes, .NET clients can still import this as a service reference which makes thing like trapping FaultExceptions easier.
No solution is perfect for everyone but works great for our needs.
Yes, but certain configurations favour certain vendors. See the WCF Express Interop Bindings project on CodePlex:
http://wcf.codeplex.com/wikipage?title=WCF%20Express%20Interop%20Bindings
They offer settings for interop with:
Oracle WebLogic
Oracle Metro
IBM WebSphere
Apache Axis2
The Oracle Metro (previously known as SUN WSIT) stack is by far the most advanced as regards the WS-*/Oasis standards.
I have a web service that is used by many different clients using many different languages.
I want to switch it to wcf to take advantage of the many different endpoints.
However what has been stopping me is that I am afraid that the clients will have to use a special sdk to connect (if they are using java or php or some other language) that is different then the sdk they use to connect to the existing web service.
Is this true? Or is connecting to WCF the exact same as it is for web services in other languages.
The project I am currently working on has multiple WCF configurations, some are using the default SOAP implementation, and some are using a POX (plain-old-xml) style message.
So the short answer is 'yes' you can configure WCF in such a way to work with just about anything.
However, be warned that as soon as you step outside the default little box that WCF has set up for you, it gets pretty complicated. You end up with a lot of custom message parsing and security handling if you go to a POX message format. Its easier if you stick with SOAP though.
As for needing a 'special SDK' you won't. You can communicate with WCF with simple HTTP POST messages if needed.
I have clients that are using VB.NET apps (using SOAP) and Java apps (using POX) to hit my WCF services.
A basicHttpBinding endpoint in WCF is exactly a standard SOAP endpoint, and your Java or PHP clients will not have to change in any way.
I am learning wcf but I have trouble understanding the benefits. Is there ever a time I would want to use traditional web services?
I read another thread with these benefits:
Opt in model for members using a certain attribute
Better security
No need to worry about binding (can't understand how this is true)
No need to worry about the xml
I read Programming WCF Services however this was an advanced book a bit like CLR via C#. I am now reading Learning WCF Services and will read Essential WCF (is recommended).
What would happen if I use a normal class to try to talk to a web/service reference? I know this sounds really naive, it's just my lack of experience in web services.
I am coding some WCF services so I am getting exposed to the specifics. They are interacting with a SOAP web service provided by my web host so I can get stats on my site. Is there anything wrong in this approach?
Thanks
WCF is a unified programming model for developing connected systems. What this means is that you use a single framework to develop service-oriented solutions. WCF allows you to keep your service implementation relatively unaware and care free of what's going on under the covers as far as how your service is consumed by clients and communication is handled. This allows you to take your service implementation and expose it in various ways by configuring it differently without touching your service implementation. This is the unified part. Without WCF, you have to get familiar with a framework specific for a particular communication technology such as ASP.NET asmx web service, .NET remoting, MSMQ etc and usually those frameworks impose on your service implementation and creep in such as using WebMethod attribute or having to derive from MarshallByRefObject object etc and you just can not take your service implementation and easily expose it over another communication stack. If I have a service that adds two numbers, why can it not be exposed over http or tcp easily without having to worry about low level details? This is the question in your post regarding binding. Binding allows you take a service and configure it so that it can be exposed over different transports and protocols using different encodings without ever touching your service implementation.
Is there ever a time I would want to use traditional web service?
Web service uses well defined, accepted, and used standards such as HTTP and SOAP. So if you want your service to be consumed by wide range of clients, then you would want to expose your service as a web service. WCF comes with pre-configured bindings out of the box that allows your service to be exposed as a web service easily: basicHttpBinding and wsHttpBinding. You may also want to consider RESTful services which is an architectural style that fits more natural with the HTTP model. WCF supports RESTful services as well
What would happen if I use a normal
class to try to talk to a web/service
reference? I know this sounds really
naive, it's just my lack of experience
in web services.
WCF service can expose the wsdl for a service just like ASP.NET asmx web service does. You can generate a client side proxy by simply adding a service reference to your client project. There is also a command line tool called svcutil that also generates the client side code that allows you to easily communicate with the service. The client side service class basically mirrors the service interface. You create an instance of the client side proxy for the service and then simply call methods on it just like any other .NET object. Under the covers, your method call will get converted to a message and sent over the wire to the server. On the server side, that message will get dispatched to the appropriate service method.
I hope this helps a bit.There are lots of online content such as videos on MSDN and channel 9 that you check out. The more you pound on it and expose yourself to it, the clearer WCF will get I am sure. Also, WCF is THE framework Microsoft recommends to develop connected system in .NET. The other technologies ASP.NET asmx, WSE, and .NET Remoting will most likely still be available going forward but may not be supported and developed further.
There are a number of existing approaches to building distributed applications. These include Web services, .NET Remoting, Message Queuing and COM Services. Windows Communication Foundation unifies these into a single framework for building and consuming services.
Here is a link from MSDN Why Use Windows Communication Foundation?
WCF is really the "new" standard and new generation of web service - and even more generally, communications - protocols and libraries for the .NET world.
Whenever you feel the need to have two systems talk to one another - think WCF. Whether that'll be behind the corporate firewall in your company LAN, whether it's across the internet, by means of a direct call or a delayed message queueing system - WCF is your answer. Mehmet has written a really nice summary of how WCF is the unification of a great many communication standards that existed in the Microsoft world before WCF.
I would think with the "Learning WCF" book, you should be a lot better off than with Programming WCF - that's quite advanced stuff already!
One of the mainstays of WCF is the architecture that you always talk to your service through a proxy - whether that service runs on the same machine using NetNamedPipe binding or halfway around the world in Down Under on a server - no difference, you always go through a proxy. That then also allows WCF to be so extensible - thanks to the proxy always being between the client (your application) and the service, it offers excellent ways of extending the behavior and the inner workings of WCF to your liking and needs.
WCF basically builds on SOAP communications - so interfacing and using existing SOAP services should be no problem at all. With the WCF REST Starter Kit and in the upcoming .NET 4.0 release cycle, WCF will also extend its reach into the REST style web communications, if that's ever going to be a requirement of yours.
All this really shows one of the biggest strenghts of WCF: it's a unified and extremely flexible and extensible communication framework, that can handle just about anything you throw at it. That alone is more than enough reason to learn WCF (which can be dauting at first, I agree!), and you won't regret the effort you put into this endeavor.
Marc
Have you a specific application you are writing for, or just getting your feet wet?
Google protocol buffers, is a very good choice of communications. John Skeet & Marc Gravell have both done C# implementations. See here
I'm looking to understand when to use a WCF services instead of just using webclient or httpwebrequest. I guess I'm also looking to understand the difference between the design patterns that would be appropriate for both.
Are you talking about when to create a WCF service yourself (over web service), or when to consume an existing web service using WCF instead of .NET 2.0 ASMX clients?
As for creating a WCF service yourself:
Gives you a lot more options in terms of hosting (in an app, Windows Service, IIS, WAS)
Gives you a lot more security options
Gives you a lot more protocol options (besides just HTTP, you can also use WS-*, TCP, Named Pipes, MSMQ and more)
Allows you to write your service once, and expose it on multiple end-points with different protocols at the same time
As for using WCF to talk to an existing HTTP (ASMX) web service - I don't see a whole lot of massive benefits, except WCF uses more configuration over code, and it can be good to standardize on one way of doing things, if you already use other WCF services, anyway.
Marc
I'm currently using WCF for most of the things that I would use WebClient or HttpWebRequest/HttpWebResponse in the past. While there definitely is overhead for learing how to make calls to web methods using WCF, the extensibility of WCF and the abstraction it provides makes it a MUCH better candidate for these types of calls.
I've already used it to make calls to Akismet and RPX pretty easily.
To get started, I'd look at the section of the MSDN documentation titled "WCF Web Programming Object Model", located at:
http://msdn.microsoft.com/en-us/library/bb412204.aspx