Carnets de bord


RSS source   [BlogRoll]


  • 09/12/07 :: [BPM] I am blogging again [permalink]

    I have started to blog again. This page is now archived, please visit the new page: https://www.ebpml.org/ebpml_radio.htm

  • 7/20/05 End of the roll... [permalink]

    I have decided to stop blogging on ebpml. Last June, my team was laid off after the merger between Attachmate and WRQ. I have since joined one of the big 4 software vendors and I feel this activity is incompatible with my new position. I really enjoyed contributing to the knowledge of the community and often got touching feedback from some of its members. I got acquainted with a lot of you and was happy to support innovative companies such as FiveSight, MomentumSoftware or Collaxa.

    Over the years I have expressed sadness that:

    • Concepts, technologies and specifications in the fields of B2B, BPM, SOA or Composite Applications were treated most often at a level incompatible with their usage in business applications.
    • From an architecture perspective, the leaders of the developer community were and are encouraging a conservative status quo of the application model at a time where it is critical to harness the possibilities of connected systems and change fundamentally the economics of software development

    Things are changing and some companies are now developing advanced "business infrastructure software". I have joined one of them and I am truly in owe at and fully aligned with what I see.

    The times ahead hold great promises for reaching new levels of development productivity and customization capabilities, unmatched in software engineering to date. The future of (business) software engineering won't be sloppy, you can quote me on it, it will be connected, semantic, agile and finally business focused.

    Thank you for your trust and your support over all these years.



  • 06/11/05 :: [BPM] Steve Ross Talbot  provides insight about what happened in Mars 2003 with the "Microsoft incident" [permalink]

    Steve, co-chair of the WS-CDL working group, sent me this text about 10 days ago telling some of the story the story behind the mysterious appearance and disappearance of Microsoft at the WS-CDL working group in Mars 2003. I would also recommend you read Steve's presentation on Choreography, if anyone disagrees about the necessity of choreography in an orchestrated world, I don't know what to do next.

    SRT:"Alas it is rather sad that people resort to "bullying" language like "join the one with the biggest muscle". It hardly does anything to add value to customers and does not solve their problems.

    Microsoft certainly did support choreography right in the beginning. Indeed a couple of senior Microsoft guys attended the first F2F meeting. They even presented their view. The view that they did present was that if the WG developed something that was competitive to BPEL then they would leave the group (it's all in the public minutes). If the group developed a contracting language for collaborative behavior then they would stay. Well guess what. We developed exactly what they suggested we do. Not because they told us to but because we all (WG members) recognized that we live in an eco system and because we felt strongly that we could complement BPEL by seeking to solve problems higher up the stack.

    When Microsoft did leave the WG I was often quoted as being "mystified" as to why they left. Well given what the Microsoft folks presented at that F2F and given that nothing was said about which direction we would go in during the following week it is odd - is it not - that Microsoft issued announcements to the press that they could not support the WG because it was not going in the direction that these Microsoft guys suggested. A WG in W3C is pretty democratic so it would be somewhat hard for it to make that decision within a week one way or another. I somehow doubt that even the great Bill Gates can turn Microsoft on and off that fast. So the language used by Microsoft was not accurate at all. In fact I think it is generally supportive of this "bullying" language that I described above. Clearly - for all to see - Microsoft does not and is not interested in solving customer problems. They appear to trash things they don't agree with on political grounds and certainly not on the basis of customer need or technological direction.

    It is a great shame to the industry as a whole that a company such as Microsoft, who have been pioneers in the use of pi-calculus, trash choreography on a continual basis - even though Robin Milner (the inventor of the pi-calculus) supports it. I strongly suspect that they are all suffering from "cultural lock-in". A syndrome in which if you say it enough you start believing in it. And I guess that is what has happened to Microsoft. Fortunately customers are just not so gullible. They evaluate on sound principles and take much of this with a grain of salt.

    Still I work away slowly with a fraction of the "muscle" but perhaps a good deal more open and rationale intelligence and against the odds the choreography working group will come out with a standard that adds value before BPEL and yet will serve to make BPEL more useful and not less."



  • 06/11/05 :: [BPM] Workflow Handbook 2005 [permalink]

    This book is published every year by the WfMC and edited by Leyna Fisher. This is a great vintage.


  • 05/21/05 :: [SOA] Composite Applications (SAP/ESA) [permalink]

    I caught this web cast from Shai Agassi: ESA: Today ! Enterprise System Architecture is the business architecture that SAP layered on top of SOA. The presentation is about an hour long but it is time well spent. Shai goes over the complete spectrum of NetWeaver / ESA capabilities. From the latest Office integration, to visual designers, to composite applications. They even show composite apps between SAP and PeopleSoft ;-)

    There is also an introduction from Taf Antias (CISCO), former CTO of IBM's MQSeries, who unveils CISCO's vision (and products) of intelligent network and how it fits within ESA.


  • 05/19/05 :: [SOA] Composite Applications (Mike Guilpin - Forrester) [permalink]

    I really like this presentation because it takes a holistic view at the Composite Application Model. The analysis of the current situation is excellent. I could not agree more with what is being said here.


  • 05/19/05 :: [SOA] Service Interaction Patterns [permalink]

    Alistair Barros and Marlon Dumas have created a web site which collects all service interaction patterns. This is very interesting because they go well beyond the WSDL patterns, which frankly have disappointed me a little bit. The authors also reference another interesting web site: Service-Description.com


  • 05/19/05 :: [BMP] The state of BPM standards [permalink]

    Michael zur Muehlen gave a great presentation at the BPMI Think Tank on this topic. I attended the last BPMI Think Tank in march and I am very supportive of all their efforts to enable the convergence between standards. This is new and critical to the success of BPM. Personally I would like to see a stronger link to SOA and its application model: Composite Applications, but this is already a huge leap forward for the BPM community.


  • 05/11/05 :: [SOA] Composite Applications: Value Proposition and Architecture [permalink]

    I have translated a presentation I had given in France last November at the integration forum. I also added a couple slides from Dave McComb which I think go a long way to explain why SOA and Composite Applications are attractive today. As usual feedback welcomed.  


  • 05/10/05 :: [SOA] Composite Applications [permalink]

    Composite Applications seem to become the latest buzzword du jour as an ultimate evolution of Service Oriented Architectures (could the SOA buzzword be worn out already?). Gartner had been talking about Application Platform Suites for a while. The SOA executive forum talked a lot about it. Microsoft has released a nicely architected composite solution: CCF. Edwin is also repurposing his BPEL engine as the foundation of Oracle's Composite Application story. I am expecting to see a lot more coming shortly.  


  • 04/27/05 :: [other] My daughter's first PPT [permalink]

My daughter (who is in first grade) came back home today asking me if she could use my computer. She asked me to start PowerPoint and started typing and changing background. She has mastered the logic behind it in one computer lab ! On another note, I bought my kids a Tablet PC and that was probably one of the best toy I bought for them. My 4 year old is able to do fairly complex games that would be much harder to master with a mouse. In addition, they are doing all kinds of drawings and writings with the MS Journaler. (Incidentally, I think for most adults, a Tablet PC is just a toy).

That being said, if there is anyone listening from MS or Google, it would be great to make kid friendly operating systems, office applications or search engines. It is all about "context". When I search on google (or MSN) why not specifying that this is a "first grader" requesting information about Martin Luther King for instance. This would make a big difference in their relation to the digital world.



  • 04/05/05 :: [MDA] Orchestra Networks [permalink]

    If you are suffering from XML fatigue like me, this could be one of the remedies. The EBX platform centralizes the management and deployment of XML files for any runtime. Most interestingly, Orchestra Networks has developed an approach that lets you manage variations of the XML metadata (development, test, production...) via their "cascading configuration engine".


  • 03/27/05 :: [SOA] Andreas Wombacher [permalink]

    The work of Andreas on Collaborations is remarkable and I hope it will be noticed by the BPEL and ebBP TC as well the WS-CDL working group.


  • 03/24/05 :: [SOA] Web Service Modeling Ontology [permalink]

    Today is the first time I came across this working group, so I am not sure if a lot of people are aware of it. This is great that somebody is covering this.


  • 03/21/05 :: [Architecture] Lattix [permalink]

    Some of the people I was privileged to work with at Eigner are launching their startup after about 18 months of hard work. This is one of the best engineering team I worked with in terms of quality, vision and speed of execution (not to mention camaraderie). So I was not surprised when I tried their latest product. Lattix is applying a relatively old engineering methodology (DSM) to software architecture. Design Structure Matrices have been applied successfully to a wide variety of engineering disciplines but this is the first time it is applied to software construction via some work done at MIT. An introduction on DSM can be found here.

    Lattix lets you analyze, visualize and constrain the layering of your code. Its parses your project (or jars) to create the DSM automatically. Software, unlike other engineering discipline, does not give us the luxury to "visualize" easily what is being build as Mark Masterson posted recently. As you build a house you get a good feel if it was "architected" right. Lattix is the first tool that allows me to "visualize" what is being built and somehow constrain it by specifying architectural rules. That's new and that's fresh. Lot's of us have tried UML and understand its limitation when the number of artifacts becomes large. DSMs are very different, they scale relatively well (I say relatively, because I am not sure the matrix notation is necessarily optimal here, maybe there are more compact ways to represent hollow matrices, but still Lattix is designed from the get go to work with very large projects). DSMs are about understanding the layering of a project and enforcing it. If you are working on a Java project I encourage you try for yourself, it takes about 30 minutes to get started. I will not be surprised if this tool becomes a must have next to Together, OptimizeIt and JMeter.


  • 03/19/05 :: [Other] BEA's online SOA Maturity Evaluation [permalink]

    I got the link via Olivier Rafal's blog at "Le Monde Informatique". The test is a series of questions relative to your current IT infrastructure and your ability to deliver SOA related projects. BEA identifies your company profile (one of 6) andThe  make recommendations. BEA seems to focus on business process modeling as the starting point for building an SOA. I guess I can't disagree on that one.

    I was pleasantly surprised to see that the first link they recommend to read is the presentation I gave last year at Penn State and Trento University. This presentation has been downloaded over 12,000 times in one year. It is probably time for an update.  You may also want to check a white paper I wrote recently on the Fundamentals of Service Orientation. This paper offers a discussion on ROI and SOA, as well as concrete a service examples and a 4 level maturity model.


  • 03/13/05 :: [Other] Business Collaboration over Web Services [permalink]

    Faisal Waris has published in his new blog a complete model for Business Collaboration using UML and the WS-* specs (including abstract BPEL). OASIS ebBP 2.0 which is now available for review is supporting web services, while providing a state alignment protocol which guarantees transaction semantics between business partners. 


  • 03/11/05 :: [Other] SharePoint goes Rich[permalink]

    It has been one of the most puzzling (and annoying) thing in Microsoft's Strategy for a while. How come the company who invented the "Smart Client" could found the strategy of one of its most important product line (Office System) on the sloppy old browser? If you ever look for an negative productivity tool, just run a document and form centric collaboration suite in a browser not integrated with outlook. Groove has banked its survival on the integration with SharePoint and that seems to have paid, big time, both for Groove and Microsoft. With Groove, Microsoft completes its ownership of the desktop from the browser, to the SmartClient to the Office Suite to now Collaboration and P2P. You add to the mix the latest momentum behind VSTO, and it is going to be hard to ignore this spectrum of clients where users can perform their day to day activities as part of enterprise or even cross enterprise business processes. I am wondering if Ray will move in that direction because today, the products are still quite discrete and SharePoint server is no BPMS.


  • 03/09/05 :: [SOA] Same Old Architecture [permalink]

    I like this quote from Gregor, who advised last week at the TSS symposium to forget about SOAP and design patterns. "The characteristics of a service are that it is well-defined and self-contained, independent of consumer context and accessible without individual deployment." +1. (I don't know if we should talk about self-activation rather than deployment).


  • 03/08/05 :: [SOA] Better than Google: Kartoo (well not just yet) [permalink]

    I don't expect you will switch to Kartoo anytime soon, mainly because I think their representations of the search results sucks and their reach for results is not as broad as the one from Google, but I just wanted to point out that no matter how useful Google search is (and I use it every day), it can be improved greatly by understanding the context of the requests rather than focusing blindly on what other people found useful. This is what Kartoo is about, it understand contexts and provides maps that let you navigate your search along a particular context, as well as refine the context. My friend Didier will be happy to know that his site (www.application-servers.com) is the center of the search map when we query for BPEL. Kartoo's representation also displays the contexts referenced by any given site. Obviously Kartoo has still some progress to make before it takes on Google, but what is clear is that Google has no notion of the context in which I am making my query, yet it is fundamental to almost every query we make.


  • 03/03/05 :: [SOA] Fundamentals of Service Orientation [permalink]

    This is a whitepaper I wrote for Attachmate. It seems that we are at crossroads for SOA. Lots of people are trying to analyze where we are and what is going to happen next... John Evdemon published a great summary. Phil Wainewrighit talks about the missing layers of SOA. Jeff Schneider talks about the evolution of computing (So shouldn't we talk about Service Oriented Computing rather than Architecture). Jason Bloomerg posted an analysis "Avoiding bad SOA" (via John Evdemon). Overall, what I see missing is the concept of "composability". Today we cannot afford to build IT assets that are not composable (as a model for re-use).


  • 02/27/05 :: [SOA] AXML (Active XML) [permalink]

    This LGPL framework, now part of ObjectWeb, is very impressive. It let's you create active XML document with embedded web services calls. It is even capable of optimizing the invocations when the documents is queried, rather than accessed in its entirety.


  • 02/26/05 :: [other] The state of BPM is strong [permalink]

    I am a bit embarrassed to say that I discovered 3 fairly big BPM companies last week alone: MetaStorm, Global360 and XicoBPM with very impressive customer bases. I also attended a presentation on a new BPM related product from Microsoft. Wow ! I don't think I could have been more impressed with the architecture and the tools. Apparently I was not the only one.


  • 02/26/05 :: [other] Turning off google ads [permalink]

    I played quite a bit with Google ads over the last 8 months in different contexts. It does not appear over the long run such a viable media. I would consider this is a "Jump Start" advertisement tool. I can see why it worked for relating Collaxa to BPEL, I don't see why it would be helpful to relate BEA and SOA for instance.

    A killer evolution of Google Ads is "Google-ized content". ( I have no idea what google is working on so this is not a scoop -I actually wished I could have patented that one), but what would be really helpful to me would be a content that has been marked-up by Google or say Amazon such that all 'key" words point to either: a point of purchase, a web site, a google search, a dictionary/thesaurus, ...

    I must admit I am not a superfan of Google anymore after the sloppy discussion, though I am certain we will look back at the 2000s and for sure realize that Google was one of the major innovation of that decade. I have had a computer on my desk since the late 70s (started with a TRS-80 and an Apple II). It is quite interesting to actually look back and list the applications that appeared on your desktop in each decade that you have kept using since. Google comes to mind immediately for the 2000s, the next one is Groove (say file swapping applications). I am wandering if Skype will make the list at the end of the decade (VoIP has been on an off for a while now).


  • 02/20/05 :: [MDA] mOOdel [permalink]

    I discovered recently Mark Masterson blog. Certainly worth adding to your blogroll. There was a lot of discussions recently on this article from Richard Mansfield. Not to mention the discussion between Clemens and Hartmut. I discovered OO in 1991 at Penn State with NeXT and Objective-C and wondered about it. I shared this wonder with my students in the years that followed. They had no prior exposure to OO and like me they wondered: their mind changed for ever after I had introduced the principles of OO, they could not think without them anymore.

    OO has gone in about 15 years from a mind opener to a mind bottleneck. Why is that?

    If we consider that the paradigm shift that OO introduced was not a new programming model, but rather the introduction of modeling concepts into traditional programming language we might understand why today we are hitting a wall. It might also help us break that wall. Actually, this wall is a double wall. Today we need to evolve both the modeling capabilities and the programming foundation. Cw from Microsoft Research is the best proof of this double evolution. I have written many times about making the message a first class citizen of the programming language and enabling peer-to-peer computing (aka connected systems). Bertrand Meyer had eloquently proven at ICSOC 2003 that OO cannot deal with concurrency very well, in other words the granularity and programming model of an object don't let you create (autonomous) "peers". So I won't write much more on that, I would like rather to focus on "modeling".

    The Class/Instance abstraction provides generic modeling capabilities. In other words, I can create models (very efficient ones, specially when it comes to model physical things). Since the advent of XML we might have loose track that you don't necessary need angle brackets to create models. Instantiating a collection of related objects from a piece of code let you create models (the piece of code in question is "the" model). The only thing that XML has given us (almost for free) is the notion of "metamodel". When you create a series of classes that work together and you "create" a model in code, this code does not yield a metamodel necessarily. Another major difference between OO and XML is that in OO the model and the model implementation are part of the same environment, using the same syntax, as opposed to XML, which of course cannot be used as an implementation language (it is already hard enough to use tags for documentation in .Net). If I had to say I learned only one thing over my 24 year career as a software developer and architect, it is that you should always be aware of the semantics (the meaning) of what you are doing. It does not mean that you have to spend a lot of time creating complex semantics but instead of learning the GoF patterns, I would rather encourage people to know the semantics of what they are using in their everyday coding life. Let me give you an example. "Events" are cool. Their semantics are "fire and forget". If what you are going ever need a "response" back from that "event", don't use an event. Another semantic that is completely absent in OO is "state" for crying out loud. There no "explicit" states (and transitions). A developer has to model state from scratch and a class is not necessarily the best granularity for that. That missing semantic is probably responsible, just by itself, for a lack of productivity of 10-20% across the whole software industry. The real OO killer today is the lack of composability. Unless you plan really hard to do otherwise, writing something in Java or C# is like pouring concrete (not even in a sloppy fashion): you can do really nice thing with it but once it has dried out, the pattern is "break and rebuild" not "compose and reuse". Any technology that can support composability of assets will win. (I will resist to add my traditional rant on sloppiness at this point).

    So OO as we know it, i.e. classes, interfaces, instances, methods, inheritance, containment will fade very quickly now because it is a formalism completely antiquated with today's world (composable connected systems). The principles will not disappear but will be diluted in larger semantics. This is why I don't fully understand the position of the Indigo team. On the one hand they understand the need for more semantics (they introduce the notion of contract at the foundation of Indigo) on the other hand they force fit these new semantics within the boundaries of the OO modeling capabilities which are completely "d�pass�es" as we say in Frrrrench. This approach is bizarre since Microsoft itself is pushing the envelope on OO (C#, Cw). If I could ask only one question to Don this would be this one: "why use an OO interface to map to a WSDL? Don't you see that the semantics are different both at the interface and operation level?"

    So I could spend some time explaining why the class concept does not work in a multi-tier environment or complain that developers have become CPI "scripters" (class programming interface). But who cares, the question is where are things going to go next? The immediate evolution is MDA (I call that "path of least innovation"), we got everything in place (programming language on one side, meta-modeling facilities on the other, the tools will make the two work together as one) so why bother doing anything else? Is the sloppy index good enough? I certainly hope that won't be it. I hope that semantics get added to OO modeling capabilities (e.g. Message, State, Service, Activity,...). I just know that patterns are not the way forward and reifying everything behind existing semantics will create absolute chaos in software engineering. Now can someone really smart bring together both the modeling and programming aspects like OO did in its time? I hope, it is never very productive to have to cross boundaries like XML Schema / XML / Programming Languages. The question is for me when will we see a model{...} syntax? like we could see a service {...} syntax if someone had two ounces of innovation and one milligram of guts. Or is the "tool" the answer? in other words, there is a finite way of combining the 128 ASCII characters or so, and we cannot create more syntax other than meta-syntaxes like XML.

  • 02/19/05 :: [other] print.Google [permalink]

    Recently Google announced royally that it would fund a project to digitize the content of four (english) libraries.
  •   (Dobritz) 
    An interesting article (in french) relates that it happens that Google is also launching an unrelated print.google.com service that adds to your search results the "sentences of recently published books". It would be surprising if Google does not go as far as adding a few commercial clicks where you can buy the book of interest. What would be a better incentive to both publish to and use that service than the foundation of four libraries?

  • 02/17/05 :: [SOA] Suggestions for SSDL [permalink]

    I don't mean to overly criticize SSDL as both the spirit of a "community" standard and the new approach to service description are refreshing.

    I still think that componentization is not enough and you must completely separate interface definition from binding (many types of bindings can be created). It will also encourage people to reuse interface definition as they will be published as independent artifact.

    the second fix I would to WSDL is at the binding level. As you may be aware, there is a new WS-standard coming up (WS-CDL) which allow for description of peer-to-peer interactions. However, I am not completely sure (I have to look at it) that the bindings to WSDL (and within WSDL) support peer-to-peer interactions. Ultimately, WS MUST SUPPORT PEER-to-PEER interactions. Note that for me this is what is a contract (how two or more interfaces may interact together). I am not a vocabulary guy so if you call interface contract but you have a concept that make two contracts work together, I am fine, I just want to make sure that both are semantically different.

    The 3rd thing I would fix is provide the ability to provide more semantics to operations (or message exchange patterns). The type of semantics that come to mind are:
    a) Resources: does this message contains a representation of a resource (Order, Customer,...)
    b) behavior: what is the MEP allowed sequence
    c) message type: signal, event, ...
    d) MEP type (see the latest OASIS ebBP spec)

    I think the modular approach of SSDL can later support these semantics. Note that these ideas are not really mine, I am just translating some of the ebXML architecture in requirements.

  • 02/14/05 :: [SOA] The SOAP Service Description Language (SSDL)[permalink]

    Savas Parastatidis and Jim Webber have published a spec on their own. I am actually surprised that the "community" did not felt earlier that it could do a better job than standard committees. SSDL targets WSDL, this is not surprising. If one of the goal is "better componentisation", I was disappointed to see that Savas and Jim inherited the same flaw as WSDL, i.e. a lack of decoupling between the interface definition and its binding. What is the logic behind coupling them? Why not describe the interface in an abstract way, independent of its binding to particular endpoints? This is different from componentization. I am also puzzled with the fact that some people are using the word "contract" to describe an artifact that is unilateral. The webster specifies that a contract is "a
    binding agreement between two or more persons or parties". I know contract sounds sexier than interface, but I wish the WS-* community would actually work on a real contract definition.

  • 02/10/05 :: [BPM] Comments on jBPM[permalink]

    JC Reddy comments on jBPM metamodel. We both agree that UML activity and state diagrams are a very antiquated way to look at BPM. It is simply annoying that anyone can label their stuff "BP" no matter what it is or what it does.

  • 02/09/05 :: [other] Google Maps[permalink]

    (via www.Applications-Servers.com) Google is on a mission to help you find anything you need. This is the latest instance of their technology. I bet most of you will switch to Google maps today for any geo-spatial query. Now of course the question I have for Adam is whether a web browser is the best client for using it?

  • 02/09/05 :: [SOA] Introducing Indigo: An Early Look [permalink]

    (via DotNetGuru.org) David Chappell wrote this article (I was sitting next to him at the last indigo SDR). If you wandered about the details behind Indigo, now you could wonder about them. I particularly like the "contracts" which are at the foundation of Indigo (Take a look at the data contract). The only thing I did not like is its "client/server" paradigm. In other words, Don is force fitting services behind OO concepts (interface). So when you need to create (god forbids) a service that has inbound and outbound operations you need two interfaces. I wish we could have bent the Interface" concept to match it to WSDL capabilities. Other than that, the programmatic binding definition is really nice. Overall, Indigo is going to be a keystone of SOA.

  • 02/08/05 :: [SOA] The path to BPM II [permalink]

    Radovan responded positively to my last post. Thanks ! I thought for a second I was the only one thinking along these lines. I would like to emphasize like him that "state" is very important and not well enough separated from the resource content. Yes, this is another thing that REST doesn't care about even though REST is all about "state". If you take a purchase order it has a content: the customer, the line items, the shipping address, the purchase agreement,... but it also has a "state": issued, accepted, processed, shipped, received, paid, returned ... I think the latest working draft of WS-CDL has brought back the notion of state inside the spec but I did not have time to investigate it further. I also think like Radovan that BPEL/WSIL/WSRL could be used for managing that "state", in other words, a purchase order service can only receive or issue some messages when the PO is in a given state. You can't cancel the PO if it is in paid state. In that respect, yes we could also call it WSRL. Personally, I would like to see that state managed by the service implementation this is why I like WSIL better, but at this point, I would settle for anything that does not start with "BP", that is articulated with WS-CDL and that can deal with conversation instances, outbound messages, transaction and reliability. I hope Systinet is working on something like this and can share it with us soon.

  • 02/03/05 :: [SOA] The path to BPM [permalink]

    WS-* continues to be cooked up, yet lots of WS are being built and used!. SF.com mentioned that 1 in 5 calls into their data center is a SOAP call. Companies like Systinet seem to have also a lot of customers building big SOA projects.

    So here we are in 2005: we still don't have EndPoint references, RM, Transaction, we kind of have a bit of security, not to mention that people are confused about BPEL and therefore they are not really rushing to buy BPEL products. Data 'flows". If web services created the pipes to flow this data relatively seamlessly, we are still missing the grand vision of SOA, i.e. an engine behind SOA, a BPM-based engine behind it.

    What I think would be a great goal for the WS community is get all these specs done sooner than later. I would also go as far as suggesting to the BPEL team to give up on the confusion around BP, B2B..., I won't go as far as suggesting a name for it but something like WSIL (wisel) Web Service Implementation Language would help clarify the concepts. I would also suggest the WSIL team to get together with the WS-CDL team and make these two pieces work together, anything less would be a disaster for our industry. I wish the chairs would understand how much responsibility they hold at this moment in time and adopt a adequate behavior.

    Actually, before we do all this, we also need to fix WSDL just a bit. I cannot tell you how much disappointed I was to read that the WS-I recommends that people don't use outbound operations. The only (good) reason why they recommend that, it is because the WSDL operation binding is broken, in other words, yes, I can't have a valid WSDL containing outbound operations until I identified the "consumer" and the "producer". ebXML has solved that problem with its architecture (eBBP / CPPA).  In other words ebXML is using a double binding, a profile and an agreement, while WSDL only uses one. WS-* must adopt a similar architecture. Once all these pieces are in place, and only then we will be able to build a viable BPM infrastructure on a peer-to-peer SOA. The terrible thing is that is WSDL does not get fixed, we will have a split in the stack and the concept pushed by Gartner around EDA will emerge, what else will be flawed there? How many years would have we lost in that process?

    I know most of you personally or in person and respect your work and contributions, Tim, Patrick, Steve, Martin, John, Diane, Frank, Yaron, Don, Francisco, Felipe, Satish, Stephen, Chris, Chris, Yuzo, Kevin, Mark, Eric, Layna, Jeanne,... and many more. Your leadership has got us where we are, i.e. really close to where we need to be. Isn't it time to finish the job?

  • 02/03/05 :: [SOA,BPM,MDA] Microsoft Office Developer Conference [permalink]

    I attended the first two days of the first MODC. Microsoft introduced the notion of the "Office System" which spans from SharePoint Portal Server to Word. Microsoft gets it when it comes to leveraging SOA to build Workflow/BPM and Office solutions. Interestingly engouh MS does not have a workflow product per say. I was really impressed by K2.Net who provides a very complete and scalable workflow product, at the end of their presentation the whole amphitheater flocked to the stage to get the demo CD. SalesForce.com introduced the sforce platform integration with Office. The lesson's learned from SF.com is that SQL does not marry well with WS-*, no news there, Jeff Schneider pointed out it recently too. I was happy to see that SharePoint Portal Server is using the orchestration capabilities of Biztalk to create complex service interfaces,i.e as a programming language. Microsoft is delivering on a new pattern (Activity-Coordinator-Resoource-Service) that will progressively replace the MVC pattern in the application model. They are transforming Office applications into a place where information workers can perform more and more activities while buying into the vision of wrapping line-of-business systems behind services. The 3rd party workflow engine acts as coordinators.


I still think that Microsoft is missing a BPM vision, locked in by the Biztalk server and without a real integrated workflow backbone. I would not be surprised if an acquisition happens there looking at how much a hole it is in Office System. However, with the concept and release of "Office System" Microsoft is coming one step closer in the direction of BPM, though there are many more to come.

  • 02/01/05 :: [BPM] Howard Smith: "BPEL is a programming language"  [permalink]

    An unexpected paper ("The Next Generation") from Howard about BPEL, pi-Calculus, composite applications, SOA and BPMS. At least we now agree on one thing: BPEL is a programming language (best represented by BPEL-J). I am wondering if he recalls that BPML was a copy of BPEL (or vice-versa) and that this article could have been written talking about BPML just as well. Under his leadership BPMI has spent four years trying to develop something that he now dooms as unsuitable for Business Process Modeling. One thing we strongly disagree about it the notion of a massive "BPMS". OASIS ebBP 2.0 will be out momentarily and demonstrate how business processes can be modeled after a series of cooperating agents. This architecture is completely decentralized (or more exactly requires minimal centralization a la WS-CAF).


  • 01/29/05 :: [MDA] Modelware [permalink]

    Lots of stuff going on around "Model Driven" software engineering. I highly recommend that you take a look at this project funded by the EU: Modelware. One of the goal of the project is to create an Open MDD (Model Driven Development) platform based on Eclipse. Wow! Another project is CARROLL that seem to be focused on MDD for real-time systems. MDD has also a conference lined up for 2005: European Conference on Model Driven Architecture.


  • 01/24/05 :: [MDA] VS 2005 DSL [permalink]

    Over the week-end I got VS 2005 DSL (December preview) to run (unfortunately, it is not too easy to get all the rights bits at the same place). This latest version supports end-to-end scenarios from specifying the metamodel to automatically building a graphical metadata editor. Wow ! It works. The graphical designer meta-model is quite sophisticated and let you choose from lots of options. Metadata is created in a proprietary format, but that's ok, the great thing about metadata is that it can be transformed.

    Very few products in our industry are developed with a vision, just one feature at a time or based on the latest buzzword. Some even think that "being sloppy" is the vision. Keith Short and his team have articulated a very strong vision and they are delivering on it. DSLs are the future of computing. They are in the direct line of evolution by creating the environment that will spring domain specific virtual machines (the run-time associated to a given DSL), just like the concept of Operating System VMs were a major evolution in the 90s with the concept of "managed code".


  • 01/12/05 :: [MDA] Keith Short on DSL [permalink]

    I wanted to re-post a link to Keith's seminal presentation on DSL, in cased you missed it, I strongly recommend you sit back, relax and spend the time digesting it. He is probably one of the brightest guy in the industry at this point in time. This is the future of software engineering.


  • 01/10/05 :: [MDA] Basic Principles of Model Engineering [permalink]

    Literature on MDA is still rare. Jean B�
    zivin from Nantes University has prepared a masterpiece on MDA or "Mo

    del Engineering"


  • 01/05/05 :: [MDA] Language oriented programming []

    Eric Newcomer's blog, here is a great example of forward thinking towards productivity. I did not see much sloppiness in this article but rather a careful analysis of what is broken in software engineering and a well thought out solution. I am glad that it is not just Microsoft promoting this kind of approaches, it is a real industry momentum. Wow ! 2005 sounds very exciting. I wish a great year for everyone.


  • 12/31/04 :: [SOA] Why IT doesn't matter for now?[permalink]

    Adam, I wanted to make some of my arguments very clear, in case you want to discuss them.

    1) Abstraction: when abstractions are well defined productivity dramatically improves. XL, RDBMS, CAD are great example, LabView from National Instruments is also a pretty spectacular example. Great abstractions enable tolerance (not sloppiness). In IT today, business abstractions are ill defined. Many attempts have been done from BOCA to OAGIS. No matter where you turn to: security, EJB, JDO, B2B, BPEL, WSDL, RDF, ebXML ... nobody has found the correct set of abstractions to achieve the same level of productivity increase that IT is giving to some its consumers. I am sure hundreds of PhDs have been thrown at the problem but so far little progress has been made. It is almost like the string theory, lots of bits and pieces here and there, most of them great work, but still an elusive grand unification.

    2) MVC: MVC was invented in 1978 at Xerox PARC by
    Trygve Reenskaug. Job well done, MVC was a great pattern, incredibly productive. But it is one of the core problems of the application model today. Amongst other things, MVC does not provide explicit user activity boundaries. If a user activity spans more than one view we need to maintain ad hoc complex state machines. The code has no idea when the user starts and ends an activity, in which state the activity was ended... Business processes are not explicit, everything is hard coded in the  controller, impossible to manage and monitor independently. At the model level, the pattern does not put any constraint on domain abstractions. The most terrible property of the pattern is that it offers no composition capability. Don't people end up coding more views, more controllers, and yes more models simply because all they have in stock does not exactly fit the new context of utilization they want to provide. Interestingly enough, Reenskaug had called his pattern "Things-Views-Controllers" in its original paper in 1979. For me MVC is a "micro-pattern" not a "macro-pattern" i.e. it is not a worthwhile abstraction that can be applied in large scale. It is pretty obvious to me that something like a "Service-Resource-Activity-Coordinator" pattern will emerge out of SOA and will supersede MVC. This is why I say, web application model as we know it will disappear, i.e. be buried behind a new layer of abstraction, because this application model (J2EE or ASP.NET) is nothing more than an MVC cookie cutter. It is part of the problem. Making it sloppy by design or by accident could only compound the productivity problem created by MVC. I actually thought that Edwin had convinced you of the incompleteness of the J2EE application model. To be fair, the things that web apps are really good at is creating apps that marry content with data. The thing I argue about is that if you are building complex information system (and want to use the fantastic attributes of a browser), then this is a terrible model.

    3) Solution: yes, solutions contribute to the lack of differentiation between companies, but worst of all they contribute to the lack of internal efficiency within the companies that use them. Now matter how customizable they are if they impose too much of a data model or processes they prevent their users to do what's best for their business. To give you an example, in my previous job one of our customer had used our solution to build a front end to a leading ERP system and he had replaced 22 windows with one in its procurement process. I am sure this ERP vendor had its reason to require 22 windows, I am sure their PMs had done their job and they concluded with these 22 windows they could serve all the need of their customers (adoption), but what they could not do and will never be able to do is to give a solution that does what's best for every single customer (productivity).

    4) Integration: the problem is not find better ways to integrate like an ESB or even use Web Services only for integration. The problem is to get rid of Integration altogether via normalized models or more realistically reduce it to a minimum. There is no value in integration, this is a pure cost. Interestingly enough, SF. com is so easy to integrate with that companies offer "connectors" for it (e.g. pervasive). Hum...

    So why doesn't IT matter today? Here is a slide I presented at the last Integration Forum in Paris last November. It shows the cost and the value (Y axis) of an IT department with respect to the number of systems installed and managed by this IT department. I made up the curves, but I think we can agree on the trends.


    The cost tends to grow exponentially because of the cost of integrating monolithic applications, managing them (just keeping them up and running), and maintaining them (dynamic schema is a very very small piece of the problem).  The value tends to level off fairly quickly because lots of projects become just incremental improvement in the life of a department or business unit. You can also argue (ok, this is controversial) that the value can decrease. The reason is lost productivity as soon as a user has to deal with more than a few apps to do its job. Web apps don't help that much (just a bit), because it is really a questions of context switching, errors rekeying information, ... it is not so much having a nice looking uniform interface.

    IT does not matter today because most companies have reached the cross over point. After you reach that point you are going to put yourself in the position "What if I don't do anything". This is not because CFOs don't get it or because they are adverse to risks. If you can clearly show ROI within a year of operation or so, CFOs will invest. If you tell them ROI will be achieved after 10 years, they will give you the platonic look. And in any situation this is a good thing/business practice to move this point upward because you increase the value that someone can get from something.

    SF.com killed Siebel because they understood that very curve and Siebel did not. Did SF.com resolved the fundamentals of that curve? Did they move the point of no return upward? Just a tiny bit, above all they just found another trick to ramp up adoption by passing the CFO decision or better yet, by going undetected by the CFO. Ok, I am exaggerating a bit, but I am just trying to get a point a cross not defend or attack SF.com.

    Interestingly enough, there is probably a similar curve for search engines that explain the success of Google. When someone searches something, s/he spends some time to get some value. Google algorithms which measure relevance found a way to move the point of diminishing return higher than anyone else in an automated way. The algorithm has side effect, but overall it beats all the others in terms of productivity. Sloppiness, or fuzziness in that case is just a property, not necessarily desirable, but how could Google do otherwise?

    If you agree with this interpretation and think that the "utility" interpretation of N. Carr is an effect not a cause, the question becomes, how do you move the point of ROI higher in the curve? Because people will never cease to build information systems, they just need to build them faster and to their needs.

    1) Provide a very productive application model for business to develop what they need - don't tell them what they need. yes being tolerant (I don't like "sloppy") improves productivity.

    2) For anything that is built or installed in IT, provide an application model that is conducive to reuse of existing assets, stop the bleeding, don't build new assets

    3) Provide an application model that reduce the need for integration to a minimum.

    4) ... I could go on an on, I am sure you get the point

    Any hope somewhere? well we have SOA or as some people call it "SOC" (this is not just ideas, this is a full computing model with which you and I can build apps). Looks like everybody sees some kind of light in SOA: customers, infrastructure & solution vendors, SIs (solution vendors seem to be lagging behind a bit...) Could we use this momentum to do great things? We are far from done inventing this new magical application model, but one thing I am totally convinced of is that it will be built on SOC. Can we built it to be "sloppy", sure, people have done that before. Do we need it to be sloppy? well define sloppy, but, another thing I am sure of, is that this application model cannot change the curve above, i.e. cannot make IT matter again if it is not based on a very productive abstraction of the problem at hand. Do we need a bunch of PhDs to deliver that abstraction? I am sure a few would not hurt, this is not the point, it is not whether you need PhDs or not to do something. I got mine at age 24 and never looked back, never felt that I was entitled to anything, different, smarter or that this piece of paper will let me achieve greater things than someone who did not have it. Above all you need a vision, the will behind the vision and whether the vision is economically sound or not -this is what really drives adoption. 

    The most interesting property of SOC is "composition". Resources (XML) are composable, services are composable, coordinators are composable, with a bit of foresight we can also make activities composable. Frankly, I think this was achieved by accident. I don't know anyone that stood up one day and said that this whole thing should be composable. But if there is one property and only one that people should focus on is composability not sloppiness. Composability helps create assets that can be reused outside the context for which they were designed, sloppiness leads to the creation of assets that cannot be reused. Have you ever tried to reuse a web app? the assets created for a web app?  Composability is the real flexibility that is needed.

    Before I conclude, I would like to throw a quote from T. Reenskaug: "Any method that prevents the programmer writing code, is a good method". In other words, the real KISS principle is the one that leads humans to specify the least amount of artifacts possible to provide the best solution to a given problem, rather than having Legos or infinitely flexible or sloppy technologies. The automotive industry, the construction industry, actually most highly engineered industries have understood that principle but not the software industry.

    I hope I have convinced you that: sloppiness, web application architecture, monolithic solutions and integration are by far not the way forward, they are the problems of our industry. What I suggest is: productivity, composable abstractions, SOC, services & minimalist solutions, zero integration.

    It makes me sad that you could go to ICSOC and tell them that all the heart and mind they are throwing at the problem is irrelevant rather than encouraging them: SOC is the way forward because IT needs a massive realignment towards productivity. This is not a dream. Now, you know what my nightmare is.

    Jean-Jacques Dubray

  • 12/27/04 :: [SOA] Adam Bosworth responded to my post...[permalink]
    Adam, thanks for taking the time to answer my post (Apologies, I just found out a few minutes ago about it). More apologies, this is another indignant post.

    I was surprised to read the central argument of Adam's response: ...the problem IT faces isn't sloppy languages. It is irrelevance. For much (although certainly not all) of the work IT does, IT is like children building sand castles on the beach and watching the tide roll in. That tide is highly customizable web based solutions, Salesforce.com today, perhaps Talaris tomorrow." Aren't we in violent agreement? Isn't IT cornered to use Salesforce.com (nothing more than a Siebel NG) simply because there is no technology that let it build what it really needed. Isn't there a direct correlation between sloppiness and irrelevance? IT tried the sloppy ones already, those are the sand castles. How can an infrastructure vendor be satisfied when he has handed the keys to the house to solution vendors? How will BEA ever compete with Oracle and SAP? I don't deny the need for solutions, it is after all an efficient model -especially to deal with widely accept rules like government regulations, but by promoting them as "the model" you are negating the specificity of every business. Infrastructure vendors have simply turned off any hope for businesses to compete on the IT grounds. I am sure SAP loves this idea. At my previous job (a solution vendor), it was stunning to see what our customers wanted us to do. They had the creativity in their heads but not in their hands. No offense to any solution vendor product management team, but how could a product manager, no matter how bright s/he is, ever understand what makes every single customer special? Enabling creativity is the future of IT.  With that respect, even if SF.com goes in the right direction in terms of productivity, it is a dead end for IT. And this is precisely why IT doesn't matter because people like you don't care about the customer needs, their creativity, they even attempt to justify how we got there, they have given up. All they really care about is adoption. SF.com is just a better mouse trap than Siebel, but it is only a mouse trap. How could you be so naive to think that the "solution" is the answer even with a dose of productive customization? How could you argue now that development is over, that only a few specialized solution vendors will control it? This is an argument that is even worse (and as much flawed) than the one about sloppiness. Yes, the days of Javascript as a development language and an application model are counted, probably even J2EE as we know it, but not the days of business critical information systems. How often do you talk to the developers? how often do you ask him how much he enjoys working with sloppy technologies such as HTML and Javascript, what this has done to his work, productivity, morale and self-esteem? overall to his job? How many J2EE projects were hurt by these "sloppy" technologies? How often do you talk to customers? Do you see all their needs and desire reflected in customizable web apps? I don't.

    The way out for our industry (customers, infrastructure & solution vendors, system integrators) is called productivity for creativity not sloppiness or a single mold for the masses. You are not pointing it out, but sloppiness is not responsible for SF.com's well deserved success (hopefully this is not a transitive property) it is rather productivity and above all new form factor, actually not so new because it is called ASP. Similarly, Google was successful not because it returns fuzzy search results but precisely because it is a highly productive tool, far more productive than was available then and today. This is how Google earned its letters of nobility. And actually, Google's future will be built on productivity not sloppiness. Who could believe otherwise? Do you?

    Software engineering will hardly ever cease to re-invent itself while touching every aspect of humanity.  This is power, this is responsibility. Your recommendations are irresponsible. Javascript, HTML and Salesforce.com are not a model for the future of software engineering. Please spare me also the piece of Americana about supply and demand. I have been around long enough and worked with many product management organizations, some sloppy, some extremely bright and attentive to the customer, to know how product managers understand and translate "customer demand" into products via the engineering prism. Now don't get me wrong, I don't deny the significance of technologies that are widely adopted and easily accessible without lot's of training or PhD level expertise. But, please don't claim that this is anywhere close to be relevant to software engineering. Adoption by the masses is just a product feature, not a MUST HAVE property for any product or technology.

    Adam, we are at the dawn of a new application model: SOC. SOC is not merely a simple evolution of distributed technologies -i.e. a better integration point as you relegate it to. SOC is rather changing fundamentally the form factor of applications: from monolithic to an open set of services enabling the creation of new contexts of utilization without technical or physical boundaries. Amongst other things, by changing the very concept of what an application is, it should and will change radically the ROI of IT projects. SF.com (i.e. solutions) and ESBs (i.e integration) are nowhere near there. They are just the byproducts of sloppy product management and engineering -a better mouse trap without vision, a pyramidal scheme. I urge you one more time to reconsider the argumentation you developed at ICSOC and in your last post. You have the power, you have the responsibility. All this industry needs is to listen to and empower creativity with the right technologies, not create a "Widely Adopted Soup" (WAS) where one size fits all and with which nothing significant can be accomplished at a reasonable cost. This would be the best lock you can put on universal creativity. I would be very surprised if this is your goal. If you care to read it, I can send you a preview of a paper that I have written on the topic.

  • 12/20/04 :: [SOA] IBM's BPM Strategy, Products, Architecture[permalink]
    BPM has been my hobby since 1997. I have been the editor of the ebBP 1.1 spec and I am in the process of completing the edition of the 2.0 edition. In 1999-2000, I worked on a BPM-based B2B integration server and really thought B2B would be enough to make BPM take off. I think even the Biztalk server team made this assumption. Little did I know. In 2001, I moved on and was privileged to work for a PLM solution vendor, Eigner, the company founded by Martin Eigner. In a split second I understood that the key to BPM was the application model of solutions. As long as applications will be built the way they are built  today BPM will remain this desirable but marginal technology. (or could it be that  BPM is not sloppy enough to be adopted by the masses?).

    So when IBM comes up with a plan I listen. Paul Harmon wrote yet another masterpiece, smart, insightful, complete, precise. We are getting there, with "BPMS Applications" (i.e. an application that implements a process that can be examined and changed): an application model is finally on the map (figure 3). There are not that many such applications unfortunately. I still think that we need to go one step further and not talk about applications but composite applications (Don't business processes cross application boundaries?). I gave a presentation at the Integration Forum forum in Paris about the relationship between composite applications, SOA and BPM. This is where the future of BPM is. Actually, this is probably where the future of SOA and Composite Applications is too.

    Though it is precisely correct, Figure 3 is also very depressing. It shows how fragmented the BPM market has got to and how little chance there is of a good enough consolidation between tools, engines, EAI, management, BAM... So what to think of IBM's consolidation of its own stuff (Figure 5). How can IBM succeed stitching all these products together? More depressing, IBM is relying on Siebel and PeopleSoft (huh?) to provide software components to implement "specific process activities". Don't hold your breath. This picture tells me that the IBM machine, after spending probably one or more billions developing all these products, has no clue about delivering a BPM vision. What IBM has developed here is a Middleware Process Management solution. MPM is useful but it is not BPM. I would not be surprised if Edwin and his team at Oracle get it because Collaxa showed the way to change the application model. Considering how much solution space Oracle now controls, considering that Oracle is a one stop shop application infrastructure vendor, the best chance for BPM to take off today is at Oracle. I'd be surprised if they mess it up. SAP got it right quite a long time ago, but it seems that it was too much to chew for a solution vendor to build infrastructure software.

  • 12/19/04 :: [SOA] Gartner's presentation: Time Well Spent: Web Services Mature More [permalink]
    I found this very interesting presentation via BPELSource.com. Gartner gave up on the notion of "stack" which makes sense. The French talk about "bricks" rather than layers. I tried that term a couple of times in the US but it did not stick. Gartner has started rating the probability of success for a given standard: Strong positive, positive, promising, caution... buy, sell, short,... This is hilarious. I love this quote:-) "The beauty of Web services is their simplicity, but complexity will eventually creep in". Lots of great stuff overall.

  • 12/14/04 :: [MDA] Debate is heating up around DSLs [permalink]
    Jack Greenfield was giving a presentation last week about Microsoft's Software Factories concepts so I made the trip to Redmond to hear him. I was happy but not surprised to learn that he was a NeXT guy. Too bad that DSLs are not as sexy as iPods otherwise Steve would have surely wanted something like that for the Mac. Jack made two points about UML:
    a) UML is inadequate to model DSLs
    b) Microsoft MDA's approach is very different in nature from the OMG's MDA
    Grady booch responded to the first point. I actually felt that the second point was more interesting. Having practiced in ebXML BPSS how UML fanatics can arm-wrestle with their favorite standard to make it say whatever they want, I am not surprised of Grady's answer. My position is also, who cares? I actually don't mind if there are more than one way to express machine readable semantics. UML is just one of them, XML is yet another way. I find the second point a lot more debate worthy. At the top level, it seems that both advocate a domain level language (DSL for Microsoft, CIM for OMG). The OMG adds to the mix the notion of platform independence with the concepts of PIM and PSM. If it is not surprising that Microsoft did not spend much time on this notion, the MDA guide (it is not a spec), doesn't spend much time relating the CIM with the PIM, but rather focuses almost entirely on PIM/PSM transformations. I would argue that it might be a lot of effort to create a platform independent system model that is then transformed into a technology specific model (OMG advocates 3 levels: business/domain, system, technology). These 3 levels make an OMG MDA approach complex. Why do you need Platform Independence in everything you do?  Furthermore, the PIM/PSM transformation is often a code generation step. This is another point of failure or inefficiency, unless the code generated is pure metadata (e.g. domain classes for JDO persistence) . We all know that complex code generation does not work. Microsoft's approach is a lot simpler (but not sloppy...). As I understand it, Microsoft advocates simple DSLs, very simple DSLs used to configure a hard wired run-time. If you need platform independence, you write another run-time for the same DSL. Microsoft's DSLs are more like engine "configuration" languages (though it is not really doing it justice to draw this analogy). They are declarative before being generative. They are about asset reuse more than asset generation. I don't want to judge (for once), which one is the best or most likely to win. I just want to point out the degrees of complexity of each approach. The 80/20 rule should apply then.

    Of course, Microsoft is playing its usual role of destabilizing standards in place like UML (and of course the economic interests behind it), but in that case, I think there is also genuine creativity and a sophisticated analysis carried out by Keith and Jack's team.

  • 12/05/04 :: [SOA] Is Sloppyness good (enough)?[ permalink]
    This past week, Prof. Vincenzo D'Andrea was a guest at Attachmate. We had great discussions on SOC and other topics. I also spoke with him briefly about Adam Bosworth's talk at ICSOC04 in respect to where the software industry is today and the road forward to SOC. The past 10 years have been quite impressive in terms of the number of technologies, concepts and products that have emerged and matured around software engineering. Adam argues that "software which is flexible, simple, sloppy, tolerant, and altogether forgiving of human foibles and weaknesses turns out to be actually the most steel cored, able to survive and grow". Vincenzo made some excellent points relating the complexity of the problem to the complexity of the solution and of course the evolution of the categories of problems and with respect to existing solutions and often their lack of evolution. We also talked about differentiating the factors that make people adopt a technology versus the factors that make it a productive technology. HTML and related technologies (e.g. javascript) were widely adopted, but when the problem shifted from creating and publishing simple content to building content rich web applications, was this solution still related to the new problems? Could web services be on the wrong track as a solution of never ending complexity (sometimes even loosing track of the problems it is addressing)? Considering the number of PhDs working on SOC, are we in trouble?

    Before we answer that question, I would like to point out that the biggest argument I see missing in Adam's thesis is the economic one. Adam does not factor at all the "cost" of using sloppy technology. After all, if Nicholas Carr can safely argue that "IT doesn't matter", it is not because everyone can adopt the same technology, it is rather precisely that using sloppy technologies and being sloppy translate into significant cost (and risk) being added to any given project. Adam, have you ever considered that HTML and Javascript have almost wiped out software engineering from the face of this earth? Was it desirable to build (web) applications with such sloppy technologies which complexity is adapted to other classes of problems but which adoption has guaranteed hefty revenues to companies like BEA or Microsoft? IT doesn't matter today, not because like machine tools or electricity everyone can acquire them, IT doesn't matter today because sloppy technologies prevent companies to build mission critical systems at a reasonable cost and reasonable risk and most customers had to result to adopt SAP or PeopleSoft view of the world in attempt to diminish this cost and risk. IT unlike any other tool integrate a very strong human factor in its successful and valuable usage. IT will matter again the day we will change fundamentally the ROI equation of building solutions and we give customers the means to build what they need. How can we do that? it is simple, I think Vincenzo has the answer: adapt the complexity of the solution to the complexity of the problem while being creative for the adoption of well suited solutions. I understand why vendors want us to believe that "adoption" of a technology is what we should focus on. However at the end of the day, the only thing customer care about is ROI. Most customers know what is good for their business, not you, not me. The only variables we can control for them is cost and risk.

    How can SOC change ROI (that was the topic of my talk in Paris last week)? Yes, SOC will change ROI. It is changing ROI because it tackles the need for "integration" by significantly reducing its complexity, even the need for integration itself. I am writing an article on this topic so I will keep the thunder of my arguments for it. is the complexity of SOC (as a solution) adapted to the problems at play? This is a tough one. What is clear to me is that the standards are just one part of the answer. We have yet to agree on a full fledge SOC model with which one can build entire solutions, not just ease the pain of EAI with an ESB or solve the "traveler's problem" with WS-BPEL. SOC must emerge as a viable application model with connectivity at its center and with the clear goal to ac
    hieving a decentralized, manageable application model to avoid the monoliths of the past. This application model must transcend our technologies, and more specifically the Object Oriented Programming model. There is nothing sacred about OOP. What OOP has taught me is that having tools to "model the complexity of the world" is good. I would consider it "sloppy" if people may think that you can model all you need in software engineering with "classes". Yet, there are so many attempts to sloppily reify SO in OO.

    Adam, like me, I am sure that everyday you see customers that have incredibly creative ideas about their business. The web has opened up nearly infinite possibilities to better serve their customers, gain competitive advantage, improve the life of their employees or better use their resources. I would urge you to reconsider your argumentation because sloppy tools and approaches are in the way of their success.

  • 11/29/04 :: [SOA] It is always flattering to see one of your slides in someone else's presentation...[ permalink]
    Even though you are not referenced and when the presenter is an icon of the SOA community... The conference in Paris was good otherwise but I felt was lacking of new ideas. The SOA community seems to be busy building the little bits and rushing to trivial applications of these bits while loosing track of the vision. Hopefully, this is going to be temporary. As I was giving my talk, I kept thinking that the fundamental shift is not necessarily from component to services (as the slide that was borrowed was talking about), the fundamental shift is the other way around from enterprise systems to services. Service Orientation is about changing the form factor of solutions, applications and systems. This new form factor features of course all the properties that are listed in the right end side. They oppose the form factor of current systems: monolythic, hard coded and static, integrated, unable to participate in a context different than the one they were specified for, with a very large granularity...
  • 11/22/04 :: [SOA] I have submitted the OASIS ebBP specification for internal review[ permalink]
    As soon as the internal review is completed (~1 week), we will move to public review. The schema is already available on the OASIS mailing list. OASIS ebBP 2.0 includes many new features: an advanced multiparty specification mechanism, improvements of the business transaction protocol with a notification of failure mechanism. The most important improvement I think is the web service operation mapping which allows a) interoperability between ebXML and Web Services b) the specification of web service choreographies (without any ebXML capability) c) leverage the ebXML Business Transaction Protocol with Web Services. This latter capability opens the door to very robust web service utilizations. I will probably write a paper pretty soon explaining how WS-CAF can be used to support the OASIS ebBP architecture. Last but not least, we worked with BPMN and Stephen White in particular, to create a few extensions to BPMN to allow it to model ebBP business collaborations.
  • 11/20/04 :: [SOA] Off to Paris today, I will be speaking at the Integration Forum next Wednesday [ permalink]

  • 11/18/04 :: [ICSOC]  Some insight from Adam Bosworth at ICSOC 2004 [ permalink]
    "The value is neither in the computers nor in the software that runs on them. It is in the content and the software�s ability to find and filter content and in the software�s ability to enable people to collaborate and communicate about content (and each other)". Not surprising when you work for Google but yet quite profound. The fundamental difference I see with the radio though is that the radio itself is not a) a source of information b) has any processing capabilities. So I still see lots of value outside the content.
  • 11/16/04 :: [MS]  Events vs Services: the real story [ permalink]
    I am totally in line with this white paper from Zapthink. I don't understand the need to introduce a new concept (EDA) when everybody is building his SOA and SOA support the notion of events readily.
  • 11/14/04 :: [MS]  A cup of Kafka [ permalink]
    This week, I bought an XP pro upgrade. I learnt, it is a lot more secure than my current win2k. The install completed without a glitch up until I got to my wireless network adapter. After a couple reboots, I realized that the wireless network adapter was working fine but XP pro is so secure that it won't let me create a wireless network that is not protected, he gives me the choice between creating the key automatically or use an existing key. I forgot, it is true these days, that everyone should be so afraid that his/her neighbor hacks into his/her computers. Worse, in the process I swapped my wireless adapter from my home server and my HTPC. I could not believed what happened next: my XP home edition complained that I had "changed significantly" the hardware of my computer and I had to re-register windows. That's bad, but wait there is still worse. I entered my windows license key and Microsoft responded that this key was already registered, well hell yes, since I was asked to re-register. I have 27 days left to fix the problem, after that if I am not registered, I won't even be able to boot. I am wondering what Kafka would write if he was still alive and using computers to write his novels.
  • 11/12/04 :: [SOA]  SO versus OO  [ permalink]
    I have not been posting too much lately, all my free time is consumed by editing the OASIS ebBP spec. Here are some thoughts tonight.
    The SO vs OO debate may sound like an old debate but as SOA starts spreading its wings, it might be important to underline the differences as the question will come back sooner than later. Why? well, yes, there is going to be a lot of tool-based service development kits, but one day someone will likely realize how cool it would be to develop services like we write objects today...
  • 11/10/04 :: [MDA]  Whitehorse bits available [ permalink]
    I was very excited to install the bits of whitehorse on my machine this week. I got to run the example (UIP metamodel) and its looks really cool already. I totally adhere to the philosophy behind the tool. I built my first model driven application in 1991 (I was using the NeXT Interface Builder -itself a model driven application- files as bags of metadata to define the configuration of the systems my code was controlling. This metadata was used across the board to "plug-in" device specific behavior in a general process control application. Of course NeXT had lots of model driven application including Enterprise Object Framework (EOF) which led to the first application server: webObjects. I am happy to see that model driven application models start becoming mainstream and there seem to be a very robust tool that supports the paradigm. No more IB file hacks.
    .. promised.
  • 10/30/04 :: [SOA]  Two types of Service Composition[ permalink]
    There are two types of composition: operation composition and interface composition. Operation composition is what most people have in mind when they talk about service composition. This is the classic case where you expose an operation that is in turn invoking a series of operations before it returns the response/fault of the outer operation. BPEL has been used for this type of composition extensively. Now, there is a second type which I refer as interface composition, where all operations of a service interface are linked with each other via something that could look also like a BPEL definition and can in turn invoke other services definitions as part of the inner workings of this outer service definition.
    If these inner services are hidden from the outer service interface, we have an interface composition. It appears to me that most people are not talking about this type of composition.
  • 10/29/04 :: [BPM]  New open source BPM engine[ permalink]
    Gluecode has donated their BPM engine to the Apache foundation (project Agila). Based on some comments, it looks like this was the missing piece for Apache to compete with BEA's WLI platform. I am so glad to see the J2EE community thriving to adopt lightweight BPM technology to complete the application model, inline with the work of the JSR-208. I am wondering if and when Microsoft will add this kind of thing to .NET.
  • 10/27/04 :: [SOA]  Integration 2004, November 24-25, Paris, France[ permalink]
    This is the event you don't want to miss, great speakers (Jean Paoli, Roman Stanek, Antoine Lonjon, Didier Girard...), lots of case studies, incredible insight and analyses, little to no marketing... I will give a presentation on "Composite Applications: Myth or Reality?"
  • 10/21/04 :: [SOA]  Conference on service oriented computing[ permalink]
    The ICSOC 2004 edition will take place in NY city the week of november 15. I attended the 2003 edition and was very impressed with the quality of the papers and presentations. I was a referee for this current edition and many papers caught my attention. If you want an opportunity to get a -no nonsense- thorough understanding of service orientation without a single "marketer" on the horizon, this is the place.
  • 10/19/04 :: [BPM]  Jboss goes with the flow [ permalink]
    So JBoss enters the BPM market with an association with Tom Baeyens jBPM engine. We can all but wonder why JBoss chose a BPM engine based on UML activity diagrams. This is what we started with at eXcelon back in early 2000, and the engineer that came up with the idea realized quickly how poor a choice this was. I mean for crying out loud, jBPM does not even understand what a "message" is, though UML activity diagrams support the notion of "object flow". Now the remaining dozens of JBoss developers (It looks like Jonas is kicking JBoss's bits) will jump the bandwagon of BPM with a metamodel so poor that Mark Fleury will sell it for EAI applications (like Tom promotes his engine, or Edwin was so keen on touting as the primary application of BPEL).  

  • 10/07/04 :: [Indigo]  Gregor's summary of Indigo's SDR [ permalink]
    Gregor dared to write a summary about Indigo's SDR, I don't know if this link makes me an accomplice. Anyways I also attended the SDR but we can't tell much except that Indigo has a nice programming model (honest opinion) and will certainly be one of the foundation block of Microsoft's SOA story. I can also sense like Gregor that orchestration is not too far down the endpoint though I don't have any specific information at all. Let's put it this way, it will be a shame to ship a web service framework of Indigo's caliber without providing the means to build long running duplex services other than C# and .Net.

  • 10/07/04 :: [WS]  Not your average WSDL [ permalink]
    A recent post from Eric Newcomer, the publication of the OAGi WSDL definitions and my work in ebBP got me started commenting on WSDL. Though it sounds now like WSDL is burried well below the infinitely expending WS-* stack, we should not forget it. Eric argues that "what makes [WSDL] different from the previous interface languages is that it clearly separates the data definition from the transport definition".

    I also would like to add that WSDL gives you the opportunity to support any number of WSDL definitions for any given address. An address is just a soap sender/receiver and the number of contracts it supports has no reason to be limited to one. Can't do that with your average EJB. I am wondering if people would consider that COM can do that? Another major difference that sets it apart is its ability to describe by-directional interfaces anchoring it into the realm of peer-to-peer interactions though most people use it today in a client/server fashion. A WSDL file is going to describe not only the calls you can make on a service but also the outbound calls the service is going to make to its consumer or any other service. That aspect of WSDL has often been quickly forgotten though it is fundamental to Service Orientation. No, WSDL is not just designed for two services talking to each other in a client/server pattern.

    Now, here is the link with ebBP. Have you ever tried to use WSDL in this bi-directional capacity? Then you need two WSDLs one on each side, then you need to do some mapping one way or another. Now consider using n services talking to each other (this is not unheard of, you just need to take a look at the OAGi integration scenarios). How do you describe this mapping between all these WSDLs? any idea?

    well, yes we could create a new WS-MappingABunchOfWSDLInterfaceDefinitionsTogether specification? any volunteer? well actually, that spec already exists, it is called OASIS/ebBP. If you were to consider ebBP for your not so average web service scenarios this is what you would get in addition to a very elegant mapping mechanism: a state alignment protocol that guarantees state alignment for important message exchanges, non repudiation, a superb notation integrated with BPMN...  and many more features.

  • 10/06/04 :: [SOA]  OAGi shipped WSDL files for integration component [ permalink]
    The OAGi has had my highest respect since I ever worked with this group in 1999. It has also been a constant source of inspiration. I still remember my first encounter with David Connelly in Dublin. What is remarkable about this standard is that its architecture has been so well designed from the beginning (1995) that it was able to absorb revolutions like XML, B2B, and now service orientation in a wink. Not to mention that it is a prime example of application of the REST principles though they never talk about HTTP and hacked URIs. It even passes my test of producing "real world" services. Take the SalesOrder service. Its interface provides operations to manage the complete lifecycle of sales orders. They offer us a glimpse of what web service enabling existing systems will look like, always leading without the hype and noise of some "standard" organizations. The next step for the OAGi is to use something like BPEL for describing the order in which the operations will occur (abstract BPEL that is), WS-CDL and/or ebBP to define integration scenarios and B2B collaborations once they are all ready. I would encourage anyone to look at it and use it as a model, it is superb ! I could not expect less.

  • 09/30/04 :: [ebpml]  I did not realize people were actually tracking my glogs[permalink]
    I created a few Google Logs (Glogs) a couple of months ago but did not bother updating them. I will try to update them every other week. I use the Google web service API to do a search on some keyword, say BPEL and create an RSS feed with the result. I only provide references to PDF, .DOC and .PPT documents. If you do that by hand that may require to go as deep as a few hundred results. 

  • 10/05/04 :: [Indigo]  I like Indigo[ permalink]
    I got to see a little more about Indigo today and I really like it. Don's team has really done its homework and understand what message orientation is. I will check tomorrow how much I can report before being killed. I also got into a heated debate with someone close to Microsoft about the difference between orchestration and choreography. I am actually amazed at how aligned is the position of Microsoft on this topic. I get the exact same answer no matter who I talk to, not a wink of doubt -quite fascinating. I tried to show some examples that I felt could not be dealt with orchestration because there is no place to put an orchestration engine, specially in B2B scenarios where there is nothing in the middle but the "free and vastly open" Internet. I even got to hear that it was so sad to spend all these years (like a few others) defending a position that ("the all mighty") Microsoft did not support. I am wondering if he would say that to Robin Milner who is working with the WS-CDL team. He is only the inventor of pi-calculus and head of the Bill Gates Research Lab in Cambridge. The guy ended the conversation by telling me I'd be better off to join the side of the debate that has the most muscle. I am assuming this is what he did. Anyways, I responded, I can't, I am French -i.e. having grown up in the country of Descartes, I don't mind being proven wrong, but I do mind being right. If you have any opinion on the question, drop me a line.

  • 09/30/04 :: [ebpml]  I did not realize people were actually tracking my glogs[permalink]
    I created a few Google Logs (Glogs) a couple of months ago but did not bother updating them. I will try to update them every other week. I use the Google web service API to do a search on some keyword, say BPEL and create an RSS feed with the result. I only provide references to PDF, .DOC and .PPT documents. If you do that by hand that may require to go as deep as a few hundred results. 

  • 09/25/04 :: [WS]  Radovan's rant on JCP and mine on the WS-* stack development process[permalink]
    Radovan pounds the JCP and predicts Java's decline within 12 months. I found the comment more amusing than founded. It is true that lots of good Java APIs have flourished outside the JCP. Speaking of which, I am wondering what happened to BPEL-J. It's been months since I heard anything new about this group, another trait of JCP -in addition to being expensive, it is slooooooww. Anyways, Systinet co-submitted a spec with Microsoft: WS-Transfer. Though, it looks like the nth attempt of bringing REST into the WS-* stack, it appears to me that somebody just web service enabled the good old WebDav. Now how significant is that? Is it part of the WS-* stack or is it not? If it is, what is it related to? Does it work with BPEL? I am wondering if Radovan would comment on the WS specification development process and how well it is working for delivering something useful, at least you can do lots of great things with Java (and C#). I know that Systinet has a lot of customers in production and yes, something like WS-I has proven useful to both the vendors and these customers, but I am also assuming that these customers have bought into WS because of the vision not just because of SOAP and WSDL (oops, I almost forgot) UDDI. How efficient is the WS specification development process (WS-SDP) for delivering that vision? Is the multiplication of little specs competing and overlapping but never aligned, produced here by vendors, here by competing standard organization the way to go? who does this process serves? What is the cost -the real cost- of this process. I bet the TCK looks like a bargain, isn't it?

  • 09/19/04 :: [WS]  WS-* Stack: Microsoft's view[permalink]
    This must represent the official view, based on the authorship. I am a bit disappointed that BPEL is not even mentioned as it was before in this type of article (as a Web Services Composition language), it would be important for Microsoft and others to define what BPEL is. John's definition as an import/export format for BizTalk is kind of weak

  • 09/19/04 :: [SOA]  What if ...[permalink]
    Ok, it is no secret that I am not a big fan of the current WS-* standard process and in particular of the direction or lack thereof the BPEL group despite the importance of this standard for the success of Service Orientation. I have to write a couple of articles on behalf of Attachmate and I came across Prof. Munindar Singh research papers talking about "coordination" or "commitment" way back when at the end of the last century. You may want to check this article ("
    Synthesizing Coordination Requirements for Heterogeneous Autonomous Agents"). I cannot avoid to wander and wonder what if people like him where in charge of designing BPEL. In all fairness, this approach is being tried by the W3C/WS-CHOR group for the design of WS-CDL who invited Robin Miler and others to contribute to the standard work
  • 09/16/04 :: [SOA]  Gartner advises to ignore Longhorn[permalink]
    Dotnetguru.org provided this link that explains, according to Gartner, that by 2010 enterprises will still use XP on the client and WIN2003 on the server

  • 09/16/04 :: [BPEL]  Everyone concedes ...[permalink]
    "...that the robust version, BPEL 2.0, is approximately 18 months from completion." - I am wondering if it is going to beat longhorn.

  • 09/12/04 :: [Job]  Looking for a strong UI developer (Attachmate, Bellevue, WA) [permalink]
    Ok, we found our server star, but we still have one position open in our team on the client side. If the server side is quite innovative, the client side is revolutionary. Attachmate is a great company to work for and our team is the best team I ever worked with from a talent, creativity and camaraderie perspectives. Join us and make a difference !

  • 09/12/04 :: [SOA]  More articles on Service Oriented Computing [permalink]
    The SIGSOC at Tilburg University in the Netherlands has a great list of articles. For instance this one from Mike Papazoglou: "SOC: Concepts Technologies and Directions".

  • 08/29/04 :: [SOA]  Jump of the bus, take a cab (III) [permalink]
    Doug Tidwell gives us the definition of an ESB in this presentation (
    Business Processes in SOA): "The ESB�s job is to figure out how to get the request to the service, then get the response to the requestor" or "the Enterprise Service Bus routes messages between Web services". My understanding is that most ESB vendor are touting these properties as critical for SOA. I am wondering how counter intuitive are those definitions to W3C/WS-Architecture and SOAP, WSDL and UDDI. I understand the need for having the notion of "web services domains" where a web service sends a request to a domain without having to know which particular end point will be answering the request, but this is not ESB. Why do I need something to facilitate getting requests and response back an forth? I thought the very value of WSDL was decoupling the technology bindings from the service interface definition, enabling more than one binding for a given interface. So a service consumer, discovering a service, could choose whichever way it wants to talk to the service.
  • 08/29/04 :: [BPEL] IBM adds support for BPEL in Eclipse [permalink]
    The product is really an "Integation Modeler" so it is not specific to BPEL (though it has BPEL mode which limits its functionality :-). Looking at all the concepts that you can model, you realize how far BPEL is from a "Business Process" Execution Language or even how far is it from being able to deal with EAI only. You may want to take a look at technical documentation of the product. They do not seem to use BPMN.

  • 08/26/04 :: [SOA] Positions open in our project at Attachmate, Bellevue, WA [permalink]
    We are looking for talented and passionate people on both the client and server side of a new product focused on web services and SOA. Attachmate is a great company to work for, the product is incredibly innovative and our team is the best team I ever worked with from a talent, creativity and camaraderie perspectives. Join us and make a difference !
  • 08/21/04 :: [SOA] Amazon: REST or SOAP? [permalink]
    So here we are, SOC is getting a big boost from companies like Amazon, eBay, PayPal,... Their services can be accessed in two ways: REST and SOAP. The REST camp is claiming victory. We should really analyze these numbers with great care and look fairly at the major limitations of REST moving forward, for instance: state alignment, peer-to-peer interactions and partial state representations. In the front-end, REST will remain a dominant player and this is why some services must offer a REST interface. In the back end SOAP will win by a large margin.
  • 08/19/04 :: [SOA] Microsoft's vision about web services [permalink]
    Rebecca Dias and Jorgen Thelin articulate MS's vision with respect to standards and products. I found it interesting to see that BPEL was left out of the grand vision. As I see it, the Service Oriented Computing space is being fragmented along three domains: distributed computing, EAI (ESB) and whatever is left (B2B, BPM, ASP...). Clearly WSE, Indigo and Rebecca's group is marching towards a new distributed computing model focused on interoperability but with very little innovation compared to CORBA or DCOM except for asynchronicity. Of course, my position is that there is something called Service Oriented Computing that will change radically the way we build applications, by changing the very notion of what an application is in the connected world. I did not see that translated into MS's vision. I am totally in line with the CBDI Forum, see this new article, which related the foundation of SOC to the fact that "Conventional approaches are based on widespread replication of data precisely because users have not been able to rely on distributed data networks. This architecture is fundamentally flawed because of the inherent difficulties in maintaining high quality data with appropriate currency"


  • 08/18/04 :: [SOA] End-points: a new begining? [permalink]
    I wrote a short review of the WS-Addressing spec. I would encourage anyone to become familiar with this simple but powerful spec. It was submitted to the W3C by a broad set of vendors earlier this month. IMHO, the spec enables a new class of applications of web services technologies, far more sophisticated than what we have seen so far. The last big hole in the WS-* stack remains transactions in order to have a completely operational foundation (RM is pretty much done already).


This post is somewhat personal, answering Dave Welsh - his article touches on many events that I lived and affected the standard I work for: OASIS / ebBP, formerly ebXML BPSS. I was the editor for ebXML BPSS 1.1. and I am now the editor of ebBP 2.0 after the whole team (except Dave Welsh) walked away from the operational development practices of the TMG- the body which was responsible for BPSS within the UN/CEFACT. I don't want to waste too much time (yours and mine) on his article, but felt I had to respond since it contains direct references to the events of August 2003 that lead to the whole team leaving the UN/CEFACT SDO. Dave is the former project leader of ebXML BPSS 1.1 and was imposed to the team without any form of cooptation by Klaus Dieter Naujok in January 2003 (I am surprised Klaus is not a co-author of the article since he is an expert and knows so very well how some standard organization works, for instance his). Actually, I wish Dave and Klaus would have the honesty to report the detail of their own operational practices instead of hiding behind the comfort of plain vanilla articles published on MSDN, just as if nothing had happened. As a matter a fact, Dave does not have the courage to mention BPSS and UN/CEFACT in this article.

You may want to refer to John Markoff, Senior correspondent in the Silicon Valley for the NY Times, who has taken a stab at the question, and I would encourage you to compare and contrast both articles ("Microsoft Creates a Stir in Its Work With the U.N." By John Markoff). I frankly cannot wait to read the following article where Dave will explain us "the key specific issues influencing the world of standards [...] demystifying the topic of intellectual property in standards"  (yes this is a quote from Dave!). Shouldn't end-users provide the requirements that influence the course of a standard? Vendors are influencing standards? hum...that's news to me ;-).

I will not go through every point of the article since it would have limited value. I wish however that Dave would have mentioned that there are many many individuals behind the "SDO" acronym, and it is the painstaking contribution of these individuals that make up standards. Most of these individuals contributes on their own time, some time pay their own trip to face-to-face meetings. Not everybody has the luxury to get year round, all around the world (including the most exotic places), all expenses paid trips. These individuals often act as a counterbalance to the "implementors". 

I would like rather to reflect on the "cost of standards". I meant to do that for some time. Here we are, if you consider just the WS-* stack, say 70 specs and counting, often overlapping, hardly ever aligned, and say 10 people full time on average, say at a total cost of 250k/year (including travel expenses, management,...). You already have a running cost of $175 Million dollars. Say now, you start counting the cost of tracking (the very slow) progress of these standards (e.g. 100 companies per standard with 0.5 FTE at 200k/year), that's $700 Million dollars. Now, you start factoring the cost of not delivering a standard within a reasonable time (e.g. BPEL or BPML before it), creating a loss in revenue and delayed investment and ROI, you are looking at a few billions at least. Not to mention the extra development cost brought by unnecessary complexity of the specs. These number make the hefty 50k/year W3C fee a deal -that fee give you the privilege to contribute your expertise to the development of its standards . You might argue that I am a few billion off. Frankly, my conclusion is that nobody benefits from the way the standard development world REALLY works and I feel that Dave and others should not attempt to teach anybody any lesson about it. I may be naive, and this is where I disagree with Markoff's analysis of the facts he reports: I would not go as far as saying that Microsoft or any other large vendor is aware and seeking the kind of thing that is happening in SDOs. Any reasonable CEO would slash that cost to a fraction and bring back accountability and timely results to the field. I believe instead that the field has been left open to personal rather than corporation strategy. I remember the time within BPSS where a couple people had decided without the mandate of the ebXML organization and for their own interest to align BPSS with OMG/EDOC creating unnecessary constraints on BPSS. EDOC was not even a B2B standard! Since one of them was the chair, they got away. This happens all the time everywhere and goes unnoticed. If you want my honest opinion, the OMG is the least dysfunctional standard organization producing very high quality work, through a very rigorous process and with incredibly competent people. It is sad that they have not been more involved in WS-* more. I would rank OASIS second, with a fresh way of fostering new standard (but please, figure out a way to converge and align them). W3C has lost leadership. Its best achievement is by far XML, and just for that this organization was worth it, but it went south from there. Interestingly enough XML is probably the standard that was the cheapest to produce and is the one that is the most widely adopted (depends on how you count compared to HTML). This should be a model for everything else. I wish Tim or Jon could duplicate their recipe across the board.

The WS-* standard development process is broken, really broken. What is fundamentally broken in SDOs -and Dave does not speak about it of course- is simple: product management. There is no product management and accountability, end-users are hardly represented (who could spend this kind of money?). This leaves the door completely open to vendors and most often to individuals not even representing the vendors but just pushing their own ideas. The best example is the wide-spread use and over-representation of pi-calculus in BPM. A few -bright, and I mean it- individuals (not more than 5) have decided that BPM was equal to pi-calculus. And here they went, BPML, BPEL, WS-CDL, (ebBP escaped the disaster), were just about pushing pi-calculus, nothing to do with modeling processes. Now, who could argue that any end-user looking at their own processes and trying to use BPEL would not understand what I am talking about. I mean even Collaxa's value proposition as a BPEL engine was cheaper EAI ! Which reasonable human being can look at pi-calculus and start to believe this great but simple theory can do it all by itself? If there had been any reasonable product management in place, bringing up legitimate use cases, and not just the ones looking at pushing an agenda- this would never happen.

As a society, we should reflect on that cost, should I say waste? Are we getting our money's worth, again as an entire group of human beings, from these roughly 50 billion dollars (say 10 billion per year for 5 years) to develop approximately 7000 pages of specifications, and sadly just a few Mb of barely readable XML Schemas. There are far better ways to keep all these people busy. Being French, I see an opportunity for the government to get involved, I have been saying this for years. I know the folks in the US usually don't trust the US government for many things (it became clear to me why), but say you take an organization like NIST with outstanding people like Conrad Bock and many others. All you need to do is to put in place a basic but honest product management and project management structure stable enough to last for the length of the work. Vendors could freely contribute to the fund, or the pool of people. SMEs could also participate. Again, as a society, everyone has benefited and will benefit from standards, every day that passes without a potential standard being complete cost money to our society. After all, my car can run on any road and roads are not private, but the cars are made by private companies.

Dave, I am saddened that you could hide behind this article after all that happened, be assured that I will be commenting on the subsequent ones when you will talk about "influence" and "IP". In the mean time I will go back to my job of editing OASIS/ebBP 2.0.

Jean-Jacques Dubray


  • 08/10/04 :: [Other] More on software factories [permalink]
    The launch Visual Studio 2005 is going full swing with this latest
    article by Jack Greenfield talking about the holly grail of software engineering: software reuse. Eric Newcomer also commented on the topic with respect to SOA (sounds like he was taking Amazon web service API as an example). For me, the fundamental issue in building applications for a given field (say business applications like ERP, CRM, PLM, SCM, ...) is that the code written with our current languages does not reflect the requirements that were specified to create it. Once the requirement has been coded, it is virtually impossible to reverse engineer it. This makes the code very difficult to maintain as requirements evolve or new ones come in.
  • So just like Jack and Keith I believe that Domain Specific Language are the way forward. But not DSL on top of Java or C#, DSL on top of Service Oriented Computing. Incidentally, and unlike Jack, I don't think Patterns lead to good reuse. I like the application block model a little better but it is still code.

    Why? I like car analogies for software engineering, I have literally dozens. Cars are for me the ultimate result of engineering. Imagine the pride of a Porsche engineer when he sees a 911 GT2 on the road. So many disciplines are involved and it is made of so many different parts, which unlike lego's bricks are fulfilling specific functions, most often as a service (e.g. battery, water pump, starter, ...). Note that Lego had to move from bricks to parts to make useful stuff. At the same time, car parts are often designed to offer these services in a "context independent" way. There is just enough coupling for the parts to act together as a car, but not more. Of course there are still dependencies (e.g. geometry, QoS), but nowadays, parts can be found on many different cars, often across brands. Developing an ERP system is a bit like developing a car. SAP has models and series. Once an ERP system is deployed at a customer you have to manage its "configuration" like you manage the one of a car unit (actually, maybe a bit more like an airplane). Ultimately, there will be enough "services" available from OE to Billing, to sales tax calculation, ..., such that companies could venture to create ERP systems pretty much like we design a car. This is what Amazon is doing today with its web service API: developers can write applications consuming these services (though not yet using DSLs) .

    So DSL + SOC would be my winning combination for software engineering reuse.



  • 07/29/04 :: [SOA] Jump off the bus take a cab (II) [permalink]
    Steve Vinoski adds to the debate about ESB vs decentralization. I would like to throw a few comments. In the past application architectures were not designed to take responsibility for integration capabilities, those were the golden days of MOM. So, is an ESB a stupid idea? As a centralized piece of infrastructure, yes, this path will not lead you to SOA, just EAI, but as a web service "server" providing shared integration capabilities to a series of end points, no. About the N^2 problem, if I agree in general with the statement made, we are also in a much better position today, architecturally, to build end-points that can respond to various requester types using different formats.

  • 07/29/04 :: [SOA] More on data centric interfaces [permalink]
    I looked at a presentation from Jason Bloomberg (ZapThink), sponsored by GrandCentral. In his presentation he was talking about a New-England based large Insurance company which was making a call into a private UDDI registry each time an incoming ACORD formatted message was coming into their organizations. The goal was to do a lookup of the (internal) web service that would be in charge of processing that incoming message. I felt that it was king of clumsy. It is interesting to see that nobody in the WS community is ready to face the problem of data centric interfaces. As a reminder, ebXML and ebBP in particular has addressed most of this problem 4 years ago and is about to publish a strong 2.0 spec.

  • 07/27/04 :: [MDA] Software Factories [permalink]
    Some of you may remember BowStreet and its CTO Andy Roberts, the language sounds very familiar to what BowStreet came out with in 1998. They were talking about business web factories back then. I totally agree with Keith: MDA is not about UML and is not about platform independence (this is why Microsoft is calling it DSL instead of MDA). Yes it is easier to switch platofrm once you have adopted an MDA approach, but you don't do that every day so it does not make so much sense to make it such a strong architecture constraint. Similarly, tying MDA to UML does not appear such a good idea, and again I concur with Keith when he explains where UML ought to be used. XML has proven a far more efficient technology to support MDA. Tools like VisualScript or VSTS pave the way in that direction, you can expect a lot more will show up as the concept of Software Factories becomes more mainstream.

  • 07/26/04 :: [SOA] How low can you go? [permalink]
    Maarten Mullender provides a great perspective on the granularity of services in his post "CRUD, only when you can afford it". That part of SOA has not been fleshed out completely, he provides great insight and structure to the problem.

  • 07/19/04 :: [BPEL] BEA enters the process automation market [permalink]
    BEA announced the availability of is Weblogic Server Process Edition directly targeting the BPM market while delivering the keystone of its SOA strategy. Two very interesting details in the press release: A) it does not talk about BPEL B) the product is 'designed to help enable companies to quickly and cost-effectively experience the benefits of service-oriented architecture (SOA)'. If the product looks like the Oracle BPEL server, the datasheet specifies that BPEL is just an 'export' format and will support BPEL-J when available... BEA establishes a link with BPM and SOA via the concept of web service composition and ubiquitous connectivity. I'd be curious to know why BEA dumped BPEL so easily while pushing (slowly) for BPEL-J. BPEL is a clear market force with Oracle, SAP or IBM, along with many startups like FiveSight, OpenStorm or Active-EndPoints.

  • 07/17/04 :: [BPEL] Edwin's interview with John Udell [permalink]
    I was quite disappointed to read Edwin's interview on the evolution of BPEL. On one side, he urges us to accept BPEL as a first class language (of course I agree with that), I also found his point about the XML syntax vs a more regular scripting syntax quite convincing, but his point at the end about having business analyst filling out parameters in BPEL templates via specialized GUIs did not resonate too well with me. A) There is something called BPMN (https://www.ebpml.org/bpmn.htm) that can be used by any business analyst. This is a lot closer to what a "business process is" (not just a few parameters sprinkled on a run-time engine, hand coded in proprietary wizards), and B) BPEL is a programming language to write orchestrated services, including composition of web services, this is different from the more general EAIish orchestration of services which is a poor idea counter to the principles of SOA.

  • 07/17/04 :: [Article] A Survey of Web Services technologies [permalink]
    Mike Papazoglou has kindly offered me to participate in writing this article (80 pages). It is is meant to provide a complete view of the web services technologies, as of today, and a perspective on their evolution paths.

  • 07/17/04 :: [SOA] Simon Woodman asks what is the difference between Coordination, Composition, Collaboration, Choreography, Orchestration, Transaction... [permalink]
    All of the above are a form of coordination...

  • 07/15/04 :: [SOA] Testing of Service Oriented Architectures � A practical approach [permalink]
    The idea behind SITT is to test services and their orchestration by analysing the message flows.

  • 07/15/04 :: [BPEL] An Analysis of Web Services Workflow Patterns in Collaxa [permalink]
    The article measures how Oracle BPEL engine can support Will van der Aalst workflow patterns

  • 07/08/04 :: [SOA] Jump off the bus, take a cab ! [permalink]
    Today, a story on NPR about the airline industry and the (economic) superiority of the point-to-point model over the hub triggered some thoughts that I have been contemplating for a while. A lot of companies have expressed the similarities between SOA and the concept of (hardware) Bus. We even have the notion of "enterprise service bus (ESB)". I am not attempting to discuss the merits of one product or another, I am just commenting on the concept of "bus". If this concept has been more than widely used in hardware architectures (could you image point-to-point connectors in a PC chassis?) buses had to evolve to achieve capabilities like plug and play, hot deploy or even scale (compactPCI, DMA,...). I understand that a bus offers a "common interface infrastructure" and components can use the bus to communicate with each other, this is pretty much where the analogy stops for SOA. SOA requires very little in the middle (other than a standard communication infrastructure, that we already have for free) and is inherently point to point and asynchronous, unlike most bus architectures which require some centralized infrastructure and synchronous behavior. I would agree with the OASIS/BCM group that the only shared component in a SOA is a directory service. Of course some technical services can be shared across a group of services, but this is just for efficiency, not an architectural constraint inherent to SOA. With that respect I like a lot the presentation from SUN that was given at JavaOne talking about JBI and the concept of "micro-architectures".

  • 07/08/04 :: [WS] Are you glogging yet? [permalink]
    Some more experiments with Google web service API tonight. I created a "Glog" page, that provides canned google queries in a RSS format. This should keep you up to speed on all new publication relative to topics like SOA, BPEL, ...

  • 07/07/04 :: [BPM] BPIResearch publishes the Business Process Management Ontology [permalink]
    The primary goal of the BPMO is to provide a stable platform for the semantically rich definition of business processes.The BPMO is architected in layers. The BPM Core ontology forms the foundation. Industry-specific and organization-specific ontologies form levels 2 and 3. Of course, multiple industry-specific ontologies can be integrated, which is a requirement of larger organizations.

  • 07/07/04 :: [WS] The Google Web Service API [permalink]
    I was playing with the Google web services API and wrote a little tool that fetches all the PDF documents that contain references to ebPML.org.

  • 07/04/04 :: [SOA] Matt Tavis explains what Service Orientation is [permalink]
    Matt, a PM in the Distributed Systems Group, explained that (I quote him) "SO is a paradigm, an approach, NOT a technology or product" during his CTS300 presentation at TechEd 2004 Europe. All you need to care about are the four tenets of service orientation (PEACe). If you couple this statement with Pat's vision of SOA ("SOAs are [just] about connecting independent pieces with messaging"). You realize why MS may be missing the "coordination" piece of SOA... A bit of "WISI" and your're done! Hum...Isn't SO a new computing model? not just a modus vivendi?

  • 07/03/04 :: [BPEL] BPEL elevator pitch reloaded [permalink]
    My elevator pitch did not pass Paul Brown's mum test so I called mine this morning and I finally ended the secrecy about the kind of things I was working on. I said mum: "you know there were a series of programming languages that were really good at adding and subtracting numbers. This kind of programming languages let you model and execute all kinds of complex operations like the ones that are needed for the accounting package you used to work on, that you would otherwise do by hand. These languages can't really model and execute, say the operations that happen when you post a letter at the post office until it arrives to me on the other side of the earth. Some really smart people have invented such a language and have even created a system to run these programs. She waited for a while, and then she continued...hum, it doesn't sound that useful, we already have email to automate these operations what else can I use it for?". At this point, I took my Calvin face and was thinking "... noT Fair ..." while Hobbes was telling me: "At least she is now certain that you are not an opera singer"

  • 07/01/04 :: [SOA] The book Integration Patterns goes online [permalink]
    Yet another example of MS thought leadership (with the help of Dragos and Gregor)

  • 07/01/04 :: [SOA] Dealing with Concurrency: Designing Interaction Between Services and Their Agents [permalink]
    Another great article from Microsoft think tank. Maarten Mullender explains the different concurrency model (Pessimistic, Optimistic and Posting). I am wondering how REST handles yet this -other- problem. This is the point I was making yesterday. They have hired the best and brightest, they understand all the problems related to SOA and web services, and better than anyone else, yet they can't deliver a coherent product line aligned with their vision. All we see are smart application blocks (open source equivalent at Microsoft) and WSE with marginal improvements in .NET 2.0. In the 21st century, infrastructure software can only be standard, nothing less, nothing more. WSDL, SOAP and UDDI won't be enough.

  • 07/01/04 :: [ebPML] ebPML.org statistics for Q1 and Q2 2004 [permalink]
    I wanted to publish the usage statistics and thank the 20,000 (unique) visitors that took the time to stop by in the last 6 months. The most downloaded presentation is an invited lecture https://www.ebpml.org/csfsoa.ppt with over 2500 downloads. Some of them took also the time to send some touching comments about what I was writing. As usual, good or bad, feedback is always welcomed.
  • 06/30/04 :: [SOA] Microsoft and SOA: I love you, me neither [permalink]
    Microsoft made Web Services and SOA real and now retreats...

  • 06/30/04 :: [BPEL] Oracle buys Collaxa [permalink]
    This link is a historical milestone in the long quest for BPM. Collaxa is THE company that made BPEL -the SOA programming language- real, everybody else followed, who knows where it will be today if Collaxa did not have the guts to start building a product without IP clearance. Collaxa positioned IBM (in), MS (out) and now Oracle in that market. IBM had to move in because it knew some other J2EE vendor will buy Collaxa. Some genius at MS thought they had to move out because BPEL was making J2EE stronger, they felt they could kill it before it could happen, plain wrong. With this acquisition, Oracle recovers a bit of its lag in the SOA space. While IBM has established a de facto dominant position, while Microsoft SOA story has completely vanished in the indigo blues with completely unrealistic timeframe (Don Box may joke in Amsterdam, but it is sad that WSE is the only real SOA technology that MS has to offer until 2007 or 08 or 09?) and statements such as BPEL is an exchange format for the BizTalk server. Oracle seems to be making the begining of an entry (for once not after the battle). This entry could become very powerful if and when they articulate BPEL with WS-CDL and WS-CAF. At this point, Oracle will be the only company with a SOAM (Service Oriented Application Model) which will for instance make PeopleSoft integration happen seamlessly (just kidding).

  • 06/22/04 :: [SOA] Stefan's comment on Data Centric Interface Definition Language [permalink]
    Stefan Tilkov commented on my post about Data Centric Interface. I guess my comments required a bit more framing. Here was the intent of my question: How do we define the interface (contract, including behavior) of a Data Centric Interface. As I understand it REST provides me with an implementation model (GET/PUT, ...), but not a contract definition. Do we even need a contract definition for DCIs? Note that if BPSS was viewed as a good starting point for DCI it could be possible to make it more RESTful.

  • 06/22/04 :: [SOA] Data Centric Interface Definition Language [permalink]
    Continuing to reflect on Paul Prescod Data Centric Interfaces concept, I am wondering what a data centric interface definition language would look like.

  • 06/22/04 :: [SOA] State alignment in the connected world [permalink]
    I wanted to write a short note for a while talking about State Alignment in SOA. There is strong misconception about the fact that RM is enough. If companies like Systinet have just came out with an RM implementation, we are still light years away from being able to achieve state alignment in SOA. I explain how the ebXML Business Transaction Protocol works.

  • 06/20/04 :: [SOA] SOAR: Service Oriented Architecture Research Consortium [permalink]
    Stanford University has opened the SOAR consortium. Full membership comes at a hefty price. Charles Petrie and Chris Bussler are leading the research center. The goals of the center is to develop the technologies for the next generation of web services that will enable dynamic, runtime discovery and consumption of services as needed, including complex service composition in order to achieve high-level business goals. There is actually a lot of interesting research going on in the field of automatic web services composition especially at the University of Trento in Italy.

  • 06/19/04 :: [REST] Resource Oriented Architecture: the Amazon foREST [permalink]
    Paul Prescod has put together a remarkable presentation about Resource Oriented Architecture (Data interfaces) vs Service Oriented Architecture (Services Interfaces). He dissects the Amazon REST interface and claims that it has been widely more successful than its counterpart SOAP interface. I must admit that I cannot stand when some one is trying to make a point about architecture with a hacked URL syntax, but if I close my eyes when that happens, I really like his argumentation and conclusions. Beyond these conclusions and like the W3C WS-Architecture group, I am conmforted in the idea that SOC will have to establish clear relationships to the concepts of Resources and Events, otherwise we will again achieve a mosaic of misfit concepts: SOA, ROA, EDA. I still think that everything is a service, but the service interface as defined in WSDL is not flexible enough today to accommodate all concepts. The best example I have to illustrate that, is that in the ebBP group we are attempting to describe ebXML BPSS business transactions and collaboration as a set of web services interfaces and this proves to be an impossible task. OASIS ebBP is probably a mix of ROA and EDA, yet sure feels like an SOA.

  • 06/18/04 :: [BPEL] BPEL elevator pitch wanted [permalink]
    Paul Brown is wondering what would be the best elevator pitch for BPEL. Sounds like a contest. Though I have no chance to win, I would give mine: BPEL is a programming language or a set of extensions to existing programming languages that let you write programs and systems that can participate in message driven, asynchronous, long running units of work. This type of code is typically very hard to write or debug, in particular the dehydration/hydration of state, error prone, and difficult to monitor. Now that we live in a connected world, this type of code has become very common if not the norm. As such, BPEL is the programming language of SOA, it has brought consistency, order and elegance in a world of chaos. Today, BPEL can complement existing application models (e.g. J2EE) or be used for EAI applications, for web service compositions and in the near future it will become a key technology of BPM along with choreography languages.

  • 06/16/04 :: [BPEL] BPEL use cases wanted [permalink]
    The OASIS BPEL TC is requesting uses cases that they could use in their ongoing work.

  • 06/14/04 :: [Article] Where is BPEL 2.0 going? [permalink]
    I have written a short essay wondering where is BPEL 2.0 going? Now that WS-CDL and BPMN have defined the fabric in which BPEL fits, what are the options left to this programming language? Through a concrete example, captured in BPMN -thanks to the workflow-research.de visio stencils-, I demonstrate the inconsistencies of BPEL.

  • 06/13/04 :: [Article] Developing web services choreography [BPM related] standards -The case of REST vs SOAP [permalink]
    Michael zur Muehlen, Jeffrey Nikerson and Keith Swenson retrace the history of BPM related standards (FYI: BPSS was published as a spec in 2001 not 2003). The authors provide an interesting perspective showing what a REST style business process would look like. The authors argue that since the latest SOAP specification allows for a RESTful usage of SOAP, we should see the re-emergence of REST concepts in BPM related standards.

  • 06/12/04 :: [Specification] WS-CDL Analysis [permalink]
    I have written an analysis of WS-CDL. This specification is long overdue with respect to BPEL, I hope that most people will now understand how complementary orchestration and choreography are. Overall, the BPM space is making huge progress this spring. The release of BPMN and WS-CDL signals a profound inflection in our ability to move in the right direction for both modeling and execution. The second half of 2004 should be fascinating when we put all the pieces together: BPMN, WS-CDL, BPEL, WS-CAF and BPSS.

  • 06/12/04 :: [Article] Pick your coupling: Loose, Dynamic, Active? [permalink]
    Jeff Scheinder makes a great point about loose coupling, hinting yet another level of coupling called dynamic. In this post, I argue that there is probably another category that I call Active

  • 06/11/04 :: [BPEL] John Evdemon's presentation on BPEL current status [permalink]
    John just opened a blog and posted one of his latest presentation on BPEL. Nothing has really changed in the last two years except that BPEL got even more confused with its relationship to B2B. He confirms that Microsoft sees BPEL as an exchange format for his Orchestration Engine (Biztalk/winOE). John argues us that BPEL is NOT a programming language but is nevertheless "turing complete". Of course, you all know my opinion by now, BPEL is for the most part a programming language with which one writes business logic that can participate in a business process. Of course the "other" application of BPEL is EAI.

  • 06/11/04 :: [Product] Collaxa's Value Proposition? [permalink]
    I was caught off guard when I visited Collaxa's company description page today. Collaxa's server value proposition is... standard-based, semantically reach [, model driven] affordable EAI ! No comment.

  • 06/10/04 :: [Specification] BPMN Analysis [permalink]
    I have written an anlysis of BPMN (Business Process Modeling Notation). All things considered, this is a major step forward for BPM. It should become the catalyst to federate the 3 specifications of BPM: BPEL (business logic that can participate in a business process), WS-CDL (Choreography is the foundation of business process definitions) and BPSS (B2B semantics and public processes).

  • 06/10/04 :: [SOA] Jeffrey Richter [permalink]
    Jeffrey Richter, a co-founder of Wintellect, Inc. is a .NET guru and has contributed to the design of many parts of the .NET CLR and Windows operating systems. He also contributed to Indigo most recently. I attended one of his talks today and I was really happy to hear him confirm what I have been saying since the summer of 2002, i.e. web services should not be thought only of as client server request / replies. Instead, it is best to think of "asynchronous, one-way, stateless messages". (I disagree with the stateless part as for me a service is most often orchestrated, I often talk about "context independence" as a property of services). This allows for more sophisticated and more useful message patterns as compared to request/reply. This also allows for better scalability as well as robustness and error recovery. He emphasized that this was the model supported today by WSE 2.0 and Indigo.

  • 06/08/04 :: [SOA] W3C WS-Architecture [permalink]
    I have added some quotes from the W3C WS-Architecture document that summarize when SOA is applicable and the characteristics of services in a SOA

  • 06/08/04 :: [Product] WSE ("WISI") 2.0 Ships [permalink]
    This is the precusor to Indigo. Release 2.0 provides support for message-oriented programming and enables asynchronous communication for Web services that involve long-lived operations, batch processing, peer to peer programs, or event driven application models. It supports WS-Security (OASIS 2004 standard), WS-Policy, WS-SecurityPolicy, WS-Trust, WS-SecureConversation and WS-Addressing

  • 06/06/04 :: [BPM] Web Services Choreography explained [permalink]
    This is a complete and clear presentation directly from the author of WS-CDL in the W3C/WS-CHOR working group. It seems that the group has found a good theoretical foundation based on pi-calculus (:-P. I was also happy to see that the group is now officially presenting the same articulation between BPEL and WS-CDL that the one I gave at the first face-to-face meeting in March 2003 (see a more sophisticated example of choreography/orchestration at https://www.ebpml.org/bpmm.ppt). I am wondering why Microsoft and IBM keep ignoring this standard, it is now inevitable that it will be an integral part of SOA. Oracle has now all the pieces of the SOA coordination tier in its hand (BPEL, WS-CAF and WS-CDL -Nick I was a bit disappointed that you don't relate your work to WS-CAF). I am really anxious and curious to see how their product line will turn out now that we know about some of the pieces... I will publish an analysis of WS-CDL in the next few days.

  • 06/06/04 :: [BPM] User Interface Process Working Group [permalink]
    I wanted to signal a new working group on GotDotNet.com lead by Pascal Recchia an outstanding architect from VCSTimeless. UIP is often the missing piece in BPM. Its role is to model user activities that can participate in business processes. The goal of this working group is to create a specification that will later be given to a standardization working group. Even though the name bares some ressemblance with the .NET UIP application block, the specification is technology neutral. Pascal will release the statement of work this week, but there are already lots of interesting discussions going on.

  • 06/06/04 :: [IP Violation] ebPML taught at NYU ! [permalink]
    I found this set of slides a couple months ago and gently notified the "author" that this slide deck was put together in complete violation of the copyright notice (the only missing slide from the presentation !!!). I gave this presentation at the XML and Intregration Forum last November in Paris. This is very sad that this kind of behavior be tolerated at this level.

  • 06/06/04 :: [Google] ebPML adds google ads [permalink]
    Some of you may have noticed, I have added some google ads to selected pages of the web site (following an idea from Didier Girard, publisher of www.application-servers.com). If it is somehow profitable to me (don't expect an IPO any time soon, I'd be happy if I recover my hosting and software cost within a year), it also supports the idea I have of the web, i.e. a network that develops peer-to-peer relationships which would have no chance to exist otherwise. After checking the content of the ads, it looks like they complement ebpml.org without establishing privileged relationships with vendors. As usual feedback is welcome: info@ebpml.org

  • 06/06/04 :: [Article] Enterprise Workflow, National Project Report [permalink]
    Gordon Docherty wrote an outstanding report about Enterprise Workflow Systems for the british government. Anybody who is considering starting a workflow project should study this document which presents the concepts, terminology and architecture of workflow systems from a technical perspective.

  • 06/05/04 :: [Article] Web services and the mainframe [permalink]
    Richard Adhikari provides a very good overview of the topic along with a review of the offerings from various companies.

  • 06/02/04 :: [Presentation] Exploiting Semantics of Web Services in eBusiness Applications [permalink]
    Asuman Dogac, a BPM pioneer, has published one of the clearest presentation I have seen on Web Services Semantics. She explores what kind of semantics are needed to fully specify and qualify a web service, how we can efficiently store and query these semantics, and how these semantics can be used in different verticals

  • 05/25/04 :: [Article] Service-Oriented Architecture: Implementation Challenges [permalink]
    Microsoft is starting a new series of articles focused on Implementation Challenges for SOA

  • 05/25/04 :: [Standards] BPMI Phase II [permalink]
    Howard Smith was kind enough to share with us his proposal to BPMI for the work ahead. I was impressed with the plans. Slide 39 caught my eyes and I feel that finally, we have a chance to bring business semantics in the picture. The presentation also talks about "users" as participants in the business processes. The main feedback I have is that the work is not focused enough the evolution of "application models". I understand that BPMI cannot specify an application model, but it remains important for the adoption of BPM technologies that someone specifies how a business process model works with applications (legacy or not).

  • 05/22/04 :: [Article] The State of Workflow [permalink]
    Tom Bayens wrote an excellent article on TSS on the current state of workflow and business process engine. He is the main driver behind the jBPM.org engine

  • 05/06/04 :: [Article] Microsoft's Next Frontier [permalink]
    Microsoft understands that the future belongs to those who can master �connected systems�. Microsoft seems to be patiently establishing technical services, tools, an application model, programming languages, and domain specific languages for service oriented computing, with an appetite for innovation that is unmatched in the industry.

  • 05/06/04 :: [Article] Aie...Wall Street Knows about Grid Computing... [permalink]
    ...and think it is the next big thing. That probably means that most companies will be compelled to do stupid things suggested by some leftover bubble analysts to get their stock in the GC list. The article starts with an interesting perspective on hardware versus software companies but I am not following the rationale provided by Jon Markman. I thought that Grid Computing was about rationalizing the use of resources and avoiding duplicates by providing on demand and provisionable access to expensive resources. How could EMC or Oracle benefit from it ;-) by selling less and avoiding duplicates? The winners should be the one that provide the grid, not the resources on the grid?

  • 05/02/04 :: [Article] BPM Tools [permalink]
    Paul Harmon wrote an excellent and timely review of BPM tools available on the market. In the past couple of weeks, Tibco bought Staffware, and today Adobe announced it bought Q-Link

Hit Counter