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
Related
I would like to use a technology that is used for communication between services and several thousands of clients. I came to know of WCF and read a little about it. While it looks attractive and has no interoperability issues, i would like to know about other leading technologies which can give me the same features as WCF ? Are there any open source technologies out there ? Also, which is the most widely used technology? I just want this information before i commit myself to WCF.
EDIT: By alternative to WCF, i mean to say that i am looking for a framework that will help me to implement a webservice in linux or any other platform. For example, the wcf simplifies the process of creating a webservice by the use of hard coded .NET applications. Similarly, i need a tool in linux. I came across mono,but found out that it is not complete and not very reliable.
I also provide an Open Source WCF alternative in ServiceStack A modern, code-first, DTO-driven, WCF replacement web services framework encouraging code and remote best-practices for creating DRY, high-perfomance, scalable REST web services.
There's no XML config, or code-gen and your one clean C# web service is enabled all JSON, XML, SOAP, JSV, CSV, HTML endpoints are enabled out-of-the-box. It includes generic sync/async service clients providing a fast, typed, client/server communication gateway end-to-end.
I don't think there is any .net framework with comparable features. But the core protocols of WCF such as WSDL/SOAP are not Microsoft specific so it's not as if you're tying yourself into a particular protocol, you're just choosing an implementation.
To put it another way if you choose to migrate away from .net in the future then I would say the WCF migration would be one of the easiest parts. But if you stay with .net WCF is almost certainly going to be the best implementation available given the investment Microsoft has in it (Azure is built on WCF for example).
I'm working on a project that will have two user interfaces. Web (asp.net MVC) and Desktop (Delphi 2010). It was requested by the customer, so we need to use Delphi.
We're thinking of architecture oriented by services, and so is WCF. To access WCF Services in Asp.Net MVC it is fine but what Need I do in Delphi? My principal doubt is, how to access a service in WCF using Delphi. Is there any way to make it easy?
Can my methods in service return IEnumerable or T[]?
Are there recommendations for this !?
Thanks!
The web services support in WCF provides many features which are not suported by Delphi - MTOM, WS-Addressing, WS-Reliable Messaging and WS-Security just to name a few. If you are designing both parts of the system (web service server and client(s)), you are in the happy situation that you can choose which features to use (as long as they are not dictated by other parties).
WCF fortunately does not 'dictate' to use SOAP. The Interoperability section in this Wikipedia article mentions for example WCF with standard XML (or RSS, or JSON). There is also a WCF binding for REST.
Planning a service oriented architecture is a tough task, so I highly recommend to read through the usual literature for this topic, and find a way to keep it as simple as possible and easy to test and evolve.
Maybe you can take a look at RemObjects SDK: it is a WCF-like solution, and you can use it for .Net, Delphi, Objective-C, PHP, C++, etc.
So you can build a server with RemObjects for .Net, for example TCP + Binary message for best performance (SOAP/XML is much slower!), and a Delphi 2010 client (even FreePascal is supported). Both sides (Delphi and .Net) are compatible with each other, even for the binary message!
My experience with RemObjects is very good: very easy to use and to build services (easier than WCF?), good support and quality etc.
One of the latest SOA framework for Delphi, is our Open Source mORMot framework.
You can use interface to define your Service contract, and access to them locally or remotely using named pipes, GDI messages, or TCP/HTTP. Your contract is defined as such on both client and server side, just like in WCF.
type
ICalculator = interface(IInvokable)
['{9A60C8ED-CEB2-4E09-87D4-4A16F496E5FE}']
function Add(n1,n2: integer): integer;
end;
It handles per-call, per-session, per-user or per-group instance live. See this sample code.
It is secure (with secure authentication at URI level), light and fast.
It uses JSON as communication (lighter than XML), and a RESTful access. It is ready to be consumed by AJAX or WCF clients (the latest after custom marshaling of the interfaces). It was optimized for speed and scalability (with advanced features like balanced custom hosting and per-interface/per-method access security).
The mORMot framework documentation has more than 800 pages, and some dedicated high-level explanation of Service Oriented Architecture design pattern in Delphi. It is integrated with a Client-Server ORM, so you have at hand all needed low-level tools to make a proper Domain-Driven application in Delphi, and other technologies.
I'm new to WCF RESTFull services developpment and I'm looking for some usefull information and your experience feedback about using webHttpBinding compared to the new WCF Web API http://wcf.codeplex.com/.
What I'm looking for is to know about the shortcomings of webHttpBinding and therefore why to use the new Web api and especially what problems the new API resolves.
If you could point me to some blog posts comparing both of them or just talking about the problems when using webHttpBinding I would appreciate. Thank you in advance.
Main shortcomings I would say is that the webhttpbinding makes it difficult to handle HTTP specific concerns. It works great if all you are doing is passing an object over HTTP that is serialized into XML or JSON and which may be transported over different formats.
HTTP is much more than a simple transport protocol for XML and JSON, it is an application layer protocol with rich semantics. Web API is specifically targetting folks that want to build systems over HTTP that fully levergage HTTP's richness.
Web API embraces that HTTP Resources can have a multitude of representations based on the needs of different clients. One end of the spectrum could be a dumb browser that just talks to a service using a Form url encoded post and a GET, while the other end could be a more rich client that uses Atom/OData or a hypermedia based media type.
Web API embraces that there are other HTTP specific concerns like conneg, etags, etc which allow better leveraging intermediary web servers.
Web API is designed with more testability in mind, thus you can address working with HTTP messages or other concerns in a more testable manner.
Web API has a more simplified configuration story.
You can read more about the rationale here: http://blogs.msdn.com/b/endpoint/archive/2010/11/01/wcf-web-apis-http-your-way.aspx
The most significant difference for me is the change in programming model. You no longer write 'services' which expose 'operations' bound to HTTP idioms (GET, POST etc.). With Web APIs you create 'resources' (POCOs) with which your clients can interact.
Web APIs seem to be better at handling various custom media types (like PNG images for example).
Last but not least, Web APIs are far better suited for automated testing. For instance, you no longer have to use static context classes to access HTTP concepts such as response codes. You use POCO request and response classes which can be easily instantiated in automated tests using old-style new() operator.
I agree with Ladislav that Web APIs are just a preview now and building application on top of it can be both risky and forbidden by the means of license agreement (but I haven't checked that).
Have you considered #serialseb's OpenRasta? It is stable and offers very nice programming model for building RESTful services.
The Web API is something like possible future of REST development in WCF. It is just preview which can significantly change before final release (probably in next version of .NET framework). So if you want to build production REST service you should use webHttpBinding.
Available information about Web Api can be found for example on .NET Connected Framework team's blog and on the site you mentioned. It is simplification and extension of current REST API.
Web API provides a REST-friendly HTTP based API. Web API uses the patterns of MVC and is going to be very familiar to ASP.NET MVC developers. Web API can leverage the capabilities of HTTP as an application layer protocol, returning resources in multiple representations (XML, JSON, HTML etc.) according the the client's request headers.
On the other hand WCF webHttpBinding uses the patterns of WCF, and is going to appeal more to the WCF developer - ServiceContracts, OperationContracts, comprehensive (or overweight, depending how you look at it, config file), ability to self-host outside of IIS.
One of the things I like about Web API is the ability to use dynamic types to escape the constraints of the type system. I also like the default exception behavior in Web API - contrast WCF webHttpBinding where, by default, exceptions bubble up as HTTP 500 + an HTML payload (yuk!).
Its nice to have the choice between two excellent technologies here. I wouldn't describe Web API as 'newer' or 'better' that WCF, as this implies its a replacement technology and that WCF webHttpBinding is legacy, which I don't believe is true.
I chose to use WCF webHttpBinding recently to expose a JSON API for an existing WCF SOAP service. I believe it was a good choice because it fitted that style of that existing solution and minimized the amount of change required.
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
A .net desktop application will send information to a central server, there will be potentially thousands and thousands of deskop apps sending info to my server(s).
The data will be small in size.
Would .net web services be good for this scenerio or would WCF be better suited?
What are the pros/cons?
I'd go with a WCF REST-based service, because you'll be able to transmit pure data without the overhead of the SOAP header (and other envelope nonsense) that comes with the SOAP-based classic .asmx web service.
the possibilities for throttling, concurrency, etc. are far more developed within wcf.
its a little bit more work in the beginning, but i guess that it's better suited for scenarios where you need to have full control over your bindings.
WCF is a more robust approach to SOA. Microsoft is committed to making it the primary framework for building the next wave of Microsoft business applications. The functionality available already, early in its lifecycle, is superior to plain old web services. It's only going to get better. By going with WCF early, you will be able to ride the wave and take advantage of future new functionality.
In some cases depends on the type and amount of data to send.
WCF will give you more options to tweak your calls.
On the other hand, I can't think of advantages of implementing asp.net web services over WCF. In WCF you could also implement plain 'old' web services
ASMX is like remoting, it's still around because it shipped with 1.0, but you shouldn't use it anymore if you are starting a new project. WCF will give you many more features and better tooling support.