Friday, May 05, 2006

Enterprise SOAaaS2.0 and API Blogjects

The following is a transcript of a naked conversation recorded inside a global, distributed Enterprise adhering to the Enterprise SOAaaS2.0 principles. The conversation demonstrates how globally distributed transactions, consisting of endless, recursive, mashed-up services, applications and hardware components can be tracked down in real-time for an on-the-spot enforcement of Enterprise Policy; post-mortem problem resolution; and post-transactional Business Intelligence, to name just a few usages.

Though the basic concept is known and implemented for sometime now (and see my previous posts on Enterprise Logging), there are few innovations here, in particular the description of the entire Enterprise software and hardware components as Blogjects (Objects that blog, i.e. converse; keep reading for further details) and the exaltation of RSS as the new Enterprise components' Lingua Franca (bear in mind that RSS is the syntaxic part of the language. Vendors or Enterprises would have to decide on the content and the semantics). And yet, the following vision is compelling: application servers, operating systems, databases, processes, storage units etc. etc. – all are Blogjects in an endless Enterprise RSS conversation. Enterprise (B)logging.


Here's the transcript of that RSS conversation followed by a short discussion on API-type Blogjects .

The transcript:
Session Captain: "Control, this is the Session Captain speaking. User 111 is here again. This time, with his brand new ultramobile 7000 running Firefox beta 2.0. Tellin' ya – this guy is a pain…"

Control: "Create the session and stop ranting".

Session Captain: "OK, OK. Session Instance 345 created. User 111 is on the go"

Control: "Ack"

Service S50: "Control, there's a Session Instance 345 that's trying to mess up with me. What do you say?"

Control: "It's approved. Proceed"

Service S50: "Right on. Starting doing what I should do. The APAC data center is relatively free. Invoking myself over there"

Control: "Ack"

Service S50: "Control, I'm running out of resources; What's the nearest Sun Grid Service?"

Control: "It's in Bangalore. You should invoke Sun's Grid Service number G10"

Service G10: "Control, an S50 instance at the APAC Data Center is asking that additional resources will be allocated to Session Instance 345. My intuition tells me it is User 111 again watching his YouTube's. Am I Right?"

Control: "Enough with the speculations. Provide S50 with the resources it needs. Now!"

Service G10: "Dude, you had a tough night or what? Proceeding with resource allocation"

Control: "Ack"


Blogjects – or Objects that Blog – is a meme coined by Julian Bleecker and is now one of many synonymous memes describing the simple principle of existence by being (or rather because of being) a conversing entity. "I converse, therefore I am". The following definition (as well as the nice pictures accompanying it) is taken from Nicolas Nova's presentation titled "Blogjects and the new ecology of things":
"A Blogject is an artifact that can disseminate a record of its experiences to the Web and would report the history of its interactions with other objects and with people.
Blogjects are assertive: they are having a voice; they have an ability to act and to be articulate; they have a capacity to exchange and participate in channels of communication. With all these characteristics, objects become first class citizens".
I suggest we start thinking about software and hardware components as Blogjects that are part of an endless Enterprise SOAaaS2.0 conversation. Furthermore, in a real-time Enterprise context, where the capturing and processing of any event is critical, the importance of Blogging Objects is invaluable. If a KPI is crossing a threshold's chasm and this fact remains untold – well, a serious damage could happen (and see the following survey - 22K$/minute of downtime).

But from all possible IT blogjects, there's one with a particular importance for the SOAaaS2.0 world we're living in: the API. A talkative API is critical for the well-being of the service, but it is also essential for a non-intrusive SOA implementation, as I described in an earlier post (In SOA we Trust). I would, therefore, like to conclude this post by directly conversing with this first class citizen - the Blogging API.

I suggest, dear API, that you will tell us what you know and how do you feel in the following contexts:

1. When you're invoked tell the world what you know about who/what invoked you; through which channel, location [if you have these details]; what is the value of the parameters passed to you; what is the action you are going to perform; and what is your well-being status (KPI/KQI) at this starting point. It won't hurt if you tell us, as well, where you are currently physically deployed, because with all the utility computing stuff, this might not be where we think you are.

2. As you go on with your self-processing, you should tell the world, us, how you're doing. Don't be shy – tell everything: a state change, an operation you're about to perform, whatever. Naturally, if there are any changes to your KPIs/KQIs, or if you're encountering an exception – you surely need to recount that.

3. When you're done, tell us "how was it"; did you have a positive experience or a negative one. Give us as much details as you can. If, for instance, you were asked to create a record inside a database table – don't hesitate to tell us that record id so and so with the following attributes' values was created in table Z at this timestamp etc. Never underestimate the value of Information and never think that the Information is already known. You should tell us everything.

Lastly, whenever you converse, do so – like all your Enterprise SOAaaS2.0 counterparts - with RSS.

2 Comments:

Anonymous Udi h Bauman said...

Wow, really cool post!
Indeed the key to the emergence of a real super-organism is the interactions between it's agent components. But I don't think that RSS will be enough: machines will prefer OWL or even more expressive languages to exchange unambigious information.
I recently thought about the need to not only syndicate information & knowledge, but also goals, so that agents could get targets to pursue. And then, I think we'll also need some "chemicals" syndication, just like the attention/focus drivers in insects colonies. What do you think?

12:45 AM  
Blogger Muli Koppel said...

Hi Udi
You know I like it :-) But...
I'm reading what you're saying and see the AI camp with its endless efforts to build this super-organism. I assume one day they'll succeed, but until then we got to have the stupid bypass around. You remember the NASA experiment on reading thoughts? (my first Google post) - we need something stupid yet ingenious like this one. Nowadays every Enterprise component is either mute or partially talkative, and in any case, when it speaks it's in its own language. So first we must make them all chat excessively and next we must make this chat happen in a universally understood language. I think RSS is proving to be efficient in disseminating information. On top of that, as we both agree, a semantic layer should come. Will it be microformat-semantics or owl semantics or enterprise-proprietary, ad-hoc semantics - well, at this early stage we shouldn't be giving it too much thought, otherwise we risk to never get there. That's my feeling.

Thanks for your interesting comment.
muli

5:08 AM  

Post a Comment

<< Home