MoreWhite
a web 2.0 blog
New ajax web applications are coming out faster than you take a shit. If the AjaxOffice project gets some code written, we’ll have a full blown office suite running within the browser the next time you visit the bathroom. However, writing code doesn’t seem to be on the agenda just yet, so don’t get too excited. Nevertheless, you can avoid waiting for the open source movement to copy crappy ideas from M$, and start using existing applications out there: word processor, spreadsheet, calendar, presentation.
A typical web user is subscribed to many services, each with its own username and password combination. Remembering them all can be impossible for many, and we end up using the same combination for many services as a result. This means that if one service gets hacked, it’s all hacked, busted, ruined, sobbing, tears, whatever. [wired: 1, 2]
Single sign-on (SSO) services like Passport have failed miserably, now covering only the Microsoft county. However, a need for a distributed SSO service seems to be growing rapidly. Several people have already started developing solutions, including, last but not least, myself.
So what exactly are we trying to do when we define a business process? Are we composing, orchestrating, aggregating or managing web services? Are we defining the business interactions with our partners or an abstract process for our B2B partners? What terms should we use when we’ve got two thousand to choose from?
Not surprisingly, there are as many specifications for defining business processes as there are fancy terms: BPEL, BPML, BPMN, XPDL, BPEL-J, etc. Do any of these have anything in common? Yes, there are all four letters long!
All of the specifications for composing business processes from existing web services are big. And complex. And boring. But can we really blame them? Trying to define any possible interaction among services, plus format it is XML, cannot be simple. Or can it?