Architecture

REST -only links or no?

Ebenezer Ikonne — Tue, 01 May 2007 15:07:50 GMT

REST touts that a "progresses through an application by selecting links (state transitions) resulting in the next page....

To borrow from a commonly used example, if I have a web service that "gets a list of parts", the URI to get the parts would look like this: http://www.parts-depot.com/parts and the "response" contains a list of links to the individual parts like this: <Part id="00345" xlink:href="http://www.parts-depot.com/parts/00345"/>

For additional information, I would have to "select" the link to "GET" information on the part.

What consumer application really wants to iterate through a list of links to get part detail information (other than a user interface)?

The Astoria samples are more liberal and actually return detail information for each product that exists (a URI is included also):

<QuantityPerUnit>10 boxes x 20 bags</QuantityPerUnit>

<Discontinued>False</Discontinued>

</Product>

<ProductName>Chang</ProductName>

<QuantityPerUnit>24 - 12 oz bottles</QuantityPerUnit>

<Discontinued>False</Discontinued>

</Product>

</Products>

</DataService>

This just seems wrong to me and state transitioning seems to be shot. In other words, I think it becomes less about REST and more about HTTP and data formats. Maybe it's hi-REST versus low-REST?

Astoria - MS getting RESTful

Ebenezer Ikonne — Tue, 01 May 2007 14:45:01 GMT

I've been gone for a long time now; hopefully I'm back.

I discovered http://astoria.mslivelabs.com/ today and it is pretty interesting. Underneath the covers, the "Entity Data Model" (EDM) is used (a post for another day) and it seems like there is a conscious effort not to mention "resources".

The samples provided also bring some questions about resource/state representation and the concepts of traversing links. A follow-up post on this is coming.

Is Software Development Really Hard?

Ebenezer Ikonne — Wed, 31 May 2006 10:04:00 GMT

Rocky blogs that 98% of the systems being built out there are "trivial" or at least can be solved by "trivial" solutions. Is this really the case? He also contends that most applications are a "viewer (form, page, screen)" over data and development tools such automat this, attributing unecessary complexity to tool vendors, framework builders, architects etc.

I actually disagree with his assessment on the distribution of complexity. My developers spend much more of their time behind the screen than in it. I've worked on enough projects to know that there are a fair share of applications where more interesting things happen when a user clicks the "Ok" button.

Understanding the business problem that needs to be solved (deployment model, update strategy, functionality, performance requirements, scalability, user interaction, configurability, integration etc) drive the tools and methodologies that should be used. A decent understanding of tools and methodologies are required in order to effectively use them. It's not a secret that a lot of software projects fail due to a lack of understanding of both the problem domain and the toolset/methodologies required.

I cringe when folks with influence imply a panacea of sorts for software engineering based on a subset of scenarios. Each situation has to be studied in isolation. While there may be reusable "patterns and practices", in a lot of cases, these need to be "tweaked" to solve the problem. If your application is simply forms-over-data, build it in the simplest manner possible!

Is there such a thing as a "simple" service?

Ebenezer Ikonne — Wed, 17 May 2006 22:44:00 GMT

A lot of time has been spent debating REST versus WS-*, examples are given based on what have been qualified as “simple” services. For instance, a RESTian example that shows how to retrieve a list of orders (or cars) or a WS-* (dare I say SOAP?) example that shows how to consume a service that returns the current weather.

There has been a lot of banter that suggests that REST is used for “simple” web services and this has been slightly offensive to certain individuals. In fact many a blog has been dedicated to demonstrate how REST can be used to build “complex” web services.

I'm not sure that I subscribe to the simple versus complex views. I tend to to view services in the context of their nature i.e. how do they behave, what they require, how they interact etc.

For instance, certain services are long-running in nature i.e. they can take hours before completing business functionality. I won't get into discussions on whether the consumer should block or not - that's an implementation issue, but we generally agree that the service shouldn't “always” force the consumer to block. However building such services using REST is interesting (to say the least) because of the underlying protocol of choice - HTTP and its default RPC-like behavior. What does this mean? The developer of the RESTful service will need to override the default timeout for an ASP.NET thread (executionTimeout) to ensure that the thread managing the long-running process does not die prematurely. It doesn't end there however, the consumer of the RESTful service also needs to override their “request“ objects default timeout also so it doesn't die while “waiting“ because by default it blocks.

Scenarios like the one above should ultimately influence service architecture and not necessarily the logic executing under the covers.

Complex Queries and REST

Ebenezer Ikonne — Tue, 18 Apr 2006 17:17:00 GMT

It's been a while, been busy with work and all that.

I've decided to venture into the realm of RESTful Web Services. As is popularly quoted, “in theory, theory and practice are the same, but in practice, they are different”.

Trust me, I am still drinking the REST kool-aid and I definitely believe it solves a certain set of problems. You will be hard pressed however to convince me that there is an architectural style that solves all “web service“-type problems cleanly.

Having said all that, how do I RESTfully solve a situation like this:

Every order has an associated address. What a consumer wants to do, is send me a list of orders and have the corresponding address for each order returned, there are no links to be followed afterwords. Note that I said “a list“, as performance is an issue here i.e. the consumer cannot iterate through their list of orders and for each one, RESTfully (GET) ask for the address.

Questions:

What is the resource? I'm assuming its “addresses“ since that is the resource that I need returned.
What is the URI? “/addresses/orders“ or “/addresses/query?
GET doesn't seem like an option here, hence, looks like I need to POST my criteria
Does this have be followed with a corresponding GET to actual “retrieve“ the list of addresses or can my POST above handle that as its response.
Am I totally off base? :)

I will state that a lot of business applications that I work with use more complex semantics as opposed to the example (good one for illustration) Dare Obasanjo places here and most of the “samples“ out there are pretty trivial.

I'm hoping Mark Baker, Paul Prescod or someone out there can weigh in on this.

Thanks.

Why I Hate Frameworks

Ebenezer Ikonne — Thu, 09 Mar 2006 09:03:00 GMT

Via Don Box, I stumbled on this Why I Hate Frameworks. Quite humorous and actutally a good read.

Frameworks exist at multiple levels e.g. in my opinion System.IO is a framework. However, just like everything else, things can be overdone which leads invariably to Technology (maybe now Framework?) Overload.

What do you think?

Exceptions and SOA

Ebenezer Ikonne — Wed, 08 Feb 2006 19:14:00 GMT

Arnon posts here Exceptions and SOA that

"...(innerException) the original error" - do not expose internal implementation out side of the service - only what's in the contract - in other words don't, just don't bubble exceptions out of your service.

Well I wonder what the verbiage of the exception should be? If a null pointer occurred in the service, what message should I return back to the consumer of the service?

Lessons....

Ebenezer Ikonne — Thu, 02 Feb 2006 19:55:00 GMT

Does anyone even understand this article?

What value does it provide other than to make me wonder what the point of the article is!!

Enlighten me if you may.

How many is too many?

Ebenezer Ikonne — Mon, 28 Nov 2005 19:37:00 GMT

Udi posts So many Dlls, so little time. Working on a project where there was a class to dll mapping, I can agree to some degree with what Udi states. However, I believe becoming to granular also has its disadvantages and if not careful instead of referencing one dll with a couple of classes, you might end up referencing ten dlls with a class each.

I think that related classes should be wrapped up into a single project and assemblied as a single unit. Interfaces should be used to broker communication when a circular dependency might be introduced.

SaaS - Software and Services

Ebenezer Ikonne — Sat, 12 Nov 2005 23:03:00 GMT

Ephraim Schwartz posts Microsoft is stuck on the C: drive . I must confess, working for an ISV, I think about this alot and the way it would potentially change the business landscape. I wonder if ISVs would now begin to invest in the hardware their clients previously purchased. I wonder about revenue generation. I wonder about software updates. I wonder about support. I wonder about a lot of things.