I have several questions regarding to wcf WebMessageBodyStyle best practice:
What is the diffrence between bare and wrapped?
Does bare and wrapped effects Json or just the xml format?
What WebMessageBodyStyle will be more efficent in a narraow bandwidth network?
What is the best practice binding to a cellular network?
Thanks.
Related
I'm going to implement a complex, dynamic, binary protocol in Clojure using Aleph and Gloss.
Now, Aleph is awesome and Gloss makes things much easier, but protocol in question has lots of optional fields.
Q: Can a Gloss' header->body function return another header? Or should I dynamically build the map to be compiled into codec?
And more general question: Are there any best practices or examples of building dynamic network protocols in clojure?
I'm working on a personal project which is an RPC (client-server) in C++. The RPC will communicate over TCP/IP or HTTP. The spec of the RPC is here :
http://groups.google.com/group/json-rpc/web/json-rpc-2-0
I'm wondering if there is an existing design pattern (or a combination of pattern) that could help me to produce a clean and flexible design. I will appreciate to have code examples, UML diagrams, or articles.
Thanks.
You are probably going to need a Proxy on the client to represent and make callable locally any server-side methods that you will be calling.
Under the covers, Abstract Factory could be useful to encapsulate provision of a concrete network connection that is selected using a configured or requested protocol (TCP, HTTP).
I would go for Observer.
Details and diagrams.
It's not clear if you asking in regards to high level design (observer patterns, JSON/XML processing techniques, etc.), low level design (sockets, HTTP client/server handling, etc.), or both.
If interested in lower level aspects including scalability, it might be worthwhile to study the design and motivations behind ASIO: http://think-async.com/Asio/asio-1.3.1/doc/asio/overview.html .
I am looking for a fast and efficient protocol that can be used between different web services to send text-data (not binary data). Doesn't matter if the protocol is binary or text base.
Some conditions:
I has to be more "efficient" than normal XML which adds a lot of extra data and the tools to read/write is too heavy
It has to be "supported" by most major languages, meaning it cannot only be available for one specific language. At the moment, both Java and PHP have to be able to talk to each other using this protocol.
I have already looked at:
XML - which I am currently using.
Hessian 2 -which works perfectly in Java, but the PHP-support is out of date
JSON -the different between JSON and XML is only minor
Any suggestions are welcome!
Update 1: It should be possible to use this protocol over HTTP.
I have two answers.
First of all, REST services are "supported" from any stack capable of making an HTTP request. If you really need better efficiency than SOAP, just doing it yourself with REST is probably your best bet.
Second, does it really need to be 'more "efficient" than normal XML'? Have you profiled it? Are you certain that data transfer between your service and the client is going to be your bottleneck? How big is your payload with/without the XML?
Protocol Buffers might be exactly what you want. It's a Google creation that, in their words, is "a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more."
Their official docs show implementations in Java, C++ and Python. However, the protocol is simple and has been implemented in a lot of languages (I use a C# implementation, for example.)
IMHO, there are other methodologies in this area, but nothing quite meets the sweet spot of proto-buffers in terms of simplicity and performance across a variety of languages.
I know that there are a lot of discussions already on SO about SOAP, bloat, XML, and alternative mechanisms like REST.
Here's the situation. A new team member is really talking up SOAP based upon the difficulty of implementing protocols by hand. He recommends gSOAP (project is all in C++.) He is stating things like WSDL cleaning up lots of messy hand coded C++.
Right now I am handling most networking with XML based text messages, and the expat XML library. So I have some programming effort (not much) associated with modifications to message formats or additions to parameter lists. At the sender end I package up an XML request and send it over a plain old TCP socket. At the receiver I parse the XML using DOM or SAX. Etc. It has worked fine so far. The XML messages are quite compact and average a couple of hundred characters, at most. And I understand every item in those messages.
We want one portion of the product (a server) to be accessible to web sites that are coded using PHP. That is partly driving this idea here, that a SOAP interface will be "easier" for script writers. Everyone on this project believes that SOAP is their salvation.
I see the introduction of a new large library like gSOAP as highly disruptive to the momentum of a mature project.
What I am wondering is if there is a different and more compact way of doing what SOAP gives us. And how to balance claims of gSOAP or other SOAP tools making development life easier against hard reality.
IE, I am being told that WSDL is better, easier, more workmanlike, etc than hand coding C++ using an XML library. That it puts the semantics of the C++ objects right into the declaration of the network messages. The thing is, many of the XML messages that I have defined don't map one for one to a single distinct object at the receiving end.
Or, it is possible that I am worrying about nothing.
But the reality as I scan messages here seems to contradict what I have been told locally.
I'm not buying SOAP.
Don Box's original vision of a Simple Object Access Protocol is anything but simple now. It's become a bloated, design by committee mess.
Throw in all the additional dependencies on bloated libraries and you have a potential mess on your hands.
Tool vendors love SOAP, but I don't see much for anyone else.
I think that you will find that PHP developers are more likely to prefer RESTful interfaces. Here is a 2003 article about it.
http://onlamp.com/pub/a/php/2003/10/30/amazon_rest.html
RESTful interfaces are a growing phenomenon and if you need to attract developers to your platform it will be easier if you catch the wave.
Having said that, is there a good reason why you cannot support multiple interfaces? This is fairly common in web services that do not have a captive audience. You could support your legacy model, a clean RESTful model and a SOAP/WSDL model. Then take stock after 6 months to a year to see which model is the most popular and least effort to support.
When it comes to making the site more accessible to outsiders, REST has more widespread usage. As far as saving your project, it is possible that SOAP would do this because it demands a certain amount of rigor in interface design, however the same could be said of REST. If this is a key criterion, then you should probably abandon the hand-coded XML and go with a high-level interface design that could be implemented as both REST and SOAP.
I know some people believe that SOAP and REST are fundamentally different approaches, but if you take a RESTful approach to the interface design, you shouldn't have great difficulty in creating a SOAP version. Don't try to do it the other way around though.
Here is a classic, hilarious, debunking of SOAP - The "S" stands for Simple". The community I move in is completely converted to REST.
If you look around at RESTful interfaces on the net, you'll notice that SOAP is nearly universally avoided. SOAP is such a complex beast that it effectively locks out languages with no existing SOAP package, since nobody is going to implement it themselves. Raw XML, on the other hand, is pretty universal at this point, and not that difficult to implement in-house if necessary.
I have no experience with web services. Historically I've built client-server systems using proprietary communication protocols (even they happen to be XML). I just spent a few hours looking over Axis2 and it sent a shudder down my spine. The learning curve of WS scares me, and seeing all that XML surround so little functionality makes me wonder if it's worth the trouble.
How do you decide whether you need to use Web Services or a custom communication protocol? What are the advantages/disadvantages of each approach and what use-cases are they best suited for?
Please post a clear guideline, not an opinion piece :)
Build RESTful web APIs; then you get a lot of automatic caching and etc benefits that you don't get if you use other methods (SOAP, XML-RPC, etc)
See this post for more details
Another benefit is that if you build a RESTful API for your code to use, you can potentially let your users take advantage of it too - they often have uses for your product that you never dreamed of.
"Web Services" as defined by the W3C means using SOAP over HTTP. SOAP is severe overkill in most cases; it's only really appropriate (IMO) when you're making a public service available to the world, like an API for interacting with your website, for example.
Anything else (especially internal, private communications) rarely need anything more complex than XML-RPC. Only if performance is an issue should you consider a more condensed protocol; XML-RPC is so simple and widely-supported that the ease of development and debugging more than makes up for the performance loss of using bloaty ol' XML.
Remember that there are a number of frameworks out there that make programming web services very trivial stuff. In the VB / C# world .Net makes it a joy. I'm not really sure about specific frameworks for other languages but I am sure most have at least one.
The standardisation and simplicity of implementation and reuse of web services make them very attractive. As previously pointed out- yes, they make communications very verbose. If you are worried about this why not calculate how much data you actually will be trasmitting. chances are, with current network and internet speeds, it will be trivial - even with the XML overhead.
I would always use the custom data formats as a last resort and not a first. What widely used method you use it up to you but it's unlikely you would go wrong with Web Services model.
Maintainability and extensibility are the main benefits. The use of widely used technology your solution will be easier for someone else to understand plus you can use ready to roll libraries as consumers and providers.
I have recently broken my custom protocol habit. I am now using Apache on the server side and libCurl plus libxml2 to load and parse the XML on the client which is written in C++.
The server side can be either PHP or a CGI written in a more serious language. Depends what you want to do.
Webservices have the advantage of being somewhat standard, so it's possible for programs you've never heard of to use a webservice you wrote. Using HTTP can help them communicate over proxies and other network obstacles without any extra work from you. The XML, although rather verbose and ugly, is rather easier to read when debugging than binary data.
When you're transferring stuff over the network, it's unlikely that serialisation/deserialisation to xml will be the limiting factor in performance. It can be a bit of hassle, although a library to do it for you will help a lot.
SOAP and XML -- "all that XML surround so little functionality makes me wonder if it's worth the trouble."
Totally. SOAP is heavy-weight, and -- to a large extent -- a workaround to the need for static binding throughout the Java technology stack.
REST, on the other hand, is much lighter weight. Further, REST with JSON or REST with YAML is very lightweight, and very easy to implement. It builds right on top of the off-the shelf HTTP protocol.
REST requires you to define resources (named via URI's), and transactions based on the canonical CRUD rules (GET, POST, PUT and DELETE). Very simple and canonical.
In my personal (old cranky dude) opinion, web services should only be used as a way to make some of your internal information available to third parties (i.e. other companies, people outside your organization etc.). Of course, that is also the originally intended purpose of XML. :-)
If you have access to a direct connection with the databases containing the information your application needs - that is the way to go. It's faster and simpler - which in application development means "better" and "less buggy".