Monthly Archives: March 2007

Future jobs

Few months ago, I was reading an article describing a deviation that the new electronic, synthetic world brought over:  people that pay other people to play electronic games. 😉
In that case, we could say that someone (with probably too much money to waste) payed other people (humans) to play the role of avatars.

Today, I received a mail from a friend in which there was a reference to an article describing a form of vandalism on SecondLife. I am not interested if this really happened in the way it is described…What is true is that this could actually happen (after all, with all the interesting things to read, learn, produce.. aren’t there people that spend (waste) their time creating viruses ? ).

So, I can imagine that a new kind of job may soon be on demand: the virtual bouncer or the virtual security guard. Someone who is payed to control our synthetic house or look the shoulders of our synthetic life…. Cool, isn’t it?

Are Mashups Web-based only offering?

An interesting article “Barrelling Through The Web 2.0 World” highlights parts of a recent Gartner’s report on Web2.0. The article features my friend and IBM colleague Dan Gisolfi.

I extrapolated the sentence

Who is to say the mashup has to remain a Web-based offering ?

because I think that it is very interesting… Not because of its “Web 2.0” bias (as the article implies) but because of the implications that the mashup technology could have well outside pure browser-based technologies.

Web-based technologies go well beyond their utilisation in browsers. I think that they have their place in Rich Client applications also.

I am thinking here to technologies I know, such as Lotus Expeditor or Lotus SameTime. Where the Composite application model actually allows the integration of content and application delivered over the internet with content and application aggregated from the enterprise SOA.

Thoughts around REST

It is quite sometimes that I have in mind to write down this little comment. I know that, in doing this, I am probably going to be ignored or to be blamed.
But, for all my readers, I am doing this exercise with true humble and open spirit; I am sure that many things I write here represent only a part of the truth, perhaps so little a part…. or perhaps no part at all 🙁 My objective is to understand where I am wrong: so, please, accept my apologies in advance. After all, the motto of this blog is to have “opinions”…. not “truths” 😉 !

So, here is what I do not like in the REST Hype that is around.

  • despite it is “de facto” the way the Web works, REST is counter-intuitive to me.
    It is counter-intuitive because since when I first started to program, I was told to use “subprograms”.
    And, when I moved to Object Orientation, I was told to invoke methods on objects.
    In summary: if we need to use an “addressing space” that is as wide as the whole Internet (and, not simply constrained by the virtual memory given to my executable), I do not see why I should change the way in which I am programming…why should I avoid the “invocation” paradigm ?
  • I think that REST does not add anything on the top on SOAP (or its XML-RCP ancestor).
    It is isomorphic to SOAP. Just using “nouns” instead of “verbs” simply shifts the complexity from one part to the other…. with the side effect of making the things less clear (at least for me, as I am used to add meaning to the verbs I use to describe “actions”)
  • I think that REST assumes that the world is painted with one color only: stateless.
    The reality is seldomly “stateless.
    A lot of times, it is “stateful”. And, maybe I am wrong, but I think that it is better to consider “stateless” as a subcase of “stateful” than the viceversa.
    Statelessness is great for scalability; of course! The Web is so scalable because it is stateless; sure! But, here we are not talking about pages, we are talking about an “addressing space as wide as the whole internet. We are talking about applications that use such a big space.
    I understand that the use of REST makes it possible the different caching levels the internet provides; but in so many cases, the data that are manipulated by internet-wide applications are changing so frequently that caching is not an option.
  • With REST, the “state transition” is in the protocol. I am used to manage the “state transitions” in my code.
  • I fear that REST brings back two-tiers architecture.
    Issuing GET, POST, PUT and DELETE operations on remote resources looks, to me, very much like performing CRUD operations on a remote database: something we have learned not to do.
    I understand that the implementation of a REST service makes sure I am not actually accessing the physical row in a database… but this is true for any RDBMS, actually.

I realize that an important part of the hype on REST is due to the fact that SOAP is so complex!

And I agree that REST is, certainly, a great way to address resources; it is really great when you can easily put an URL into some code and create those cool mashups!
But I would not like to extrapolate that, since something is so easy to use, then it is the only way (or the correct way) to accomplish a given task.

As I said, these are just few thoughts that I have in mind on this subject. I know that there will be arguments to address each of those concerns and to take me back on the “right way of thinking“….

P.S. : By the way; few of the previous thoughts would also apply in favor of an RPC approach to WebServices!

BPM **is** a mashup

Wow! I think this is an interesting quote from the BPM and Enterprise 2.0 panel:

My favourite quote from the panel, from Phil Larson when speaking about mashing up BPM data: “BPM *is* a mashup”.

I never thought in this way, but this is certainly very stimulating as a concept. It is the way in which I always thought to this topic (BPM) in my mind; taking services and visually composing them together in a network in order to create a Composite, Multi-Role and Multi-Step Application.

  • RSSRSS
  • Social Slider
  • RSS
show
 
close
rss Follow on Twitter facebook linkedin