daihozen

I was talking to a colleague about Red Hat yesterday, and it struck me that a new competitor has emerged that threatens Red Hat's business model in a fundamental way. Red Hat has two main lines of business, Linux and JBoss. Yes, they also have a cloud platform called Redshift, but I'm guessing it's not yet of the scale of the other two. Both Linux and JBoss are Open Source, so the revenues to Red Hat are through support subscriptions. Put very bluntly, Red Hat's business model is based on fear, rather like that of insurance companies. Customer organisations are generally afraid to run unsupported software in their data centres, so they will gladly pay the insurance premiums to ensure that someone stands behind the software they run. But consider this subtle change in the model of reliability that comes about when we move to a cloud-based platform like Amazon. Reliability is achieved not so much by keeping servers running and getting them back online when there's a p...

The term ROA (Resource-Oriented Architecture) is misleading. It should ideally stand for "Resource/Representation-Oriented Architecture", even though that's quite a mouthful. I've found in my discussions with people who work on REST-based systems that lots of them are very fuzzy about the notions of "resource" and "representation", even though these are the fundamental concepts underlying REST (and my forthcoming messaging-oriented variant, ROMA). Let me try and explain this. Let's say I found a space capsule that had fallen out of the sky, and by deciphering the alien glyphs on its surface, I understood that it contained a 4-dimensional object from the planet Royf. Unfortunately, I couldn't take the object out, because ours is a 3-dimensional world and such an operation is impossible. However, I found that it was possible to get the capsule to "project" a 3-dimensional image of the object it contained, so I could "see" ...

I've been talking and writing about SOA as "Dependency-Oriented Thinking" for a while now, and have even conducted a couple of workshops on the theme. The feedback after the interactive sessions has always been positive, and it surprises me that such a simple concept is not already widely known. I'm in the process of splitting (slicing?) my white paper " Slicing the Gordian Knot of SOA Governance " into two, one dealing with SOA ("Dependency-Oriented Thinking" or DOT) and the other dealing with Governance and Management ("Dependency-Oriented Governance and Management" or DOGMa). Partway through the DOT document, I realised that one of the diagrams in it explains the entire approach at a glance. Here it is (updated after the release of the Dependency-Oriented Thinking documents ). Click to expand. This is of course the BAIT model of an organisation, with a specific focus on Dependencies. BAIT refers to Business, Application, Information (D...

It's been a while since our eBook on Loosely-Coupled IAM (Identity and Access Management) came out. In it, my co-author Umesh Rajbhandari and I had described a radically simpler and more elegant architecture for a corporate identity management system, an architecture we called LIMA (Lightweight/Low-cost/Loosely-coupled Identity Management Architecture). Looking at developments since then, it looks like that book isn't going to be my last word on the subject. IAM has quickly moved from within the confines of a corporate firewall to encompass players over the web. New technology standards have emerged that are in general more lightweight and scalable than anything the corporation has seen before. The "cloud" has infected IAM like everything else, and it appears that IAM in the age of the cloud is a completely different beast. And yet, some things have remained the same. I saw this for myself when reviewing the SCIM specification. This is a provisioning API that is mean...

It seems the season for me to post comments in response to provocative topics on LinkedIn.  A few days ago, Pradeep Bhat posed the question, "What Are The Drawbacks Of REST?" on the REST Architects LinkedIn Group. As before, I had an opinion on this too, which I reproduce below: "I wouldn't say REST has "drawbacks" as such. It does what it says on the tin, and does that very well. But remember that the only implementation of the REST architecture uses the HTTP protocol. We can surely think of a future RESTian implementation that uses another transport protocol, and that is where some improvements could be made.  1. HTTP is a synchronous, request/response protocol. This means the protocol does not inherently support server-initiated notifications (peer-to-peer), which are often required. That's why callbacks in RESTian applications require the use of application-level design patterns like Webhooks. Now that we have a bidirectional transport protocol in t...

A few days ago, David Diamond posed a deceptively simple question on one of the LinkedIn Group sites (SOA SIG) - "Can Anyone Explain SOA In Simple Terms?" The barrage of widely varying responses that followed was, in a way, an eloquent answer to that question! I've had my own take on SOA for quite a while now, so this gave me the opportunity to validate my model against what other practitioners had to say. And I must say this: I'm more convinced than ever that the industry is horribly confused about SOA. There are those whose understanding of SOA is at a purely technology level (even some of those who profess to understand that SOA is not (just) about technology). And there are others who may understand SOA for all I know, but whose explanations tend to be couched in so much jargon that they're really hard to understand. In hindsight, David Diamond could not have asked a more insightful question. Well, this is my blog, so just as history is written by the victors,...

I've long been a supporter of the JSON Schema initiative, and I was also happy to see developments like Orderly , which offered a simpler and less verbose format than JSON Schema. But Orderly introduces its own format, which necessitates conversion to JSON Schema before it can be used. Both approaches are unsatisfactory in their own way. One is too verbose and the other needs translation. All of this made me wonder if we aren't approaching the problem the wrong way. JSON Schema is a conscious effort to replicate in the JSON world the descriptive capability that XML Schema brings to XML. But is this the best way to go about it? I would like descriptive metadata about documents to be capable of being embedded inside the document itself, rather like annotations in Java programs. Indeed, this metadata should be capable of forming a "scaffold" around the data that then allows the data itself to be stripped out, leaving behind a template or schema for other data instances...