S-Cube-Blog
S-Cube's Weblog
Would you like to fly with a spaceship that was assembled by service people?
This might never happen, but if we ever build a spaceship based in
SOA, I'm not sure if I would like to go on bord. It would probably look
very good on paper, but it would definitively not work without some
minor or major "hiccups". Once in the deep space, one might run into a
SLA violation and you probably would experience some disintegration of
your spaceship.
This is, admittedly, a bit of a polemic description, but you can find
some grain of truth in this statement. However, why should we build
systems that are based on a fuzzy notion like services (see last post)
and with heavy weight xml artifacts which difficult to understand (for
humans) and even more difficult to use? So far, the tooling is not
exactly what one wishes for and the creation of workflows appears to be
a tedious and thus error prone task.
A way to look at things is to reason what one wants to do in the first
place with services. Well, it's simple: we all wish to invoke a service
with some input and expect some output. We want to make decisions,
based on some expressions, either to invoke a service or not. The data
that we base our decisions on can be the result that we get from other
services (output) or user input. We also need some kind of support for
the creation of loops and a place to store the result of service
invocations (variables).
That's basically it. I'm aware of all those fancy concepts like
compensation handling and so on. However, in my opinion this makes
things unnecessary complicated and I dare say that some of this appears
"academic" and not exactly useable in practice. Yes, there is always
space for some PhD thesis that discusses a very specific detail of
workflows :-).
What I question is the approach of creating workflows like full fledged
languages with heavy semantics and lots of features. In my opinion, we
can build workflows with simpler mechanisms and exploit existing script
based approaches. The use of Groovy scripts is an example for this (see
links)
I'm aware that this might appear to be yet another way of simply embedding service invocations in java (groovy being a super set of java), but it has some advantages over existing workflow approaches. Groovy is a dynamic scripting language which allows run time modifications and don't we all crave for runtime changes based on contextual information :-)? Of course there is much to do, but I think this could be a interesting direction which needs more and deeper investigations.
So would I fly with a spaceship that is programmed in Groovy? Probably not, but one can never know for sure :-).
- Martin Treiber
References/Links
Why BPEL is not the holy grail for BPM
Flow diagrams, turing machines and languages with only two formation rules
What is a Service?
What is a Service - it seems that we as Service community still have no clear understanding about this.
S-Cube KM iPhone App is available in the iTunes Store
Download the S-Cube KM iPhone app: http://www.itunes.com/apps/sCUBEkm
S-Cube KM iPhone App - Waiting for Review
The S-Cube Knowledge Model Application is currently somewhere (lost?) in the Apple Review pipeline.
Eating the own soup
The service community seems to suffer from what can be called a "lacking implementation attitude". There are nice concepts, but often no implementations that verify the concepts. Only one step away from this lack of implementation attitude is something that I would call Evidence-based Service-oriented Architectures, or eSOA, where each concept is supported by experiments.
Lessons learned from the Wikipedia Community
Trying to add a S-Cube Knowledge Model Link in the Wiki Page of S-Cube.
Joined Paper with Austrian SMEs
The Collaboration between industry and academia is not always easy to accomplish. The respective incentives differ considerably and sometimes, even if there is mutual interest in doing something together, it is not possible to do anything together, like writing a joined paper and submit it to a conference.
While paper writing is important in academia, industry - especially SMEs - are not really interested in writing papers with academia. One of the first questions that is asked is: Ok, this sounds interesting. We like this idea. But, how can we use this idea for our customers? What is the product? Sometimes, it is difficult to explain that there is no immediate benefit for customers by writing a paper with academia, but opens possibilities for future developments. Euphemistically speaking, a joined paper can be a spark which paves the way for future inventions.
We, at the DSG - http://www.infosys.tuwien.ac.at/ - were lucky and we had the opportunity to collaborate with TISCO - http://tisco.at/ - to write a joined paper which we submitted to the ICIW - http://www.iaria.org/conferences2010/ICIW10.html - and that was accepted (of course, I might add :-))
For the future, we plan an additional joined paper with another austrian SME called iKANGAi http://www.ikangai.com/ They work in a different field, and it's certainly challenging to find mutual interesting topics. But this is an exiting challenge and we are more than willing to take it.
- Martin Treiber
ICSOC/ServiceWave
Hi S-Cubers and all,
I am here in Stockholm and enjoying the ICSOC/ServiceWave conference. Very interesting to see the diverse range of topics addressed by the SOC community.
Cheers,
Andreas (M :-)
S-Cube
Welcome to the S-Cube Blog!
The S-Cube Blog is intended as informal way to disseminate research results of S-Cube. Well, maybe this was too formal ;-). So what can you really expect here? More or less a bit of everything, that is related to S-Cube (which is a lot). Expect conference reports (the ICSOC is currently ongoing at Stockholm and there is the MONA+ workshop today and tomorrow morning) or ideas about future developments in the Service field. Anyone is invited to participate and to write what she or he finds interesting. Of course, the latest recipie of your great grand mother may not be of interest for a broader audience... so take this into consideration and for now: happy blogging!
- Martin Treiber