I no longer think that Domain DSL make much sense. Domain experts rarely have the semantic precision that would allow supporting their work with a DSL. Note that technical people don't exhibit much more precision. Just look at the REST space and see how people "interpret" the semantics of a resource, four verbs and URI. Ok, maybe the problem is that REST is so poor semantically that they "have to" add their own semantics, but still.

Recommendation 1: build your language for the solution space, leave the problem space to creative expression.

On the contrary, I would argue that the problem of limited expressiveness is precisely the explosion of "interpretations" of semantics. Again, use REST as an example. Please needed a query language. What happened? everyone created its own. It may not happen on the same scale in your organization, but it will happen enough to be a real pain.

Recommendation 2: Make your language as expressive as it is needed but not more

Text is beautiful. Do not mix the need for graphical visualization with the need for graphical design. Most often textual definitions can be converted (automatically) in graphics.

Recommendation 3: use graphical editors as rarely as you can. Prefer textual notations with graphical renditions

The goal is not to have everyone express something, the goal is to build solutions fast. The design of the language must be driven by how fast you can translate requirements into a working solution. Take the example of BPMN. BPMN was designed to let a certain category of people express their view point. That's great. When it comes to create "executable BPMN definitions", well the little known secret is that developers stuff the definitions with tons of arcane, hard to debug, scripts. This is highly inefficient. From my own experience, it can take 3-5 times as much to write a solution using an executable BPMN engine than writing it in 3GL.

Recommendation 4: design the language for rapidly building solutions (from as few viewpoints as possible) 

In MOP this best practice translates as rules that enable execution elements to control the lifecycle of other elements. The language needs to be one, however, you should restrict with precision the lifecycle operations a model element can invoke on another. I would not call that partitioning

Recommendation 5: understand with precision which model element control the lifecycle of other model elements

This is a difficult topic, MOP doesn't necessary help here. However, because MOP forces you to think through the entire lifecycle of the model elements and the relationships between the model elements at the implementation level, you may end up needing far fewer evolutions. DSL focuses only on the associations between model elements, not there interelated lifecycles.

Recommendation 6: Think through the entire design of the language, especially the lifecycles

We agree, yet, as you focus on the solution side, you should remain as generic as you can, what is wrong is the monadism of general purpose languages, not genericity per say.

Recommendation 7: Think polyadic programming languages

I would say, learn from both 3GLs and DSL. This is what MOP is about, bringing cogency and polyadism together in one efficient formalism.

Recommendation 7: Design Cogent Polyadic languages

You don't have to choose, this is the wrong choice. DSL forces you through that choice because second class citizens are created to implement the cogent aspects of the model. MOP focuses on first class citizens without the need of artificial model elements needed to express execution elements.

Recommendation 8: Avoid creating model elements to express execution semantics

I have mixed feelings about that one. Why would you create libraries and patterns in your DSL? They exist only because of the monadism of the general purpose languages. Programming Patterns would have never existed if programming languages were polyadic.

Recommendation 9: Rely on as few libraries and patterns as possible on top of your language, prefer a higher degree of polyadism

Go Textual !!!!!!!

Recommendation 10: MOP is textual in nature, structure your language to facilitate teamwork and leverage all the source-based tools

The bad reputation of Code Generation is due to the lack of execution semantics in DSL, i.e. DSLs are not cogent. MOP languages facilitate the transformation (not generation) into general purpose languages because the execution semantics are half way there.

Recommendation 11: Prefer "transformation" to model interpretation or code generation

Yes, but you can modify "transformed" code. Round-trip engineering in code generation can be very tricky. However, using a transformation paradigm in lieu of code generation make the round-tripping a lot easier.

Recommendation 12: You may use round-tripping safely when it makes sense, but avoid it if you can

I am not quite sure today, why the DSL community do not see how much simpler their life would be by making DSL cogents. I also don't see why the general purpose language guys keep annotating their language to death. They annotate it so much that they can't see the semantics behind their annotation. But, hey, what do I know? I am just a MOPer.

1. Standards sucks and are ever changing, they don't fit with each other or offer some kind of upward compatibility
2. REST is not as "easy" as some people would like others to believe it is
3. Innovation in 2010 is no free lunch, lots of people who don't understand a thing about innovation get in the way for various reason (greed, fud, ego...) and the innovators have to deal day in and day out with their stupid goals and constrains, not to mention unsustainable ROI

Thank you Lori. It's refreshing that someone is not talking about the Lalaland of XYZ and is not afraid of using "real" words, not to mention avoid bolonizing their readers. There are so few like you that it is worth mentioning.

Your post is also terrifying because it leaves little hope to achieve building anything right. Actually, the probability to get the right thing accomplished is as high as winning the lottery. In many ways, I agree with you. When you see products like the iPhone and you think at the alignment of technologies that needed to happen to realize such a device, only a strong culture and "proprietarism" can deliver any kind of innovation today. Standards are the wrong approach to innovation. They kill innovation. Pretending innovation is easy is the biggest lie of the 21st century. No, innovation is complex and requires a bunch of smart people working together without just ROI, greed, or fear as a driver. I think the next decade will see the emergence of new winners who understand innovation at that level. Of course, there are counter examples to my argument, company like WSO2 have innovated on top of less than optimal standards, but I think they remain the exception, and it is probably due to their strong culture and sense of values.

Stu also provided a follow up to my challenge to define a version strategy. Don't get me wrong, I like Stu, he is incredibly competent and he backs his work with a long experience. But, Stu failed to provide a compelling strategy for versioning. He actually admits that:

In a RESTful approach, URIs are your "foreign keys", and if you embed a version identifier in them, they need to change when you upgrade to the next version if you embed those versions in the URI. Assuming you can't convince your resource owners to use languages with version identifiers as a MIME parameter or inside the language itself, how is that done? 

 This is what I mean by REST couples access and identity.

Stu also conveniently forgets to speak about the "unit of versioning". Nearly every resource is participating in different lifecycles. A resource has different states, composite states. Each lifecycle has a set of actions (which are always encoded as POST+noun in REST). This is the unit of versioning. A comment from Mike actually speaks to that very problem:

there are many times when an application-flow update requires support for side-by-side versioning

Yeah, the RESTafarians finally touch the real problems or building real systems, not just blog posts and plain vanilla articles or useless annotations. I actually argue that without the visibility of an explicit lifecycle, these problems are impossible to solve. You can't version an action API if you don't understand the states and transitions behind them. 

Of course, people like Stu or Mike will never admit such a thing publicly. They will always say, "but... if you look here ... there is a promising solution that that problem". Boloney guys. Pure and complete boloney. We have endured 3 years of that boloney. REST is not a programming model. It has never been and it will never be. Deal with it.

I have ordered Subbu's book (hopefully he will give me an autograph), so I'll wait until I get it to make my final comments on versioning, but so far I think (reluctantly) that Stu belongs to the REST wall of shame. It is time to get real and provide real recommendations. Recommendations that don't let people loose like the ones that have been made for so long and got us where we are today, i.e. nowhere.

I see no success in sight and no sign of possible success either. The (other) REST is a fraud, nothing less, nothing more. Innovation is not "serendipitous" innovation requires hard work and courage. Innovation doesn't happen in pretty power points and IEEE articles.

RESTfully yours,

JJ-

Take this payment API. Is that RESTful?

POST /<path>/charge?version=1.0&endUserId=tel:+447990123456& currency=GBP&amount=1&referenceCode=ABC

Yes, you have seen it you POST a "verb" (the remainder of the API is all verbs to).

But that's not it, check that one. No you are not dreaming. You want to cancel a "reservation", you -of course- use DELETE, and just to be consistent, you use a verb (reserve) and not a noun.

DELETE /<path>/reserve/1234/release?version=1.0

But, who cares, right? the coders have already hidden all that CRUD behind code generators.  Check the kind of code that Bill Burke wants you to write to deal with Hypermedia. While you are at it, I would also look in Bill's post what the JAX-RS code look like:

@Path("/customers")
public interface CustomerClient {

   @Path("{id}")
   @Produces("application/xml")
   public MyResponse getCustomer(@PathParam("id") int custId) throws NotFoundException;
}

Yeap, this looks so much better and different than jax-ws:

@WebService(targetNamespace = "http://duke.org", name="AddNumbers")
public interface AddNumbersIF extends Remote {
    @WebMethod(operationName="add", action="urn:addNumbers")
    @WebResult(name="return")
    public void addNumbers(
        @WebParam(name="num1")int number1,
        @WebParam(name="num2")int number2,
        @WebParam(name="result" mode=WebParam.Mode.OUT) Holder<Integer> result)
        throws RemoteException, AddNumbersException;
}

Outstanding job guys ! all this brouhaha to get there. I am in awe. I am glad people get paid for that kind of "work". Some even call themselves "successful entrepreneurs" after producing a few annotations and a couple variations (no kidding).

Yes, REST has won. Not sure what we have won in return, but REST has. So, it is time to share some of the highlights of the Phyrric victory of the RESTafarians:

1) Dave Chappell - SOA is a failure : I am glad Dave gets paid to travel the world and propagate his boloney - what a job ! Dave (who doesn't write a single line of code) explains that for him "Reuse" doesn't work and the only services worth building are "Data Services". Why reuse don't work? Because:

Creating services that can be reused requires predicting the future… 

Dave, do you understand how reuse works in a distributed system? It is quite easy actually. You need a Forwards Compatible Versioning strategy. You can't reuse what you built 3 years ago, I actually agree with you. But, you can evolve services in a forwards compatible way such that the new version of a service (which was developed to meet the needs of a new consumer) works with all previous consumers without breaking them, and hence without requiring any changes from them. Something that your typical OO library can't do. Reuse in SOA happens the other way around: the old consumers reuse the new version of a service. That way you don't have to predict the future.

2) Stafan Tilkov - Code first does not work : yeap, another rock solid argument. Stefan complains that his code first approach creates "very large WSDL-files". First, REST does not change the footprint of service invocations. If your DTO (aka Resource Representation) is large in WSDL, it will be large in REST, just as well. REST is just a different encoding of the operations (using predefined verbs GET, POST, PUT). Second, You can't do SOA in a "code-first" fashion. I know, even Microsoft does that. I have explained many times that OO is the problem across our industry, any approach that tries to express new semantics on the foundation of OO is bound to fail. Annotating OO or wiring remote calls into and OO runtime is the wrong thing to do. OO is just a particular case of Metamodeling Oriented Programming. OO is not the foundation of programming, let alone software architecture. Semantics need to be expressed independently of the OO metamodel, in particular the semantics of the execution elements.

3) Steve Vinosky, Bill DeHora : The interface to a resource is uniform.. You don't hear that argument very often nowadays, specially after RESTfulie was published, yet it was the core argument when the 2nd invasion started.

... and the list could go, on and on. Stu, let's see what you come up with versioning. I do not wish to add you to this wall of shame.

I can demonstrate that our industry has lost tens of billions of dollars in productivity with these three flawed arguments. In one big swoop, the RESTafarians have prevented reuse to happen, crippled model-driven engineering and the emergence of a distributed programming model which could be the foundation to build composite applications.

In the end, you guys can claim all you want, but REST is just a "NO WS-*" movement. I am not here to defend WS-* or SCA, I don't work for a vendor. I, however, as a user of these technologies, have to constantly talk to people that are often completely confused about all these approaches (I mean really bright experienced people who now think that CRUD is a good way to build distributed systems). I sure wish our industry would have produced by now a nice distributed programming model and made all these discussions pointless. Everyone critically needs it. Unfortunately, as I explained before, there was not a chance, because everything is done from a monolithic programming model point of view, and somehow the gurus like Bill or Steve who had their chance at producing that programming model, project the semantic of a monolithic programming model (OO) into the distributed world. When these people looked at REST, they saw a distributed object paradigm that seemed to work. They looked at all the problems of CORBA (granularity of the calls, brittle interfaces, naming service...) and they felt REST solved elegantly all these questions. REST offered a universal naming service, uniform interfaces and DTO-size granularity. They said Bingo ! and here we are, only ashes are left, they burnt down everything. They have destroyed all the advances that were painfully conquered amongst stupid vendor politics and exacerbated egos. All gone: contracts, forwards compatible versioning, bi-directional interfaces, eventing mechanism, advanced coordination mechanism, assemblies, orchestrations,... you name it. REST doesn't offer any of them. REST brought our industry back to the a pre-Neolithic age and has enslaved everyone to CRUD. The RESTafarians made us lose another 10 years in our quest to built a true distributed programming model.

Congratulations on a job well done ! Mission accomplished !

As for myself, I am not in the business of creating "pretty stories" or attracting "followers". I am just too old-fashioned for that. 

You'll notice that Steve quickly passed the batton as soon as the D word (Demo) came about.

Bill Gates admitted this week to an OMG moment when he first saw the iPhone. In an interview with business Web site Bnet, Gates recalled when he first saw the iPhone, he said, "Oh, my god, Microsoft didn't aim high enough."

The state Legislature is considering a tax break for tech companies that want to build data centers in rural Washington after Microsoft moved its cloud-computing platform, Azure, out of Washington state last year.

I suggest that we universally, globally and locally remove any tax on any business activity. That way companies will make even more money and it will mechanically restart the economy while increasing positively the local, state and federal deficits. I suggest that we increase taxes on people because they can't go anywhere and they can't negotiate deals with the county or state or the federal government to make their tax bill more manageable. It will also increase consumer debt which is better for the economy. I propose to raise the sales tax 50% universally. Companies which would no longer pay any tax would have all the money they need to innovate. Of course.

Note that SAP has lost no time in making the world flatter and took matter in its own hands:

Although Plattner refused to specify the reasons for Apotheker’s resignation, he admitted that the company was facing growing dissatisfaction among customers in response to SAP’s decision to increase its maintenance fees and a recent employee survey also found growing disenchantment among its own staff. He also acknowledged that the cloud computing model poses a significant challenge for SAP’s underlying software architecture.

At the highest level, we think about innovation in relation to its ability to have a positive impact in the world. For Microsoft, it is not sufficient to simply have a good idea, or a great idea, or even a cool idea. We measure our work by its broad impact.

for a company whose products touch vast numbers of people, what matters is innovation at scale, not just innovation at speed.

Here is the translation in French of Frank Shaw's quote: "As long as we can make a bunch of money on our crap, who cares about what is pushed down the pipe? it is not sufficient to simply have a good idea, or a great idea, or even a cool idea. We measure our work by how much money gets in our bank account."

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