I have been evaluating and working on a prototype where I have exposed couple of API using WCF web service. My service is working as expected with managed client in windows platform. My service client can be on any platform. I dont know how to approach for other platform (UNIX). Couple of options I have considered so far -
GSOAP
MONO dotnet
I could not use any one of these due to some constraints. Now the only option I left out to implement my own client which can send soap request and get soap response. My preferred technology is C/C++. I am using wsHttpBinding in my server and will be working on http protocol only.
I am not sure about the following points-
Do I need to implement my own WSDL parser?
Do I need my own serializer?
How could I make my client more flexible so that any changes in my WSDL make minimal code changes on client side?
I am looking for help from the experts who could guide me with a proper approach with a basic client sample.
My experience is in WCF interoperability with Java clients. You can use Java SOAP libraries like metro http://metro.java.net/ or axis http://axis.apache.org/axis2/java/core/index.html . There is even a C library for axis. http://axis.apache.org/axis2/c/core/
I am sure other languages like Ruby/Python etc has similar libraries as well.
The other option is to use a REST based interface and then you can use any language/platform that has HTTP support or even a tool like curl and libcurl http://curl.haxx.se/.
Related
I know, there are 1000x topics about WCF and security - seems to be a hot topic. I still want to get some up-to-date opinions about this.
I am creating a Webservice (free to use) where clients can register on my website, get a secure token, and can consume the webservice with this token. Consuming the webservice must be very simple independent from what language the client is using (PHP,Java,.NET).
Also I need to have one webservice-call exposed for use in Windows Phone 7.1, Android, iOS.
I've currently implemented the Service in WCF using wsHttpBinding and TransportWithMessageCredential security. Now I have already compatibilty issues trying to consume with WP7...
What, in your opinion would be the best Webservice/Security Framework for my needs?
* REST
* SOAP (With SoapHeaderAuthentication)
* etc...
Any feedback highly appreciated!
Thanks!
If it has to be consumed easily by different frameworks and devices, I would build a Rest service. Take a look at ASP.NET Web API.
You can use Web Api to return Json, which can be easily consumed by Windows Phone 7 apps, Java, php, whatever. You have the possibility to implement https and authentication.
Keep in mind that it's still in a Beta stage and that you'll have some issues accessing it cross domain, but it's a problem that can be overcome. I guess this will be made easy before it hits RTM.
Rest is easier with interoperability. If you do use soap then basicHttpBinding is much better than wsHttpBinding since the latter has some proprietary protocols.
i'm about to begin a WP7 project. i currently have a WCF REST service deployed on my LIVE servers, and my Android and iPhone clients are happily consuming this. how do i get my WP7 to communicate with my REST service? The server side is working fine and well, and there is no issue there.
what i thought i would be able to do was simply add my client library (compiled in SL) with all the interfaces, datacontracts etc, create a ChannelFactory, ensure the web behavior was on in the client and yay! away we go. this doesn't seem to be the case however. certainly i can't use the interface created because of the WebGetAttribute reference :S
what is the reccomended way? i would prefer to consume my service in the same way as the other services do for consistency, so i don't want to make new (and more verbose communication) bindings and simply expose the same service over a different endpoint. similarly using WebClient / WebHttpRequest just seems a bit backward: certainly we don't have to parse the response for the other types of bindings available, why would we for this?
any suggestions? basically i want to write as little code as possible to connect the client and the server (ideally as much as normal WCF communication would take) and would prefer to communicate with a channel, since there'd be no parsing or deserializing the JSON response on my behalf.
surely this is possible? most people working on mobile applications have chosen a REST service to communicate with, seems a bit odd that microsoft's mobile solution wouldn't neatly integrate with its own server side solution! i really hope i'm just stupid and have missed something quite glaring.
I believe at this point RESTSharp is your best option.
Another REST Client library: Spring.Rest
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.
A business partner has suggested building a web services library with JSON-RPC rather that SOAP. (note they are not building in .NET necessarily, but I am)
I am a potential consumer of this data.
I've used JSON for client-based Ajax calls in the past, but this web services library will be used primarily for server-side calls and syncing large amounts of data.
I don't have much experience with JSON-RPC.
Questions:
Can I easily build a JSON-RPC
consumer in .NET?
Are JSON-RPC web services self
documenting and discoverable, like a
SOAP WSDL?
Can I easily add a Web Reference in
Visual Studio to a JSON-RPC web service?
Thanks
Can I easily build a JSON-RPC consumer
in .NET?
Yes. JSON-RPC services are simple to consume as long as you have a robust JSON parser or formatter. Jayrock provides a simple client implementation JsonRpcClicnet that you can use to build a consumer. There is also a small demo sample included.
Are JSON-RPC web services self
documenting and discoverable, like a
SOAP WSDL?
No, there is nothing standardized but there are ideas being floated around like Service Mapping Description Proposal.
Can I easily add a Web Reference in
Visual Studio to a JSON-RPC web
service?
This can work if the server-side implementation provides a WSDL-based description of the JSON-RPC service but none are known to provide this to date.
Check out Jayrock.
Jayrock is a modest and an open source
(LGPL) implementation of JSON and
JSON-RPC for the Microsoft .NET
Framework, including ASP.NET. What can
you do with Jayrock? In a few words,
Jayrock allows clients, typically
JavaScript in web pages, to be able to
call into server-side methods using
JSON as the wire format and JSON-RPC
as the procedure invocation protocol.
The methods can be called
synchronously or asynchronously.
Can I easily build a JSON-RPC consumer in .NET?
Shouldn't be difficult as long as you know what you're doing.
Are JSON-RPC web services self documenting and discoverable, like a SOAP WSDL?
Discoverable yes, documenting in as much as you can get function names and parameter lists. (not entirely sure what you're asking for as far as documentation goes).
Can I easily add a Web Reference in Visual Studio to a JSON-RPC web service?
I don't think so, no. (Though, I have no idea, it's possible. My experience with JSON-RPC is in PHP/JS mostly)
Relevant links:
http://json-rpc.org/wiki/specification
http://json.org/
http://techblog.procurios.nl/k/618/news/view/14605/14863/How-do-I-write-my-own-parser-for-JSON.html
Maybe you could have a look at json-wsp which is much like json-rpc but with a discription specification. It is implemented as an interface in Ladon for python.
http://pypi.python.org/pypi/ladon
I have some sample Json-Rpc 2.0 clients for .net and windows phone 7 in the Json-RPC.NET sources.
Check them out: .Net Client and WP7 Client
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.