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 .
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…"Blogjects
Control: "Create the session and stop ranting".
Session Captain: "OK, OK. Session Instance 345 created. User 111 is on the go"
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"
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"
– 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.