I work in a company that is only using WCF and i am trying to introduce service stack. Now i understand we are better off using the service stackclients that wcf clients but for some of our stuff and to keep people happy that will not always be possible. Can anyone provide a basic example of a ServiceStack service that can be added as a client into a VS2012 project using the add service reference inside visual studio as you normally do for a WCF service? Basically is there a way to make ServiceStack seem like a WCF service to people that don't know about ServiceStack?
If i can show this i think i can convince my company to make the switch but if not it will be difficult as everything else is WCF based. We are already using the ServiceStack clients to hook into other online websites so it seems a good time to try to convince them to move to the service stack services and clients as long as they feel they can fall back to the WCF client if needed.
Provided you adhere to the SOAP guidelines and limitations in ServiceStack you should be able to add a Service Reference by pointing the client to the ServiceStack wsdl at /soap12, e.g:
http://servicestackbaseurl/soap12
You can also find a link to the soap 1.1/1.2 wsdl (and XSDs) on ServiceStack's /metadata page.
Related
I want to create a restful web service that can accept json and returns json responses on a Windows server written in C#.
This particular service will actually have a long running background thread, so a WCF service hosted in IIS won't work (as far as I can tell, IIS will stop and restart the service on/after each request).
In general, I do not really even like WCF since I don't like dealing with generating proxy classes and updating service references down the road.
How can I accomplish this?
Well, with respect to WCF, is a technology already proven to help you build robust services, during your software design process you can design the service to keep state, hosting singleton instance, etc, so your impression of WCF services are somehow incomplete.
Now, regarding the restful approach, the technology used nowadays is called Web API, you can see some examples in the following website : http://www.asp.net/web-api , this will help you to avoid the tipical WSDL and generating proxies that you are talking about, and you can have bare-metal RESTful queries like "(http://myapp/orders/?id=1) that could return a json object with the orderid=1
Here you can have info for the instantiating mode in WCF services: http://msdn.microsoft.com/en-us/magazine/cc163590.aspx
hope it helps,
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 am starting a new webservice project which will be consumed by multiple consumer applications done in different technology like ASP, ASP.Net and PHP. I am planning to develop this service as a WCF service. I am new to WCF and I understand WCF is like umbrella tech which has all the features for developing a distributed SOA applications.
I would like to get your advice on whether my choice of opting WCF service over classic asmx service is correct. The consumer applications are existing application done different technologies as I said before. This service is a simple service that creates and updates user information in a centralized DB.
If my decision of choosing WCF is correct, then please let me know if there are any specific things I need to consider so that the existing application can consume my WCF service without any hiccups. In other words, I can provide a asmx service for this which they can consume directly without any issues (and currently they are consuming some of our asmx service. Since the current requirement is new I want it to be done with WCF). Likewise, the consumer should be able to consume my service like they consume asmx service.
I am asking this question because WCF provides additional features like security, etc. and hence the consumers should also follow the practice to communicate with the service.
Any advice is highly appreciated.
You probably want to use BasicHttpBinding in your WCF service and, although I'm not a PHP developer, I understand that PHP 5 has a SOAP library that can be used to create a service proxy based on the WSDL document exposed by the WCF service, assuming metadata exchange is enabled.
I am going to need a web service that receives a string via HTTP POST and processes it without any response to the client. However, since I'm not the one making the client (which will be cell phones) I am unable to use a generated client class to consume the service. The service would also need to be self hosted in a regular Windows service, if that matters.
As I'm not too experienced with web services nor WCF, I am frankly unsure if I can or should use WCF for this, but as it's the only type of web service I'm at least a little familiar with I figured it would be great to start out with one if at all possible.
I've been googling around quite a bit but haven't been able to find any good references to this, so I'd also be very grateful if someone has a link lying around to someplace that discusses it.
I think you need WCF Restful service with one way operation. Following link might help you:
A Developer's Guide to the WCF REST Starter Kit,
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.