Warning: include(wp-includes/class-wp-query-update.php) [function.include]: failed to open stream: No such file or directory in /home/content/06/8316506/html/wp-settings.php on line 376

Warning: include() [function.include]: Failed opening 'wp-includes/class-wp-query-update.php' for inclusion (include_path='.:/usr/local/php5/lib/php') in /home/content/06/8316506/html/wp-settings.php on line 376

Warning: include(wp-includes/class-wp-term-connect.php) [function.include]: failed to open stream: No such file or directory in /home/content/06/8316506/html/wp-config.php on line 92

Warning: include() [function.include]: Failed opening 'wp-includes/class-wp-term-connect.php' for inclusion (include_path='.:/usr/local/php5/lib/php') in /home/content/06/8316506/html/wp-config.php on line 92
September « 2011 « Ocean Web

Archive for September, 2011


Friday, September 23, 2011
posted by saille429

I posted an answer to the following question on StackOverflow today, and I thought I’d publish it here too.

Q: “After reading many tutorials (which seems contradictory to each other) on REST based web services, I was wondering whether we can/should use SOAP to send/receive messages in REST based web services ?”


SOAP is an XML based messaging format for exchange of data. Soap also defines a means for making remote procedure calls. SOAP is an open standard from the W3C. SOAP is agnostic about the underlying transport layer. Frequently HTTP is used as a transport layer, but it can happily run over SMTP and TCP, and other transports too.

REST is an architectural style (not a standard), so be careful not to compare REST and SOAP directly because you are not comparing apples with apples. REST takes HTTP and uses it is the way it was meant to be used, with all its subtleties and richness. The REST architectural style can used to transfer data in any format – it does not mandate any particular data format. So SOAP is a perfectly good serialization format for a REST style web service. But many people use JSON, XML, plain text and many other formats with REST. You can happily exchange binary data over REST too, like image files. The nice thing is you get to choose the data format that makes most sense for your application.

Note that since REST is a pattern, not a standard, there is a lot of debate about what it means to be truely RESTful. There is a concept called the Richardson Maturity Model which lays out a series of steps towards the REST ideal. By comparing with Richardson’s model we can see exactly how RESTful a particular REST implementation is. WS-I BP web services are at Level 0 on this scale (ie. not very RESTful at all, just using HTTP as a dumb transport layer).

I would say this about choosing REST vs WSI-BP web services – it depends on your audience. If you are developing a B2B type interface within an enterprise, it is more common to see WSI-BP web services. Because there is an underlying standard, and because of the mature support by enterprise vendors (such as IBM, Oracle, SAP, Microsoft) and because of the level of framework support particularly in .NET and Java, WSI-BP makes a lot of sense when you need to get something going quickly and you want to make it easy for clients to connect in an enterprise environment, and the data being exchanged is business data that serializes nicely as SOAP.

On the other hand if you are exposing web services to the wider web audience, I would say there has been a trend away from WSI-BP and towards the RESTful style. Because REST only assumes the client supports HTTP, it can be made to interoperate with the widest possible audience. REST also gives you the scalability of the web itself, with the support for caching of resources etc which makes it will scale up to a large audience much better than WSI-BP web services.

The Intranet Landing Page IS the Intranet!

Saturday, September 3, 2011
posted by saille429

The landing page is going to leap out at every staff member every time they open their web browser. When staff members talk about “The Intranet” they are talking less about all those documents, applications, training materials and forms, and more about the home page.

That’s why the landing page really counts. You already have the documents, applications, training materials and forms – the trouble is finding and accessing them. The landing page is like Google is to the web – a veneer over the top of all this that will make or break it. The landing page is THE page that everyone comes too. It should be the most dynamic page on the whole Intranet, updated frequently with the most important information, and nothing more.

The Intranet is a strange beast – its kind of like your own private Internet, but with lot of strange quirks, such as legacy technologies, security paranoia, and corporate politics thrown in for good measure. The key to a making good Intranet for your organization is to forget all of these things, and just make your Intranet fast, friendly and have people want to use it, not because they are required to, but simply because its the best way to find the information they need.

I wanted to share some thoughts on the subject of the corporate Intranet, so I have published a lightweight whitepaper to help organizations to focus on what really matters when building an Intranet. There’s less than 4 pages of reading, so I encourage you to have a look and leave your thoughts in a comment here.

Read it here: The Intranet Landing Page