Lots of people who have read about REST would tell you that the "resource representation" pattern is a great progress in information system construction, in particular because you can "PUT" the representation back. That's in line with the DTO pattern that CORBA or JEE aficionados are/were so accustomed to. Of course, they often pass on the fact that having a standard "Change Summary" definition as the resource representation would be a terrific feature to have, one day the RESTafarians will look around and discover (Stefan?) that the industry had already solved all these problems well before they even started to understand them: Microsoft came out with the DataSet concept around 2003 and later, in 2005, SDO generalized that concept in both Java and .Net world. But it is so easy to ignore all the work that has been done and start over. Right.

So here the argument goes, REST is great because I can PUT stuff back. Complete Freedom, they argue. This is what Bill DeHora stated a while back:

So, in a business process where GET and PUT (and friends) apply to *all* business entities and are not just per process defined methods, why can't I GET the state and have a well-understood formal document returned citing the state of that entity? Or for that matter PUT the updated state to that entity? What's the actual  limitation induced by applying REST?

For those of you who still believe that PUT is all you'll ever need, let's look at the physical world: everything is in a "given" state. From the smallest particle to the heaviest piece of equipment. Each state has a well defined transitions to other states. I can't "PUT" a particle in any state I want, I can't PUT an elevator or a can of soda in any state I want. Actually, state is such a profound foundation in our universe that it defines "time". Time only exist because the universe can never return arbitrarily to a given state. If that were possible (who would decide which state to go to?), time would simply not exist.

Before you get too bored with metaphysical considerations, let's go back to information system construction. Information entities are like physical objects. First, they often represent physical objects and model their primary "States", if they are a more abstract concept, say like a contract, they nearly always have distinct states which control their lifecycles.

The question becomes how do you express the intent of transitioning from one state to another. I say intent, because, just like in the physical world THY SHALL NOT PUT STATE directly into the information entity. Yes there are attributes, say like the color of a soda can that can change idempotently and then there are attributes which represent the states of the information entity which can only be changed by the entity itself. The business logic that transitions from one state to another must be owned by the entity. If not? if not, terrible things happen when you have more than one consumer of that entity, you start duplicating the state/transition logic in the consumer of that entity. You get the picture. In the days we built monolithic systems, there was little value in correctly factoring that kind of business logic. In the SOA days - and I would argue the principal reason people fail at SOA - THY SHALL LET THE ENTITY DECIDE FOR ITSELF whether it can transition from one state to another. Most people do SOA and actually expose a Data Access Layer as a bunch of Services. They encourage people CRUDing. Worse, people like Dave (Microsoft) Chappell would tell you that the only thing that works is a "data service", SOA is a failure. I can safely say that he doesn't understand a thing about SOA. Now, when the RESTafarian like Stefan, Bill DeHora, Bill Burke, Jim Webber, ... come to you and encourage you to PUT up with CRUD as a key success factor for your "SOA", I smile loudly.

Now, people might tell you that PUT can express an intent, why not (Roy would disagree), they can tell you, but we use POST to encode all intent. I say why not, as long as the logic to transition from one state to another resides on the resource side, but have we gained? Nothing, we have just found another encoding (actually 2, PUT or POST) and we have lost so much (bi-directional interfaces, events, orchestration, we have coupled access and identity ...). So what is the point? What is the point of yet a new encoding? Browser access, ok, so what, do you need to displace entire technologies for that? Is that a game? I am amazed, in awe actually, at how such bogus arguments took hold in our industry, how little, nice to hear, stories ended up where they are today. Yet, REST is nowhere, no proof of any massive and successful use outside the browser.

So if you want to use PUT to the attributes that can change idempotently, great, if you want to use POST for invoking actions on a resource, even better, but don't tell me you invented anything. Information systems have been working on these principles for 8000 years. They didn't need computers, the Web, Stefan, Steve or Bill to figure that out.

The (other) REST is a fraud, and there is nothing clearer today.

Apple said Monday it earned $3.4 billion, or $3.67 per share

It could be the quarter where Apple passes Microsoft. I know they are not exactly in the same business, but still, who would have thought these numbers would ever be possible...?

I wrote back in the summer of 2002:

"Oracle, IBM and Microsoft [will be] the only total infrastructure providers left (OS/DB/App server/WS/EAI/B2B/... I sure hope that the SUN's disease (react to whatever Microsoft does) is not contagious because this is not how you build a corporate strategy...

This should not be a surprise to anyone. It took Sun 8-10 years to bleed and spend their money to beat the "competition". This is now Microsoft's strategy, "react to Apple and Google's every move". It is easy to know how that will end. Microsoft will not be around in 2020. As soon as Windows and Office cash cows will start to plummet, they'll be gone even faster than Sun. I have nothing against Microsoft, I wish for Seattle, that my prediction would be false, but unfortunately, the recipe is now well known. They are simply unable to establish any competitive advantage both in the consumer and enterprise markets. They actually don't understand these markets. They have been an ISV/OEM company, and even then, if the mobile market is the blueprint of battles to come, they have no idea to compete.

Just like Sun, Microsoft is a "geeky" company: Geeks write stuff for Geeks. Geeks used to be the vast majority of their customers. Geeks were making the calls to buy their products. Actually at some point, it was the ultimate Geek experience to buy a Sun server or workstation. Eventually, Sun didn't understood to sell to IT. Today, Microsoft doesn't understand IT nor Consumers. Worse, Microsoft leader(s) don't even use their products. They can't demo them either. The day Microsoft will be run by people who actually use the crap they ship to IT or consumers, that day Microsoft will have a chance to come back.

A few quotes from this article on InfoQ and comments:

First a note on backwards compatibility. There is none.

A key selling point for Windows Workflow 4 is its integration with Windows Communication Foundation [Just like "Routing", I am glad Microsoft's Enterprise customers can only benefit from that "new" feature... we are only 3-4 years after the first release of the product]

[Giorgio Galante:]Let's be honest, business users will not be writing their own workflows anytime soon with WW. So what do the consumers (developers) gain from the added complexity, learning curve, etc of using WW rather than just implementing 'workflow' in code? Very little IMO, and a slow runtime to boot (at least in WW3.) Given the above opinion, an extremely large & complicated application would be the only situation where one should consider using WW. Microsoft's decision to 'reboot' WW and throw out backwards compatibility without much consideration makes it a poor choice from a long term viability perspective. Why tie yourself to a technology that will likely be tossed out in 2 years? Anyone considering a workflow engine/tool for .NET applications should consider alternative 3rd party solutions first.

WF4 uses pure XAML to define workflows, which makes them much easier to programmatically generate but also means you lose the ability to leverage Code activities.

State Machine workflows are not supported in WF4, so anything based on them will have to be redesigned.

You can look a the programming model here.

I would not be surprised that they took away the State Machine capability, just because I claim that's an important capability to have [just kidding]

Doug, guys in the mighty CSD, this is beyond sadness, there is nothing that can be added. The Mighty CSD has destroyed the Enterprise arm of Microsoft. Who is going to keep buying SQL Server when everything else has to be procured elsewhere?

Note that the SQL Server division seems just as competent as the mighty CSD (I can already see the synergy playing between the two). Visual Studio/SQL Server Reporting Services Continue to be Incompatible.

This isn’t an oversight, according to Stella Chan this is an intentional design decision.

My prediction is that Microsoft Enterprise Software will be trimmed down in the next 12-18 months (as Microsoft revenue starts to take a dip) to a basic stack driven by ASP.Net/SharePoint supported where it can by the amazingly powerful tools and runtime engines the Mighty BSD can actually ship in a form other than CTP and minor incompatibilities.

Professor Wil van der Aalst et al. have done some interesting work on compiling a catalogue of control flow patterns in workflow, and assessing the extent to which different commercial workflow products support (or fail to support) different patterns. They have published a paper "Workflow Control Patterns" which describes 20 different workflow patterns and analyses the ability of 15 commercial workflow products to support these patterns. This paper is available from here.

They find that commercial products are uneven in their ability to support the full set of patterns. In our view, this is because these products aim for too high a level of abstraction in their control flow primitives, potentially leading to an explosion in the number of primitives required or gaps where patterns are unsupported.

There is a analogous problem in ideographic writing systems: the Kangxi Dictionary of chinese characters contains over 47,000 entries compared the 26 letters of the latin alphabet. The reason that alphabetic approaches achieve high expressive power with a small number of primitives is, of course, that they support the ability to compose the primitives (letters) to make larger units (words). We suggest that the same is true with control flow. The ability to compose control flow definitions (as you can with Protocol Machines) means that a small number of primitives can be used to model a wide range of control flow patterns.

We have successfully described the full set of patterns using Protocol Machines. As an example, a model for Pattern 7 (Synchronizing Merge) can be downloaded here (14 K). This example shows how composition is used to model a complex pattern. Please read the PowerPoint file first, for a description of the pattern.

I would add that Problem models tend to look like Kangxi ideograms because they lower the bar for business analysts to express their concepts. So you end up creating a lot of descriptive models that are more or less easy to learn by a given population. However, it does not mean that they are effective at representing how the solution is constructed, nor are they particularly effective at creating a complete description of the solution. Problem side semantics are almost by definition incomplete. Problem side semantics also tend to hide an efficient set of solution semantics (I don't want to say "the solution semantics" as there could be more than one).

What I am certain is that Problem-side semantics are the wrong direction to define efficient solution construction models. Problem side semantics are important, but they should be focusing on the problem side only.

Protocol Modeling (PM) is a technique that aims to combine the strengths of process algebra, in particular its formal relationship between states and events and its support for process composition, with the ability to model data.

Ashley provides some example where the complexity of defining a Business Entity Lifecycle is greatly reduced by the definition of a Protocol Model instead, which is strictly equivalent.

Other papers include "Programming in Protocol", CSP Parallel Composition of Aspect Models

A complete set of papers can be found here.

One of the side effect of locking knowledge is the emergence of banana scientists which are more concerned of crafting a story they can sell, without any consideration whatsoever for the science behind it.

Anyone looking at this amazing tutorial can only conclude that WOA stands for the "WOrst Atrocity" our industry has ever had to deal with. Let's all go back to notepad and hack URIs, HTTP headers and media types.

On a positive note, they finally understood what is the relationship between a process and a resource lifecycle. I wouldn't expect these "scientists" to actually point that out, but that's better than pushing broken views of this key concept.

On the convenient ommissions side, they "forgot" to talk about versioning, and the fact that RESTfully introduced a contract definition... contract, contract, contract, I thought REST had no need for a "contract"...

There is also an interesting discussion about RESTeasy vs RESTfully going on on his site. You obviously see the usual marketing crap about "my framework is better than yours". How about they are both equally "terrible"? They were both made by hackers who understand nothing about information system construction.

The (other) REST is a fraud and nothing is clearer today.

enjoy...

Dominique Vauquier, one of the founders of Praxeme just sent a couple of links:

You can join the Praxeme Institute as an individual for free (well worth it, if you ask me) http://friends.praxeme.org/adhesion/

Praxeme is now part of the "Interoperability Recommendations" of the French Government (http://references.modernisation.gouv.fr/rgi-interoperabilite - in French)

I know a lot of people want to send blankets or water...just send your cash

As always, amazing George...

Udi recently complained about solution side abstractions:

If we want our architecture to be stable, we need to base it on stable abstractions. The only thing is that there aren’t any inherently stable abstractions in the solution domain (as we’ve had the chance to witness). That really only leaves one other place to look for them – in the problem domain, also known as the functional requirements.

Udi believes that the solution is on the problem side :-):

If we could find a way to capture those stable elements and represent them as core elements in our architectural structure, and then balance the non-functional requirements within those functional contexts, maybe, just maybe, our architecture will stand the test of time.

His position is quite ironic as the BPM punditocracy interprets the current wave of acquisition of the BPM space as a "the end of BPM" as we know it. This particular rash of BPM products built their business on the fallacy that you could somehow build solutions directly from "problem-side abstractions", i.e. BPMN. Ten years later, we are still waiting for large enterprise deployments where all business processes are somehow implemented from problem-side definitions. These vendors have for long claimed victory, this is somewhat of a Phyrric victory for our industry. Sincerely, I am glad they are going away. They have taken away tremendous resources, delivered hardly anything, and prevented the right solution-side abstractions to emerge. I have had some discussions with Keith and Scott on that topic after Keith detailed the "process trends" he saw unfolding in the last 20 years.

These "process trends" are precisely the problem you are going to face if you go find your abstractions in the problem space: you will never succeed at converting problem side analysts that can achieve the level of rigor necessary to build a solution and because you will adopt their language, you will have less than optimal abstractions to build the solutions and you'll end up, like BPM, catering to different groups when the solution-side is in fact common. The little known secret of "BPM" is that once you quickly pass the pretty (process) pictures, when you look under the hood, you see all kinds of ugly scripting language dropped wherever possible. Scott thinks that JavaScript is the "ideal" complement of BPMN. Anyone who has written more than 10 lines of JavaScript understands what I mean, and JavaScript is possibly one of the better ones I have seen over there.

So Udi, I am sorry, but starting on the the problem side has been tried and it's a mess. Developers will never be able to design abstractions that make business analysts comfortable, they need freedom and fuzziness. They want the solution side to build the solution, not them. Hence, the problem-side needs a) as fewer abstraction as possible and b) (what is the most important) whatever runs in production (once the problem has been solved) must be "visualizable" by the business analysts. That is the most important direction: solution->problem, not the other way around. So far, the problem->solution is just a pipe dream, an immense distraction for our industry and a general failure.

There is a more fundamental reason, for why abstractions (problem or solution side) cannot emerge. If you spend some time exploring Ecore in EMF (or MOF in UML) and if you look at EMF's M3 layer (i.e. Ecore):

You can see that, the center is the "EClass". Just like in OMF, the M3 layer is OO based. OO is the enemy, sorry, I can't find another word. There is nothing abstract about OO and there is nothing architectural about OO. OO is a tiny little pattern which success is out of control. Actually, I am a bit unfair. I teach mathematics to my kids using UML. So, yes OO, provides a generic modeling capability to describe systems statically, or static abstractions. At a certain level, everything is a bag of attributes with relations to other things. But you can't efficiently describe dynamic systems in OO, the behavior is an after thought in Ecore and MOF, well beyond the OO cave.

Udi, look no further for why solution-side abstractions don't work: static solution-side abstractions are not very common. Once the modeler realizes that he or she needs behavior, that's when he or she starts throwing a scripting language into the mix and everything becomes ugly, impossible to dissociate from the underlying architecture (the script has to run somewhere, call some APIs...). Microsoft abuses "code behind" models, for the same result: once your abstraction is tied into an architecture, you know what happens next. I have raised this concern with some of the fathers of MDA but I always a distant glare and no response. I may be wrong, but IMHO, MDA is built on the wrong foundation, OO. It is going to be hard for them or for the OMG to change course, but there has been enough surges in that direction to think the solution to MDE would be more OO.

I like textual-DSLs because they are conducive to modeling behavior in addition to the abstraction. You tend to create your own programming language along-side the abstractions. This is why I was generally excited about SSM and things like MService.  Note that some people understand the problem, some people have shown how to extend Ecore to model "code" as well. But I think OO IS-THE problem, abstractions need to exist completely outside the OO cave. This is why I suggest to adopt a Metamodel Oriented Programming approach.

I am certain that the question you raise will be solved in the next 10 years and that the abstractions will be more on the solution side, completely outside the OO space.

Microsoft has chosen for the most part to deliver a PaaS, i.e. it is not selling server instances. I command them for that. That's very courageous and there are many pieces of Azure that I like: the Service Bus or the Access Control Service, for instance.

But, the problem with PaaS is versioning. This is even more complex than SalesForce, GAE and the like since each component can be versioned independently. Since the Mighty CSD never understood a thing about Service Orientation, they completely missed what (forwards) versioning meant as well.

Until now, however, it has kept the operating systems on Azure firmly under wraps, patching and making changes without warning. Now, Microsoft says that Azure will proceed with an earlier promise to preserve platform version control for users as it moves into commercial viability.

Azure users can choose from existing versions by updating their configuration files and preserve their instances from automatic patching, according to the posting.

Ouch, this is "service orientation" Microsoft style... Service consumers are coupled RESTfully to Service Implementations... What's going to happen when hundreds of patches will be applied to Azure services, not just Windows? How, as a consumer, will they ensure my compatibility with the latest versions of each service?

Fear no more, .Net 4.0 Routing Service patched with SSM CTP (thank you Doug) is coming to the rescue, boy oh boy.

The main application is, of course, to fetch warm croissants at the bakery from your bed.

So if you have not checked the dev tools recently, I would pick a page, select some content and right-click to "inspect element". Enjoy.

Note that Chrome is far behind IE or Firefox in ebpml.org stats. Hopefully, you'll give it another look.

What I find interesting with SaaS and Cloud in general is the emergence (not even the risk) of a new business model, the "freepoff" business model. I have seen it with my own eyes, so this is not just speculative. The "as-a-Service" model is particularly vulnerable to black-mailing customers. Once you spent X man months or man years of work customizing something in the Cloud, the Cloud provider might simply raise its prices well beyond what your business case can tolerate. It might even tell you that if you don't pay, it would go out of business. More subtle, and probably a lot more frequent, is the serendipitous difference between a quote and a bill, and the "honest mistake" of the "quoter" which did not "fully understand" the extent the "quotee" would use their service.

The industry would probably be better off defining a business model charter for as-a-Service activities. Phil provides lots of good reasons for it, ...but I don't really believe that will happen.

In a perfect Microsoft tradition, Steve only showed a CTP, i.e. the tablet is not available yet...

... and possibly available by mid-year

I heard they plan to synchronize the launch of SQL Server Modeling with the one of the Tablette, ok maybe this is just me speculating. Of course this is a Windows 7 computer and unfortunately they didn't have room for the DVD player. No USB port either, they had to make room for the modem, printer and RS232 ports. So you'll have to download ISO DVD images to install anything you need, of course, after you figure out how to mount them before it reboots due to an unplanned and critical Windows update. The most popular app so far, that's already pre-shipping, is the blue screen of death. A beta user reported:

The download was instantaneous and the execution flawless. I was able to reboot my computer just fine after the fake memory dump. It felt really good to experience my first blue screen on Microsoft's latest computer.

Steve also talked about project Natal, a "natural UI", that of course will ship "in a few months". It's going to be really cool to talk to my computer in the middle of the night and wake up the family. I can't wait to replace my TV remote with Natal, I can already picture the kids changing channels... boy oh boy.

I was telling Doug earlier that I was tired to hear pre-announcements, and what do we get? 80% of what Steve is talking about will be another Zune (means Zombie in technobabble).

Steve threw some numbers as well:

He said the company made a lot of progress in search with Bing, which he said now has 11 million new users

Gee, impressive, that's what 1% of the "connected" population? How much did they have to pay them to use Bing? I also suspect that the connected population grew by far more than 11 M in the same time laps, so they probably got a whoping 0.2211% market share increase on Google.

He said the Zune is getting great reviews

Just as many reviews as new customers...

I really enjoyed the title of the NY Times article: "Microsoft and H.P. to Reveal Slate PC Ahead of Apple". Yeah, ahead of Apple. Ahead is the new Behind in Redmond. Sad and embarrassing.

Actually, I am a bit unfair, PC Magazine found out that Microsoft had already announced a slate in 2002:

And of course, we've been seeing Tablet PCs including slate-based designs from Microsoft since 2002. http://www.pcmag.com/article2/0,2817,265001,00.asp

I'll let Mary Jo Foley conclude this post (I guess I am not the only one tired of Microsoft's Marketing "Strategies"):

Maybe Microsoft would be better off just relinquishing the CES keynote kick-off spot. Yes, I know there’s a renewed focus at the company on proving Microsoft has consumer mettle. But if you’re going to back up that claim, you need to bring to CES some things people are actually excited about. Not version 2.0 of MediaRoom (Microsoft’s IPTV software, if you’ve forgotten).

Well done, Steve, another great presentation. I am blown away.

Annotations in code (C#, Java...) are simply metadata describing concepts that cannot be materialized in pure OO. Annotions are the expression that MDE is the way forward, that you can't patch forever OO for whatever architectural concept is missing. So let me ask you, what is the point of adding "metadata" to "metadata"? Just expand the metamodel, don't create a new concept. If you want to have an annotation representation for some metadata you are free to do so, but don't confuse notation and metamodel.

Doug responded that this was exactly how SSM worked and that annotations were syntactic not semantic. I'll take his word for it. I have decided that I will never open a Microsoft technology until it ships, I'll come back exploring SSM in detail when it does just that.

EMF ships and has been doing so for years, so that's where I am spending most of my (free) time these days. I found this article on "Metamodeling with EMF: Generating concrete, reusable Java snippets" which I really like. It's a bit crude, but it really proves that MOP is growing.

I was also disappointed to read Boris' interview of Marc Fiammante on InfoQ. Here is someone who could speak coherently about SOA and BPM.

Here are just a few quotes, music to my ears:

First, I do not consider SOA to be Client/Server or Object-Oriented (OO) on Web Services, but a business contractual approach between two business parties.

Semantically, a Web Service is just a parametric state transition request on a target resource

Marc even quotes the work of the OAGIS !

But, no, that would be too easy, he still thinks that "WS-BPEL is an execution language for processes", (sight) this is hopeless.

Doug Purdy could learn a thing or two in the routing section:

With WebSphere Fabric we do store the routing policies in the registry and as a consequence, there is a place for dynamic routing support with registries. We need however to differentiate where the routing decision takes place from where the policy is stored. Usually the endpoints and policies from the registry are cached in the ESB performing the routing, while usually caching efficiency patterns and the routing evaluation is performed in the bus on the fly, and not in the registry which would require a remote interaction.

So what will be the characteristics of the devices (not computers) of this decade?  That's quite easy:

• touch, touch, touch
• apps, apps, apps... hu?... I mean connected apps
• location, location, location
• no sysdamin required

Many of us would feel that this is back from the future, but let's face it, just compare using a browser based app and an iPhone app. Not convinced? Do you use Netflix? Just compare browsing Netflix with a... web browser and Microsoft media center. You get the picture, right?

In 2005, I was making fun of Microsoft's "SaaS" strategy. Shortly thereafter they changed the course and came out with a "Software+Services" strategy. Yes, that was the right move, but we all know how well Microsoft executes strategic moves.

In this new landscape devices will be easy to use, loaded with "apps+services". The browser is out, whether you like it or not, we are back to the wonderful idea of multi-platforms. Did I talk about form factor of an app? Cheap, small, downloadable. The "price" of an app: $1 or $2 sound reasonable, well suited to a mass market of hundreds of million of people. Who's going to buy a $60 box, shiny DVDs included, running on an operating system that requires a Geek Squad just to keep running?

So here we are, at the onset of a tectonic shift (it has already happened, it will just become visible). Who's going to win? We know that won't be Microsoft, unfortunately for Seattle. Successful people at Microsoft are too busy boating and driving their fancy cars, they never use their own product, let alone watch how people are using them. Google may have bet on the wrong horse, the browser may be laid to REST in this decade. That prediction is easy to make: finger stokes are not RESTful and JavaScript can't access "local" information (accelerometers, location...).

So Steve Jobs may have done it again after the Apple II, the Mac, the Laser Printer, NeXT, the iFamily is breaking our industry's mold. Well done Steve.

If you want to see the future, just look at this app, that one too. Now, look at your browser...

I found interesting his discussion on the relation between ads and content towards the end. It appears to me that he still doesn't understand that there are three roles: the publisher, the author and the advertizer. For him authors and publishers are the same. I cannot emphasize enough how much a game changer it would be for the press (in the broad sense) if these two roles could be separated.

I was also quite surprised that he did not talk much about Cloud Computing.

One of the major "new" WCF features in .NET 4 is the Routing Service which is a configurable WCF-based service that supports content-based routing and protocol bridging.

Oouh..Aaah... I am in awe. Who would have thought that Services in SOA needed to decouple their interface from their implementation? Only Microsoft could come up with such a feature ... in 2010 when the rest of the industry provided it back in 2003. Thank you Doug ! What a beautiful holiday present ! On behalf of all your Enterprise customers, thank you ! Thank you ! This is nirvana.

For instance, if a company has two different versions of the same service deployed, the client application can call into a central routing service. The routing service can then forward the message to the correct backend service based on information it extracts from the incoming message, such as version number.

Oouh..Aaah... I am in awe. WCF can actually version services, right now, I mean when WCF 4.0 ships? Wow! Doug, do you even understand how versioning works in SOA? Have you heard of something call forwards compatibility? Are you that ignorant? People that "route" consumers to immutable versions of services quickly end up with 15 versions of each service in production. And then their SOA stall under the weight of regression testing and tricky updates across 15 different code bases.

Last, but not least...

Unfortunately, the default routing service is not the easiest to manage or configure.

Really? Oohh.. You mean that this is something you even have to tell us? Isn't that the basic characteristic of WCF since its inception? Tools? No tools ! the mighty CSD writes software for "real" developers, the vi and emacs kind... sorry... I meant ...the Notepad ones. But Microsoft will spare no effort for the rest of us:

.NET 4 router configuration is a good modeling candidate [...] The SQL Server Modeling CTP (sic) can be used to create a domain specific language (DSL) that can make the routing configuration of the WCF routing service much simpler.

Wow... you mean I need SQL server to define a routing map and implement a broken versioning strategy. Gees, the mighty CSD rocks [bottom]. Which enterprise would not want to adopt WCF and SQL Server Modeling "CTP" at once? Who would pass on such an incredible piece of infrastructure which 7 years after its inception is still delivering basic functionality and relies on crutches?

Add another 10 years and you can be guarantied that WCF 8.5 will support XSLT transformations (stored in SQL Server, of course) and will finally get WSDL-first to work. Just like the BizTalk Server 2009 would have been a great product in 1999, WCF 2019 would start looking decent for the 2005 era.

Organizations are adopting cloud computing because their customers, suppliers, partners and employees are all doing business and interacting in the cloud already, and multi-tenancy makes no sense except as an enabling component for uncapped connectivity to every other business and resource out there in the public cloud.

Phil, could it be that you are mixing up two concepts? Multi-Tenancy and Multi-Enterprise Business Applications? What is the value of MT when data is strictly partitioned? It makes sense when resources need to be shared from a cost perspective, but in the case of a MEBA (i.e. when each enterprise is allowed to tap into each other's data) that can be achieved without necessarily MT.

I would argue if you are deploying some SaaS or PaaS that is entirely built in F/OSS, you are much better off, not trying to add multi-tenancy to the stack. MT is mostly a cost optimizer, MT does not give you a MEBA capability by default. And yes, MEBAs have a lot of business value, far more than Multi-Tenancy.

• 20 major product releases all based on our OSGi framework Carbon
• 15 minor releases
• Five new major products
• All our products now available as VMs and AMIs
• ...

Guys, you don't have to do the typical vendor dog and poney show. You are clearly better. Happy and prosperous year !

I didn't go with functional languages because I believe the fundamental role of programs is to modify state, not just the bits.

Barbara talks about the 40 year "Software Crisis". If I may take a stab at it, pretty much every one is look at Polyadic Anemic DSL or Monadic Cogent General Purpose Programming Languages. In 40 years, no one has found a monadic concept that would solve this Software Crisis. I am puzzled at why no one is looking at Polyadic Cogent Programming Models. I like her last sentence of the talk, talking about programming on the Web: "Maybe we can find programming languages where we can programm the whole thing".

In the latest CTP you can add attributes/annotations for “M” types, extents, fields, functions.

What a brilliant idea, annotating a DSL. Hey a textual DSL looks like code, so why not annotate it?

Some of you may also have picked up the anemicity of the People service, I am in awe. I mean wow, who would have thought to design the People service that way? Can you imagine, we can now create a service definition in M and it gets stored in SQL Server. I mean, Wow. I bet that one day WCF will even be able to read it back. And, add another 10 years and M will have a WSDL-mode. Wow, I just can't wait. This is so cool.

What to expect after that? I can't resist to share what I have heard: they are going to come up with is a T-SQL emulation mode for quadrant. Yes, in a few months, soon, I mean when they get a chance, they'll ship yet another CTP that will let you create M files directly from a T-SQL syntax.

Oslo rocks!

Some even felt it was time to crunch more numbers. You know what is the size of the BPM market? $3B. Yes, IDC has predicted that 2013 the size of the BPM market will be $3B. The problem is, that $3B prediction has been a rolling prediction since at least 2004. Miko, is there a formula to calculate the growth rate of a rolling target? I think it is exactly 0.2%.

So why did IBM buy Lombardi? The world is holding its breath, waiting for the answer. Is it because Frank Leymann needed to win its BPMN to BPEL argument? Maybe. WebSphere Business Modeler (which first appeared on the market in 1955) needed a face lift? Hum... how about, BlueWorks sucks?

Not sure, what is certain is that BPM is not going very well at all and instead of going through the morbid exercise of trying to see which piece fits with which and which widget will survive the acquisition, the BPM pundits like Sandy, Bruce or Scott would be better inspired reflecting on why BPM is so abysmal? Why BPM's target is 0.2%? No, these people will defend the indefensible: the fallacy that you can somehow refine little by little, one layer of metadata after another from the business analyst to the integration developer.  

This phase of BPM is over, the acquisition of Lombardi signals that the last decade has been a complete waste, that pretty-picture-to-execution does not work, otherwise, I can guarantee you it would be the other way around, the BPM market would be about $200B and Lombardi would have bought IBM. BPM, as it was designed an preached by the pundits, the "experts" cannot stand on its own. Live with it. Middleware has won, of course, because ultimately, the value is in the execution not the notation, and you can't achieve execution without a strong service oriented, process centric, model driven programming model. Not that IBM and Oracle are there yet, but they'll get there, make no mistake (Microsoft shot itself in the foot in that space when it put the mighty CSD "in charge" of solving that problem).

The question today is not, which pieces will go where, the question is going to be how can you influence these vendors to the right thing? In the end, they care about doing the right thing. Make no mistake. They are just poorly advised: BPEL is not a technology that plays directly at the business process level and no you should not attempt to reduce BPMN "isomorphically" to BPEL, at home, in the lab, at the OMG or anywhere else.

 Allow me to reiterate what I wrote in the "Seven Fallacies of Business Process Execution" article. The business, hence IT, hence IBM and Oracle, care about 4 things:

• Build solutions rapidly with projects as small as possible (rely on many iterations)
• Change solutions rapidly and support an iterative lean six sigma approach
• Be able to visualize the business design in operation at the present time without complex “current-state” projects
• Be able to gain operational intelligence from the current business design without complex measurement projects

In other words, Michael, the business cares about agility and visibility. Who said that the business cares about having a business-process-model-notation-to-execution engine? Who said you cannot meet these core requirements without a business-process-model-notation-to-execution engine? Ismael, Assaf, thank you for setting BPM on such a wonderful course, you guys deserve an industry award for such a service. Architecture and standards do matter, in case you have not noticed.

The business rarely cares when changes are implemented in two minutes or two days. Two days is a great first step ! The business doesn't really care if one person or two will be translating their business problem into a working solution. Who said the business wanted to eradicate IT? The problem you see is that in 2010, in the enterprise, you can't deploy anything of value in less than 3 months with a team smaller than 10 people -if you are lucky. This is a great improvement from the early 90s, where projects were commonly 2-3 years and 100 people, but it is not enough. We need more, especially on the visibility side.

So as long as the Bruces, Sandys and Scotts of the world will insist on the corny idea of "executable notation", as long as the the Michaels and the Franks of the world will tell you "we have a solution, slap a notation on BPEL, isomorphically map BPMN to BPEL", as long as that will happen, we will be in this vortex. Guys don't you think that trying for 10 years with the "best" minds of this world, PhDs, Professors, Hackers... is not the proof that it does not work? Don't you think that it is time to try something else? With the foundation that we have learned, of course. Don't throw away BPEL, don't throw away BPMN, just find a different articulation. How hard can that be? It's Win-Win all the way.

The vast irony of this story is that my 2002 articles are still referenced in BPMN 2.0. Somebody must like me very much to keep giving me this honor despite all that I write, but the only thing I care about is that their content be understood and that the articulation between BPMN and BPEL be designed per my recommendations.

The only path to move forward is to:

a) Give up on the pretty-picture-to-execution path for now, I don't know if it will be possible in the future, but give it up now, today, not tomorrow, don't create executable BPMN or a BPEL notation, don't, don't, don't.

b) Introduce the concept of business entities and business entity lifecycles both at the engine level and articulated with BPMN and design a service oriented, process centric, model driven programming model. BPEL at it's core is fine, someone might find something better one day, but let's start with it today.

Most of the theoretical work has been done by Ksenia Whaler at IBM Zurich Research Lab. The notation is here and it is good, the engine is built and humming. It is shovel ready.

Visit msnbc.com for breaking news, world news, and news about the economy