• ebpml
• wsper
• infoq
• Feed
• del.icio.us

02/28/08 :: [REST] REST easy... [permalink]

|

Steve got his best shot at explaining how ...

the uniform-interface constraint reduces client-server coupling and helps minimize gratuitous differences in interface and method semantics across disparate resources.

So here he starts:

One is that different resources should each have specific interfaces and methods that more accurately reflect their precise functionality.

But, Steve, have you considered that information systems where invented 8000 years ago? Have you ever understood that information systems are independent of computers and programming languages? Do you understand that you "inter-act" with information, you just don't crud around at will? You also query or research information, and it subscribes to or produces events (the occurrence of a particular state). This is inherent to information, independent of any programming model. This is not engrained in the minds of the developers, this is engrained in information systems design, of which you seem to ignore the most basic details.

those who raise this objection fail to properly consider the effects of networking and distribution.

If you ignore "inter-actions" and events and you try to remote your crud operations, sure enough what you say is true. Inter-actions are the easiest to monitor and "intermediate" because they represent a unit of work. Just try to intermediate or monitor when someone is cruding around.

You continue:

As we’ll see, the purpose and form of exchanged data in REST differ significantly from those of other systems

So you explain:

the definitions they encourage greatly resemble typical programming language method definitions.

But do you understand just a thing about XML? Do you understand that X stands for eXtensible? Have you ever seen an IDL prior to WSDL that enabled forward compatibility? No, XML does not represent any think like structures in a traditional programming language. Do you understand that you can create "projection" of an XML document, you can transform it at will, and most importantly, you can access its content semantically without ever understanding the overall structure of the document, using relative XPath statements. Do you think you can achieve things like CAM or CCTS in "traditional programming languages"? Where do you come from, where have you been for the past 10 years? Don't you ever talk to Tim? This is no RPC, just like WSDL is an "inter-action" definition language which supports "Orchestration" and "Choreography". Again, where have you been? what are you talking about?

Consider the coupling that these constructed types induce within a local application between a caller and a function or method it calls.

Precisely, this is the whole beauty of XML, it is nothing to do with the "uniform" interface.

The caller and called method are also either compiled together into the same application or are strongly connected via dynamic loading

Again, this is a very surprising statement for somebody who lead the development of an ESB. I can appreciate why some people are criticizing some aspects of an ESB, but you can't argue that an ESB makes your statement above invalid. If you look at Oracle SOA Suite 11g, you will see that they reduced the ESB to its right size a "mediator" component that can be put in place in an assembly precisely to avoid consumer and provider to be totally coupled.

Either way, changing the constructed type’s definition means recompiling both the caller and the called method.

This could not be more fallacious. You want us to make the connection "this is what happen in Java and C++", "Java and C++ are RPC", by the way "WSDL is RPC too right?" therefore it is true for WSDL. Do you think your readers are stupid? Why do you propagate such false statements?

And you don't stop here, here is the best statement of your paper:

changing the definition of any specialized data type shared across those applications is fraught with problems.

Really? because now, REST does not even share data definitions? a uniform interface and a blob of data, naturally, pick what you want, and voila. In REST you don't share anything, of course, why didn't I think of that before? I really thought that the reviewers at IEEE IC where a bit better to avoid letting this kind of thing pass through but I guess not.

A client might also replace the state of the employee details by using PUT to send a new state representation, also in HTML form.

Yes, of course, this is super realistic. Why don't I PUT the new balance of my bank account? That'd be a lot easier. The bank would save money with less IT people that write useless business logic.

Resource representations do, however, help alleviate some datacoupling problems because they’re not tied to the underlying protocol.

You mean the content of a SOAP Body is of course tied to the SOAP protocol? right?

A REST resource’s ability to handle state representations in different formats makes it easier to support a wider variety of client applications. It lets clients minimize their data coupling to the resource by choosing which representation is best for them.

Yes this is of great value, as noted yesterday. At least we agree on something.

In HTTP, message payloads are identified using standard Internet Assigned Numbers Authority (IANA) Multipurpose Internet Mail Extensions (MIME) media types.

Has anyone looked at the IANA Media Types web site? I am sure every one who has decided to walk away from REST. Why don't you compare this one (picked totally randomly) to an XML Schema definition of a message type in WSDL? Natural Language it is. And of course as you write an application you are going to expose you media type definition to IANA and the world, write an RFC, submit it to the Internet Society.

The fact that IANA controls these media type definitions means that they’ll never change, which eliminates a lot of versioning related churn and uncertainty.

Wow, you mean, once I submitted to IANA, that's it. I am done, can't never change it? I am sure lots of people are going to line up to submit their favorite type to the IANA. No more Churn, no uncertainty, Yes We Can.

Now the piece de resistance.

they, rather than the resources, maintain application state. Resource representations contain hyperlinks to help applications know how to perform application state transitions.

Yes, the very question you set out to answer, here it is. Since they contain "hyperlinks" you are done, of course, the consumer naturally speaking knows what these hyperlinks are. Makes sense, ...not. We went over and over and over this question and you write a new article to say the same erroneous statement that even the REST community acknowledges.

An application looking for information about a given employee need only follow the relevant hyperlinks using data and metadata within the representation as a guide.

How can you be sure that this is a link of such kind. How do you know it is a series of employees? How do you know a link is a contract? a benefit sheet?

What a waste of time, don't you think we have better things to do? I think by this time even Roy might the tired to ear the kind of things you write. You are actually taking a great idea: the architecture of the Web (as it was originally designed) and trashing it trying to apply to things it was never designed for and it can't handle.

02/26/08 :: [REST] What's Great About REST [permalink]

Interesting combination of posts on Stefan's blog: REST doubts and the announcement of Steve's interview at QCon.

Let me do with Steve first. Steve, we actually have a similar background, I am also an EE self-trained developer. I think I taught about 100 more classes in software engineering than I took. I just want to point out two things you said.

First, you say:

There's a problem if you have to define something in IDL just to know how to use it. That doesn't really work. No one takes an IDL and says: "Here's this method, I call this and I pass this. I just look at the IDL and I know what to do".

Nobody does that. IDL is really for code generation. If I want to know how to use a service whether it has IDL or not, I go talk and talk to the developers, if they're nearby; if they're not I look at their documentation.

Steve, could you consider just one second what an "assembly" is. Come on, you are an Electrical Engineer, how could this concept ever escape you? Can you create an assembly without an interface? Have you tried to wire "Natural Language Service Description" (p210 of the RESTFul Web Services book).

Second you talk about Erlang:

it has to fail over in case of problems with one of the nodes, or you need fault tolerance, all the reliability issues, and then the whole concurrency thing which is where you spend a lot of time just figuring out ...

Steve, Erlang is great at what it is doing, I can appreciate the exceptional activation model and the lack of shared memory, but do you really think this is the ultimate programming language (I don't think you do). My point is  why not create a programming language from scratch that solve all these problems, specifically designed to build composite information systems? Isn't it time that we think of a programming model rather than programming languages on one side and middleware on the other? It made sense 20 years ago, but this view is completely outdated.

Before I take my final stab at REST, I would like to underline what I find great about REST:

• the resource concept: this is an integral part of the programming model
• resource representations as an interaction model between provider and consumer and media type mediation (though I like role mediation better than type mediation)
• extensible QBE interface
• safety and idempotence (that's a big one)
• consumer oriented error messages
• the programming model when the consumer is a client
• (Please note that I did not say that the URI concept was great)

The first 5 items can easily be emulated in the web services stack. QBEs are trivial to specify in WSDL and you can create forward compatible WSDLs by expanding the number of QBEs in your interface definition. Please note with SDO, WS-* has already a very advanced representation update mechanism.

Now, before I started this discussion I used to see REST with a good eye. I used to say "Use it where you can, and WSDL where you can't". I must admit that after reading the book RESTful Web Services (which I got at the King County Library), my recommendation is really don't use REST at all, and here is why:

a) when the consumer is a browser, Tuscany's latest widget bindings allow you use a "Service Oriented" model up to the browser. Jean-Sebastien gave me a demo of what the Tuscany team was doing. It is simply spectacular. I did not expect it would turn out that way, but IMHO, SCA signs the death of REST because it takes away the only competitive advantage REST has over WS-*: the browser-to-service relationship.

b) The REST community is thinking of REST as a CRUD-Oriented Architecture (you don't have to do it that way, but this model is so engrained that they can't think differently). This has been exemplified by the recent "Partial Update" discussion started by Joe Gregorio. It culminated with Joe concluding that it had to make "a variable" a "resource". Let me give you a piece of advice, when you create a programming concept that is based on the concept "foo" and you reach the conclusion: look ma', it is beeoutiful, everything is a "foo" even a variable is a "foo", then you are on the wrong path, you can end your work immediately.

c) REST is CRUD-Oriented because the REST community wants to manipulate the resource content and state from the consumer. Most of the REST community does not understand that there is a difference between expressing the changes you made to the resource representation and CRUDing the resource directly. This is what the old guard of architects have been doing for over 30 years and this is wrong. This is what Service Orientation is suggesting you don't do (though you can do CRUD-OAs with WSDL and SOAP just as well, this was the SalesForce.com API at some point -some people even built an ADO.Net adapter on top of their WSDL interface LoL).

You can see the CRUD spreading just about everywhere: here in RESTful Rails, or here in the RESTful Web Services book (p188):

The Controler code: the code that converts incoming requests into specific actions on the database.

In 2004 Thinking-out-loud (??) had already identified this problem:

I have seen several systems that on the surface appear to be doing the RightThang (tm), in that they are developing with the latest and greatest technologies and platfoms, e.g. J2EE or .NET, they are following iterative and incremental development processes, and all of their application interfaces are exposed via web services.

The problem is that they didn't know when to say when, and that led to basically a massive collection of CRUD-oriented interfaces on top of entity/domain class concepts, i.e. there ends up being a service per entity, say, for example, Employee, and the operations are basically CreateEmployee, SaveEmployee, FindEmployee, DeleteEmployee. The service should be defined at a business semantic that expresses a sense of acheiving a user/business goal. For the Employee example, for example, business operations might be Hire, Terminate, Promote, etc.

d) The REST community is "religious" about where the application state should reside. Let me quote Richardson and Ruby:

Statelessness means that every HTTP request happens in complete isolation. When the client makes an HTTP request, it includes all information necessary for the server to fulfill that request. (p86)

This could not be more wrong. This is why RESTians are CRUDing in all the time. All resources are "stateful" and as a mater of fact can participate in multiple "applications" simultaneously. A PO, an Invoice, a ticket, a trip... all have a lifecycle independent of the "application" that advance their state. This is IMHO, one of the two worst architectural mistake the REST community is making. Yes, a web page does not have a complex lifecycle and of course, this statement is correct in that very limited (yet widely abundant) scenario. Again, nothing says you have to do that, but the REST community will take years to understand why it is bad. Instead they prefer to CRUD the resource to death (LoL). Incidentally, Mark, calling "state" both the resource "content" and the resource "state" with respect to its lifecycle is not going to help you architect a solution the right way, it will simply encourage you to CRUD around.

e) The second worst architectural mistake is inherent to REST itself, it is the URI concept. This is the Achilles' heel of REST and this is deadly as soon as you go away from web pages and feeds and into the world of information systems. URI mixes the concept of identity and "accession" while "flattening" the accessor query language. There is no real concept of identity in REST and this is deadly. This bolts getters and putters to the resource and creates a versioning nightmare. Not to mention that it prevents you to compare two resource representations. URIs are QBEs. Nothing less, nothing more. You would be creating a huge mess if you let them "hang" around in "consumer state" longer than they would otherwise stay in a browser. URIs are a lot more transient (in the real world) than the REST community want you to believe (of course, again, in the case of a web page or a feed, it works).

f) All this and Stefan's list as well could be fixed. The problem is that the REST community has made fun of the ebXMLers and WS-Starers. They never appreciated how difficult it is to write a spec. It requires giving a lot of yourself, a tremendous amount of energy and focus. Not to mention that there are always a couple idiots that want to derail the spec to match their inferior product, get a (hidden) consulting gig... or simply out of ignorance.

Guys, I like you, I respect you, you are smart and want to do good things and deliver value. I have no doubt of that. But please, be honest: fix REST or ditch it and relax...

02/24/08 :: [SOA] SCA and JBI bring nothing to the SOA TablE  [permalink]

Somebody brought to my attention Jason Bloomberg's opinion about these technologies (CIRCA May 2007) and asked me what's the big fuss about SCA? Jason argues:

JBI, [...] is essentially a Java plug-in architecture that you could use to build a Java-based ESB.

[SCA is] a component architecture for building service components, which are pieces of software that could consume or provide services

He continues:

SCA is more about building components that consume services. So its for doing traditional development where you consume services, if that's part of what you want to do, but it's not about building services

Jason thinks:

it more difficult to come up with a truly service-oriented approach. Because on the one hand JBI is saying build all your services in Java so we can plug them into this Java infrastructure. The SCA world is saying well let's think of services as components, so we can do traditional component development. It's not a service-oriented approach either.

He then bring OO in the picture:

It is object-oriented development. We're going to build objects. Objects are going to have interfaces. Sometimes the interfaces are service interfaces, sometimes they're other kinds of interfaces. We're working in the object-oriented paradigm where we are not able to support services in the OO paradigm as opposed to saying let's work in the service-oriented paradigm and think about how we are going to deal with objects in the service-oriented world.

It is quite unfortunate for someone who runs a "SOA Analyst Firm" to be so ignorant about SOA and how to position underlying technologies in a Service Oriented Architecture including OO.

I am going to try to make it short and sweet. I have advocated the concept of using BPEL and Service Interactions since July 2002, well before anybody started to work on SCA. in 2003 and 2004, our working group at OASIS delivered the first assembly concept in the OASIS ebXML Business Process v2.0.4 specification, with support for both ebXML and Web Services.

So here are my comments. His first statement above is correct. Yes, JBI was thought to be a modular architecture for Java based ESBs. It fits very well one of the possible topologies of loose coupling that I described here. Sun actually complemented JBI with an assembly paradigm which proves how important this concept has become since 2002.

Then Jason starts diverging when he says "So its for doing traditional development where you consume services, if that's part of what you want to do, but it's not about building services". What he has in mind is "Web Services". He has looked at the prototypical SCA assembly pictures and he has seen a "Web Service" hanging at the back of an SCA assembly and concluded erroneously that you would do "traditional" development and from time to time you would invoke a "Web Service". Jason could not be more wrong.

He continues to be completely wrong by saying: "JBI is saying build all your services in Java". JBI's binding components can connect to "anything". Sure enough the ESB itself is implemented in Java, but the binding component can reach anywhere. This is the point of an ESB. Jason again thinks in terms of "Service Engines" and see them implemented in Java, but they are really for the Loose Coupling (LC) code, not for the service implementation itself.

Jason sees it as "It is object-oriented development". LoL, "Sometimes the interfaces are service interfaces, sometimes they're other kinds of interfaces." And what could be the other kinds of interfaces? "We're working in the object-oriented paradigm where we are not able to support services", Really?

I have said it and I'll say it again, there are several core differences between SO and OO:

a) the interface in SO is bi-directional, in OO the "references" are not explicit, hence Spring, OSGi...

b) activation: in OO, there is no "activation" framework. All method invocations are serialized, Bertrand Meyer has written enough articles about Object and Concurrency to make it clear

c) in OO there is a "one-to-one" relationship between method and implementation. in SO, several operations can be tied onto the same implementation (BPEL is the best example).

SCA, finally, digs us out of the pre-historic "CRUD-Oriented Architecture" that has been the bread and butter of an old generation of architects for the last 30 years. SCA IS-THE technology that is bringing "peer-to-peer asynchronous inter-actions" at the core of the application model. SCA is one of the most elegant and most important technologies I have ever seen because it is changing radically the application model from OO to SO without disrupting existing technologies. This is not about replacing Java, this is not about adding orchestration concepts to every language under the Sun, it is about enabling the definition of inter-action based interfaces and enabling older technologies to leverage orchestration concept today without any disruption. How smart is that? Mike Edwards and a few others who have invented SCA are some of the most important thinkers of the last 30 years. SCA enables SOA, SCA is SOA, SCA brings SOA to everybody.

Finally we can move on from the antiquated, Synchronous, CRUD-oriented, Client/Server application model that has brought IT to its knees and leverage an Asynchronous Service Oriented Peer-to-Peer model to create the information systems of the 21st century.

Yes, SCA is changing a lot of things, but not in a revolutionary way, it is not about replacing skills but augmenting them. It is not about killing Java (politically), it is about augmenting it.

As Mike points it out in his response to Jason, SCA is the technology that enables composition. It is also the technology that finally gives us the correct foundation for BPM.

If I were a member of this core team that created SCA from scratch, I'd be quite proud of these accomplishments.

02/23/08 :: [Election] Flash-Oriented Democracy: Lessig08  [permalink]

I almost fell off my seat a couple days ago while drinking my favorite caffeinated beverage. Larry Lessig is now considering running for congress. After endorsing Obama, he is now on a mission to fix Washington (DC).

If none of "we, the people" could disagree with him on his assessment of the political system, he is as usual fairly sparse on how it should be fixed. From a foreigner's perspective, it looks like the US have invented, pragmatically, legalized corruption, while in other countries corruption exist anyways except that it's not legal and sometimes -rarely- people get caught.

So if Larry probably considers himself one of the "better" people, on a mission change a bad system, I would advise him to think twice about what democracy really means, because he seems to have forgotten some of the basic fundamentals. Democracy is not about words flashing subliminally on some kind of screen, democracy is not about somebody coaching a warm "Yes You Can", democracy is not even about character, democracy is about accountability and integrity. Democracy is about pushing candidates to define their vision in the most excruciating details, democracy is about testing their values, their thoughts and beliefs to the greatest extend possible. This is why primaries are such a great democratic system. This is why the Web is such a great tool to strengthen the democratic process. As with any tools, some will choose to use it in the opposite direction, Larry Lessing is one of them. 

02/19/08 :: [Election] Only One, and One Only  [permalink]

|

When it comes to thinking, I consider myself as being one of the most basic thinker. I understand the dangers of thinking at a too low level, but most of the time, my mind can't really think in an elaborate fashion.

I have been doing some reading on the energy section of the candidates web sites, and I found one thing missing. Yes they talk about spending in R&D, bulbs and electric cars, ...yawn... but the US (and the world) doesn't really have a clean way to produce electricity. Sure emissions are less because you are not using energy when the car is idle. I actually turn off my car at some select traffic lights that last about 2 minutes (though I am not sure about the effect, my mileage gauge seems to tell me that I am right).

Now, I found one thing missing. Just one. I would call it the "Telecommuter's act". It would require that by 2010, in selected industries (obviously not manufacturing or fishing), or better, for selected roles, we require that at least 60% of these roles telecommute at least 60% of their time. I work downtown Seattle, and I love it, I also like better to meet people rather than attending a conference call. But, this is an instant measure that can solve a lot of problems:

• less roads needed
• less car needed
• new square footage for building apartments
• less traffic jams
• Increased spending (or saving) capacity
• More time for parenting and contributing to the community
• Healthier, more vibrant communities

When it comes to the economy, I see it in very simple terms. The goal of an economy is to maximize our capacity to swap our time to meet the needs of society. This is why I find insane that someone could acquire the capability to swap its time against the time of more than 100-1000 person, let alone 30,000. This is also why, when I look at all the crud that our society produces and waste, I often think that we could use our time better. This is also why I am confident that a major change in activity swapping is not likely to create major disruption in the economy.

In the last 10 years, I have seen or heard of major road projects: the Boston big dig, the Seattle viaduct... We are talking I think $15 billion for the Boston big dig, again, based on my calculation, this is roughly the work of 8,000 people for 40 years. Is it really worth it so enslave 8,000 people for a stretch of 4 miles in Downtown Boston? This is also as much as the entire world invested for Nuclear Fusion research (not Nuclear Fission) which is the cleanest and most sustainable way to produce energy. Can you imagine the amount of infrastructure that we are building for nothing? Can you imagine the square-footage of buildings that we are building for nothing?

I know this would be disruptive to a few developers and investors. But, can you imagine converting 40% of buildings into condos? won't you think that homelessness could be reduced to zero, overnight? King county is trying to eliminate homelesness, don't we think it is possible? don't you think there is enough square footage across the country to give a decent roof to anyone? 

Don't we think that a lot of the world's problems would be easier to deal with if western countries would consume less oil?

It would just take some courage.

02/17/08 :: [SOA] REST: CRUD-Oriented Architecture - III  [permalink]

I think Tim Bray nailed it (maybe involuntarily).

Joe Gregorio of Google, in How to do RESTful Partial Updates, proposed overloading PUT to update resources in a way that’s constrained using URI templates.

It's Important. The problem Joe’s trying to solve keeps coming up.

It's hard...the POST-a-feed idea came up. And in fairly short order after that, it got shot down. People thought up all sorts of corner cases and problems. The two that stick to my mind were authorization and error handling. Can you specify different auth data for each of the ten thousand entries in the feed, and how do you react when twenty-seven of the ten thousand fail to update for some reason or another?

I can tell you authoritatively that we do not have consensus here; rough, smooth, or any other kind

Tim, have you ever considered that you are trying to solve the wrong problem? Don't you understand that CRUDing from the consumer side is hopeless? Don't you understand that a resource is not just a blob of data that you can manipulate at will? Don't you understand that when you are CRUDing around you are pushing millions of LOCs on the consumer side that have nothing to do there? Don't you understand that CRUDing around results in strong coupling between the representation consumer and the resource owner?

Tim, don't you understand that there is a fundamental difference between expressing the changes you made to a resource representation as part of an inter-action and the expression of what you want the resource to look like once it is updated? Why would a resource consumer had to anything to do with the later? Don't you think the former is a much more reasonable thing to express?

Tim, don't you get it that inter-actions are the only way forward? Don't you agree that a resource lifecycles (i.e. an inter-action model) are able to handle any kind of error condition -and trans-actions- in a far more efficient way (whether it is part of a batch or individual request)? When the 27th interaction fails, we have an inter-action context. The resource lifecycle knows what to do, you don't push this logic at the collection level. Same is true for authorization.

I know, in your mind, inter-actions and resource lifecyles, is not RESTful, because you are erroneously thinking that the resource lifecycle belongs to the application state, when in reality it doesn't. So you are hitting a dead end -a cul-de-sac- because you will be spinning for the next decade without ever finding a solution. No wonder you can't find a consensus. 

How much longer will we have to endure CRUD Oriented Architectures?

02/15/08 :: [SOA] SaaS: CRUD-Oriented Architecture - II  [permalink]

Well, it did not take long to find a post echoing some of my concerns about SaaS (albeit expressed with a lot more talent). Greg Olsen CTO of CogHead wrote this post that substantiates what I expressed here. A lot of the SaaS vendors jumped head first into building their SaaS offering on CRUD-oriented architectures. Creg claims:

We are now at point where implementors of SaaS capabilities are being disrupted by newer SaaS capabilities. Services that are built largely from other services are a reality, and offer many clear advantages.

Wow? why didn't I think of that before? Sorry, I really don't enjoy being sarcastic, but can you not be? You keep telling people the problem is CRUD-oriented architecture and they don't listen, they even flame you sometimes (and I don't even tell you what they are trying to do to you). But the reality is as long as people will be CRUDing around, we will drawn in the same architectural vortex we have been almost ever since information systems landed on a computer (computers are really good at computing -if you know what I mean). You want a proof that people are still CRUDing around? look no further than Joe Gregorio's latest post on how to do RESTful partial updates. The comments are hilarious, including the discussion with James Snell. We are now down to "a variable is a resource" argument. It really reminds me of the pi-calculus days when Assaf and Howard Smith were marveling at "a variable is a process". This is also reminiscent to Steve Vinoski's uniform interface incantations.

Guys, wake the f--- up, without a composition model you are doomed, as doomed as the first generation SaaS vendors. It should not take a rocket scientist to figure that out, but I guess it does. Greg continues:

The move to SaaS applications built on SaaS is a much more profound shift than the move from on-premise applications to SaaS applications.

By leveraging service options like Amazon’s EC2 and S3, a small company can deploy a complex, highly available and scalable multi-user software application — without huge upfront investments in hardware or software infrastructure. Likewise, a very small company can build a simple, narrowly focused service and can cost-effectively sell it to a mass audience. Neither of these companies would have been possible only a short time ago.

A new software service economy is rapidly unfolding and is causing disruption in the software industry. Ironically, some of the first victims of this new economy may be some pioneers of the software-as-a-service movement.

CRUD oriented architectures are a thing of the past, on-premise or off-premise. The ones left without a composition model will be immediate casualties. REST will not have time to adjust to this wave of services coming our way because no one in the REST community is thinking about composition other than at the presentation layer, nor people will have time to build these services in a RESTful way. Common guys, even Joe can't write a URL without a verb in it.

Consumption via composition is the only viable model.

02/14/08 :: [SOA] SaaS: CRUD-Oriented Architecture?  [permalink]

I stumbled on this report from GSX: SaaS, spurring innovation, enhancing business value and enabling business processes.

This is one of the better report I have seen on SaaS. As a starter, I would like to re-iterate my position on SaaS. SaaS is a transient state of the industry. It marks the beginning of an evolution (the utilization of the Web in the application model), it is not an end in itself. The problem with SaaS (as it is defined today) is that we are still using a CRUD-oriented monolithic architecture where business processes, resources and services are not explicit. Yes, from a business model, SaaS wins hands down compared to the hassle of implementing-deploying-operating-upgrading cycle. SaaS took all the costs incurred by software utilization and centralized them to drive economies of scale.

But,... SaaS gives you agility in one dimension only: upgradability. This is why I disagree with one of the belief of the report:

Software as a Service will be more profound than most industry observers currently assume.

SaaS is going to displace traditional business software models, no questions, but beyond? The forces that will crunch SaaS (as we know it today) are too big to be ignored.

Reporting across SaaS silos? How about BI-aaS? no, that won't work, why? the reason is very simple. What makes SaaS attractive is upgradability. This means that the SaaS provider is really in control of your information model. How are they going to be able to guarantee that any evolution of the system of record is forward compatible with your reporting infrastructure?

Integration across SaaS silos? IaaS? no that won't work either for the same reasons. You are going to trade off upgradability for stability. In other words, your ability to upgrade is bounded by the stability of integration with other solutions, not just by cost.

Last, but not least, business process innovation? You have now mostly surrendered your ability to innovate to the SaaS provider (remember, you just laid off your delivery team?).

The best proof of what I am saying is that one of the report's tag line is "Spurring Innovation". Sounds great to hear, but the report does not substantiate just once how SaaS is going to spur innovation, because the reality is that SaaS hinders competitive innovation. It might actually get you in a bigger mess than before because your SaaS provider is not going to provide you with SLAs around upgradability.

IMHO, SaaS is going to evolve rapidly in the next 3-5 years with the emergence of Business Process Platforms (IBM, Oracle, SAP), to become the system of record and the value add services that are assembled into business processes.

• Service versioning is far more practical as SaaS versioning
• Business activity monitoring and complex event processing is far more practical than BI in a SaaS world
• Business Process Platform do not require "integration", "integration" is part of the programming model
• Innovation is far more practical in a BPP / SOA world than in a SaaS world

Interestingly, the GXS report does not talk about "architecture" either (since SaaS is based on an old CRUD-oriented archtiecture), if they had spent about 30 seconds on this topic they might have come up to the same conclusions.

02/10/08 :: [Other] How?  [permalink]

As a foreigner living in the United States, I have no say in American elections. So I just have questions -as usual :-)

Stefan posted an interesting point of view favoring Obama over Clinton.

First, I'd like to say that as a European I believe in a strong America. I believe so much in this position that I came here to contribute to it. I am not sure as a young nation the United States have always matched their power with wisdom, but this is for another debate.

Over the last 8 years, the United States have weakened considerably, tremendously, tragically, financially, militarily, economically and to a certain degree scientifically. 

America is indeed the land of opportunities and not connections. I was brought to this country by Hughes Aircraft to work on my dream project -without any connection. Never France had given me this kind of opportunity. Never. And I did things for Hughes that some professor from CU had proven theoretically impossible. Before that I was a graduate student at Penn State in the late 80s and there again, I had the freedom to think and do what I wanted. There was no barriers, there was no irony, only results and papers. It's ok to be different here. In France during my Ph.D. I was an alien. I was the first student in my lab to actually "type" his thesis (on a Mac). I also wrote all kinds of software during my Ph.D. one of them became a commercial software (that went on to be bought by the Fusion Reactor research lab in Provence and other research labs around the world). That drew some irony, here people would have seen it simply as successful research.

Obama may well be one of the most brilliant proof that as long as you can do the job, you are in, regardless of your (modest) origins, wealth, religion, gender and other attributes that some people like to consider.

This country has proven beyond reasonable doubt that freedom is what makes the world better. The freedom to think, the freedom to live your life following your own beliefs and the freedom to pursue your dreams. I was once very proud that my children were American.

Yet, this country has changed so much in the last 8 years, that I have trouble to think I believe what I have heard and seen. For someone who boarded Flight AA11 less than a month before it crashed in the World Trade Center, I have trouble to think that this event alone changed America in this direction.

I mean who would have thought that a candidate to an American presidential election would answer the question about why he would not withdraw from the race since he had no chance to win by: "I did not major in Math, I majored in Miracles".

Who would have thought that after the superbowl a receiver would explain, on the evening news, his miraculous catch with the intervention of God. You mean God watches the superbowl? he actually intervened to pick the winner?  In the past people talked about angels. Nowadays, this is so passé, you want the boss.

Who would have thought that ET Magazine at 7:30 in the evening would explain how water boarding torture works, just like it was a new form of entertainment?

I don't listen to NPR any more because way back in 2003 as I was driving to work, I was sickened by their call to a "just war" that would "fix the middle east" once and for all and "ensure America's security". In 2006, with inquisition style techniques the same journalists, with the same voices, were grilling senators who had voted for the war. But where was the press in 2003? Where was America then? Debating over how we should rename French Fries of course.

I feel today that America, in little under 8 years, has not just lost its mind, it lost its soul, it lost its sense of direction and purpose. And I am worried, extremely worried for the future -of not just America.

Most worrisome of all is that the presidential  debate is replaced by a "party", almost a "craze" fueled by Web 2.0 (SOA seems to be out of the plot). I am extremely disturbed by Lawrence Lessig's presentation.  I am deeply and totally disturbed that few of the candidates are laying out their vision for returning America its leadership. I am deeply and totally disturbed that no-one (I really mean not enough people) in the United States seem to care to listen about what their candidates will do. Sarkozy in France was elected on very specific policies. Of course, no one could predict that his personal life could interfere so much, but this is another story.

Larry Lessig actually evacuates the policy question as fallaciously as insidiously as possible in a couple of sentences:

I know [Obama's] technology policies and they are quite good.

Policy Differences are quite small, the NY Times says there is no real gulf separating the two. [i.e. If you like Clinton's policy you will like Obama's].

On policy alone there is no reason to choose one of the other. There are things that are more important than a laundry list of policies...

Larry Lessig's Web 2.0 stunt uses the "Roveanism" argument to kill any debate. I know questions are often a problem in a world where science has made so much progress, has created so much understanding. Often people don't like questions because it tarnishes their little, otherwise perfect, scenario. But Larry is worse than Carl Rove, because Rove was not about shutting down debates, he was about weaknesses and strengths. Larry, in a post-Rovean style, is about killing the debate altogether. There is no need to understand what a president will do, it is just as good as any other. Did he really mean that just by re-naming a  President, like someone renamed French Fries, things will all the sudden be better?

I am sorry to say that an average American is far, extremely far from understanding the policies that each candidate will apply, either by reading the press or by watching TV.

So, I just have a few questions to the candidates.

• What will be your energy policy? and more generally what will be your policies towards natural resources?
• What will you change in the way the markets operate?
• What are your priorities to respond to the needs of your citizen?
• What will be your plan to lower inequalities in America and in the world?
• How do you plan to end the occupation of Irak in a way that will keep or increase the region's stability?

If the candidate can't answer these questions satisfatorily, he or she will be asked to say "I am not smarter than George Bush" (which probably will remain in history as the worst possible president).

We deeply and totally need somebody real, like real.

America has lost its freedom.

 

02/09/08 :: [XO] XO Rocks [permalink]

|

I continued discovering the XO with the kids over the week end.

The form factor is definitely great to help the kids with their homework. I showed my daughter how to use the dictionary at reference.com. He immediate reaction was that I was teaching her how to cheat, but I explained her that if you did not know the spelling of a word, you had to learn it from somewhere. I can see how having a reference source handy could really help her learn faster and better.

We played with eToy, an activity built in Squeak Small Talk System. EToy is a "a full-fledged, general purpose, multimedia ready, integrated development environment".

In this sample, the child can draw a shape, say a car and then can use a palette of instructions to move the car.

We played with some random number generator.

This is another version where the car is able to follow a track by itself.

You can play to, there is a developer image that you install on your PC.

Wow !

 

02/09/08 :: [SOA] SCA Rocks  [permalink]

|

This is week, the Tuscany team released the Tuscany Java 1.1 version. This is a major leap forward for SCA as it adds assemblies to Web 2.0.

Tuscany's fruit market sample shows how all this works:

Here is the assembly:

You just need to decorate your favorite JavaScript code as follows:

//@Reference
var catalog = new Reference("Catalog");
//@Reference
var shoppingCart = new Reference("ShoppingCart");

And the SCA infrastructure generates a store.js that does all the Ajax plumbing (JSON RPC or Atom).

<script type="text/javascript" src="store.js"></script>

This is pretty much what I was explaining in this post (Understanding SOA). I would not be surprised if the Tuscany team later develops the same kind of capabilities for WS-BPEL HumanTasks to complete the presentation layer.

I also spent some time exploring the latest Oracle SOA Infrastructure (11g) which includes an SCA implementation. I liked a lot what I was seeing. The latest beta has still a couple of glitches. I would like to draw you attention on the Mediator concept which basically provides a model driven implementation of the LC code that I was talking about in my infamous post about loose-coupling.

With so much power under the cover, I don't see why anyone would waste any more time with REST or Erlang. You have one of the most powerful development environment offering a true Resource Oriented Architecture, founded on asynchronous, peer-to-peer inter-actions (WSDL & BPEL) and composition (assemblies). It is not perfect here there are still a few things to fix, but be assured that this will happen.

There was also an interesting discussion on the Tuscany user list. Can a web service call another? I still owes this sample to David Chappell. Basically, Simon Nash says yes:

We have a few samples that show how to do this. You can either define the reference and service using explicit WSDL files, or you can let the Tuscany runtime generate these for you.

But, I want to build a "real-world" example to prove David wrong. See the tremendous value that SCA brings is that it separates the bindings from the WSDL definition (which is really what ebXML has been doing from the very beginning with the concept of Collaboration, Collaboration Profile and Collaboration Agreement). SCA doesn't really need a "collaboration profile" because the point of the SCA infrastructure is to support all possible of bindings and choose the one that's most appropriate for a given assembly. The "agreement" is the assembly. The ebXML ebBP specification supports arbitrary Web Service "assemblies" since 2004 (yes I meant to say WS assemblies, not just ebXML collaborations since being such good citizen we did not discriminate we allowed both to coexist in a collaboration, and in particular, Web Services only collaborations).

This is the example that Simon is talking about:

 

What you can see here is that the "end-point" is defined at assembly time and no longer at the time you design the WSDL. This is a major change, but it is profound. It is resolving a vexing issue that made it difficult to deal with "outbound" operations (out and out-in). The old remoting guys can now retire, the game is over. There is a new programming model in town. It is here to stay, it is here to change fundamentally everything we have done "the old way".

02/02/08 :: [XO] Got the XOs  [permalink]

|

The XOs came yesterday afternoon (no they did not forget). This morning I realized that one of them ended up in my son's back pack "by accident" as he explained to me.

I must admit it is all I imagined they would be and probably a bit more.

The great

This is really a computer designed for kids. The form factor is great from 1st grade to six grade or so. It definitely beats Amazon's Kindle IMHO. The XO's browser is wired to the International Children's Digital Library. The OS's paradigm is "activity" based. There is a journal that keeps track of the kids activity so that he or she can return to what they were doing.

The computer comes with tons of applications, some of them can be downloaded.

Computers can be meshed together and the kids can start chatting.

There a couple of great sound applications (an oscilloscope that reminded me of NeXT and a sound mashup)

There is a great application (scratch) that introduces kids to the concept of programming.

The good

I was a bit concerned by the screen, but it looks good enough to work and read ebooks (you can navigate books when the screen is folded on the keyboard).

Google Docs works but Zoho doesn't. FlashReader works !  Some of the kids web site using flash did not work completely (which was not a disappointment :-)

The power consumption is great, battery life is extensive.

The case looks robust enough to handle a kid's abuse.

The bad

I must admit it is a tiny bit slow. You really have to know what you want to do (like in a class) because it take time to switch activity.

The touchpad is a bit cheap.

Bottom line, kids love it (and dad too).

02/02/08 :: [Other] Trans-actions and Composition  [permalink]

Peter Rosenberg asked a very interesting question. He said

you don't touch upon the nasty job of doing 'Fall Back' transactions for Loosely Coupled systems. If not at least centralized (i.e. same as Spaghetti) the 'Fall Back' transactions will never be designed nor developed, causing havoc databases over time.

he adds:

But the Web Services 'hype', seems to offer (or sell) the option of binding transactions together, to form somewhat odd 'GRAND TRANSACTION', in a loosely coupled fashion.

This is of course playing with fire since the 'owners' (i.e. Service Providers) of these Transactions may not have been orchestrated into some sort of agreement to be part of such 'Grand Transaction'. Not to mention the rules by which they can be rolled back as if they were never executed (2-Phase Commit, and similar).

If I understand correctly, Peter is basically saying that a trans-action does not exist "in isolation" of a larger choreography/collaboration. In other words, you can't arbitrarily expose actions which can be enrolled in a transaction without the knowledge of what inter-actions surround the trans-action. In particular this is how compensating trans-action can be developed.

My definition of a trans-action is the coordinated invocation of actions on resources with the purpose of aligning their state. At the end of the transaction whether the action invocations succeed or not, the state of the resources is aligned (they both know unequivocally in which state the other resources are). So a trans-action is not an inter-action, the actions being invoked are not coupled to each other, even when a compensating trans-action is invoked by the transaction coordinator, they should not have to know about each other's compensation logic.

First, I would like to point out that a good way to avoid: "causing havoc databases over time", is to use a "resource lifecycle service", if you push the responsibility of maintaining the integrity of the the resource lifecycle to the resource consumer, yes you will reach this point inevitably. The resource lifecycle has to be designed to always maintain the resource integrity. A resource lifecycle is what you mashup. The goal of the mashup is not to own the business logic of the lifecycle. Incidentally, this is why REST works so well when a user is interacting with the resource, because precisely it allows the resource to manage its lifecycle. This is also why I am so vocal against Steve Vinoski's position of a uniform interface at the resource-resource interaction level which will be used inevitably in a CRUD fashion creating a massive coupling between the two resources. Don Box suggested to use XQuery in a similar fashion, and IMHO, the resulting coupling is the same.

Now, to answer your question I would say, that yes, a "trans-action" is definitely part of a larger choreography since actions are part of the resource lifecycle, but I do believe that not just one choreography is possible and unless you are in the case of large B2B community, you are better off giving people the flexibility to create their own assembly.

I already touched on the debate "assembly" versus "choreography" here. IMHO, you want to use an assembly unless the number of assemblies is large, in that case you are better off publishing assembly patterns, i.e. choreographies. A choreography is, IMHO, a packaged assembly.

The point to consider is that all actions are trans-actional in the state alignment sense. When an inter-action is invoked (1PC) the state of the initiator and target of the action need to be aligned based on success or failure, but this kind of state alignment is self-coordinated by the initiator (and leveraging reliable communications). The coupling that it induces is that if the two components reach a state where they cannot further interact, there is nothing you can do. And I think this is the point you are making, the only way this thing can work is by starting at the choreography level, rather than at the action level. I am still not convinced that this is the case, I still think that assemblies work in general though I can't prove it perfectly. My "proof" (which is not one) is that I typically assemble resource lifecycles and work activities. The interactions between resources themselves are mostly event driven, in other words, it does not matter in which state the target(s) resource end-up, they just have to be aware of the state in which the other resource is. Let me take an example:

I have ordered two XOs for the kid back in December. My daughter asked me the other day, how do you know they did not forget about our order? This is a very logical question for a 10 year old used to always get things within days. A delay of more than a week, is so uncommon that the only logical explanation is that they "forgot" (i.e. they reached the point of database havoc). So I drew this little diagram (ok, ok, I am such a geek) for her to explain how it worked and help her understand how they did not forget.

I created the PO WSDL and the Shipment WSDL.

This little example touches on several points that I think is relevant to this discussion. So first I believe that it is a good design practice to design self-standing lifecycles. I don't want to go to shipment to figure out the state of the order. This is why "shipped" and "delivered" appear in the order lifecycle. The rationale is that you don't want to couple the order lifecycle to the shipment state machine. It has to be able to work with different types of shipments as long as their state can be aligned.

Now, if you look at the WSDLs, you'll notice a lot of notifications. This is why I always thought of that EDA did not make any sense, it is not an independent style, just like Resources are part of SOA as well. Now, I can wire the notifications together or I could use a pub/sub coordinator, it does not matter.

Let me come back to what I said earlier: the interactions between resources themselves are mostly event driven, in other words, it does not matter in which state the target(s) resource end-up. Here this would be the case if you allow an order to be paid while the "reserve" operation fails in the shipment lifecycle. This is very common, think about hotel or airplane overbooking. This "chaotic" world is best described by Mark Masterson in this post. I think where Mark and I disagree (or no longer disagree) is that yes, the world is very chaotic (and creative) in terms of work performed to transition one resource to another, however the resource lifecycle is not chaotic otherwise, my daughter will never receive her XO and yes they will forget. This is the key to enable chaos to happen actually.

In the example, I decided to use one trans-action only "cancel order". So each lifecycle exhibit a cancel operation but this is not of course designed as an inter-action (you can cancel a shipment without cancelling the order). Note that in this example, you can't cancel the order until it is shipped. So, this means that the "cancel" operation has to invoke cancel order and cancel shipment simultaneously. I can implement this in two ways: a coordination of the two operations, or I can chain them (cancel order -> cancel shipment). In any case, the result will be the same "cancel" will succeed if both succeed.

Today mash-ups are fairly trivial precisely because people don't see the deal with the mash up complex inter-actions, so end-users are provided with simple scripting (graphical or not) capabilities that amount chaining invocations with a bit of logic in between. We are "back" to the DOS -keypressed- macros. The danger as Peter pointed out will come when people will want to do "real-world" stuff with these scripting engines. We will then return to "the lost semantic vortex". Vendors will hack their scripting engine to increase the level of sophistication without ever looking back at how assemblies and choreographies work. This danger is super real if the granularity of composition is below the resource lifecycle. This is why I am so vocal about this. We have circled for over 20 years, and we are getting ready to circle again.  Be assured that the "old-guard" is ready to do anything to keep their little vortex running.

Now, I don't want to underestimate how complex an assembly can be to write. We are just at the beginning of composition technologies...

Hope this helps.

02/01/08 :: [Other] Kinder Capitalism - II  [permalink]

Today, Exxon Mobil report their full year profit. This quarter was the largest profit in history, a puny $11.7 billion, and $40.6 billion for the year. Chevron also had its best year ever at $18.7 billion. I remember in 2006, the oil industry had already totaled $100 billion in profit.

I am a capitalist, so I have nothing against profit. Profit is good, this is how R&D gets financed, sorry was financed. You would think as good capitalist the oil industry would bank profits to research new sources of energy since we are support to run out of oil or run out of air within my children's lifetime.

To give you an idea, the international community came up with $15 billion budget for the fusion reactor (ITER), for the whole lifetime of the project. I earned my Ph.D. from the University of Marseilles which is very close to the ITER site, in beautiful Provence. One of my friend was working as a researcher there and I was privilege to visit the reactor the day after it was first ignited in early 90s (if I remember correctly).

So in 2005, 2006 and 2007 the oil industry have made enough profit to run 10 ITER programs. I would bet that not a dime (I might be wrong) went to ITER. I maybe a bit unfair in making this criticism, since some of the companies are doing research in high temperature superconductors. But, the fact remains that true capitalist sensing the end of their market would heavily invest in alternative energy sources. I would also think that if capitalists are not wise enough to invest in future technologies like so many did before them, you would think that the middle-eastern nation would be at the forefront of research, and if these two fail, you would think that the good governments of the free world would, in good conscience, tax energy profits to redirect this money to the new energy R&D effort?

No, that would be too kind, instead you read in the WSJ that the oil industry cut output to boost profit. You can also find out that the CEO of Exxon landed a 400 Million parachute in 2005 after sipping a refined $51 Million compensation.

I am wondering if Mr. Gates ever considered approaching the oil industry to solve the world poverty? I am wondering if he ever considered convincing them to invest a tiny bit into nuclear fusion? Maybe more on fuel cells?

01/29/08 :: [SOA] Spaghetti Oriented Architecture  [permalink]

You might think at this point that all I care is to pick a fight. This is really not the case. It is just that everyone that has something to sell in SOA is trying to kill something else: a technology, a product, a vendor... It seems that in our industry there is no growth possible anymore, you have to "reap and replace" to be successful.  This is the attitude that I am fighting. There is a lot of value and good things built by a lot of people. The key to a successful SOA is to really understand when and where to use a technology or a product.

Imagine if we could spend our time doing that instead of trying to confuse the customer base?

I am watching Jim Webber's presentation on Guerilla SOA. He is after large SOA efforts, ESBs and WSDL ("WSDL encourages RPC like interactions" and of course he is selling his own SizDL). Frankly I don't understand his point. Because first he tries to show that an ESB is stupid and then he says, well spaghetti oriented architecture is a fact of life and BTW, don't throw your ESB because you can use it as a service container on the "edges".

Again, I don't think this is rocket science, if we go back to my simple model of Loose Coupling, this model supports multiple topologies, here is a centralized one:

ESB is about centralizing some of the loose coupling code (as well as management and coordination). There is nothing wrong with this picture, it is topologically equivalent to the decentralized picture. IMHO, people don't get (bi-directional) SOA topologies. You would use an ESB if it helps you write the LC code and "connect" to heterogeneous back-end (internal) interfaces.

Five years ago WS-* did not have security, transaction, addressing and reliability, so the ESB provided messaging with this kind of QoS. The value of this aspect has gone down because of the completion of WS-* stack, but it does not mean that the ESB has lost value as a service container (with centralized management, and coordinators) or as a loose-coupling engine.

So the real question you need to ask is how do you plan writing the LC code and connecting to your internal interfaces. Sometimes, it makes no sense to use an ESB, sometimes it does. 

Now if you look at Microsoft’s Windows Communication Foundation, which is Microsoft’s Service Container, you realize that it suffers from an important architecture flaw. The flaw is not fatal, and WCF is a great container for certain types of service implementations but it does not offer any room to implement  LCc and LCp independently of your component implementation. The design goal of WCF was to enable designers to model service, message and data contracts from familiar and popular programming languages such as C#, but by doing so, Don strongly coupled the implementation to the external interface. Incidentally, this is why WCF is really about "code generation" and why people like Steve Vinoski were lead to believe at first glance that "this is WS-*". In WCF, you have no choice, the implementations of the consumer and provider are tied to the "service" interface.

In terms of loose coupling, WCF only offers the antiquated thinking that loose coupling is achieved by exposing multiple endpoints for a given implementation and configuring communication channels at deployment time. Not surprisingly, WCF does not offer any assembly mechanism other than creating a binary assembly (with two components). WCF was solely built with the assumption that the use of a common syntax, the use of an “Object Oriented” contract and the abstraction of middleware APIs was enough to ensure loose-coupling between consumers and providers. The WCF designers never thought about concepts such as WSDL as inter-action definition languages, BPEL as an inter-action programming language, assemblies as way to create units of work from inter-acting components...

On another note, I was happy to hear Jim talking about BPEL as simply a programming language. I picked this fight in 2002. I remember being the only one to speak of BPEL in these terms against people like Assaf, John Pike or Howard Smith. As usual, there was no room for something else than their views, we all know how it ended... Yet, I am a bit disappointed by Sanjiva, who has participated in the WS-BPEL working group, that still considers BPEL as a "workflow" language (as opposed to a composition language) and explains that WSO2 has developed a JavaScript based language to compose services. Again, there can be several programming languages that are capable of doing the exact same thing. IMHO, what Sanjiva is explaining is that sometimes BPEL is heavy weight and you might benefit from a lighter weight web services composition language. We certainly agree on that.  Is that a reason to try to displace BPEL, I am not sure.

01/26/08 :: [Hollywood] Kinder Capitalism  [permalink]

Last September I won a one year subscription to the Wall Street Journal. Since I ride the bus to work, I do have a bit of time to read it when I am not writing a post or finishing up an article. If you think you can understand anything about the world economy by watching TV, think again. I am not claiming I understand it a lot better with the WSJ, but boy do you get a laugh for your money. This last Saturday there was a single paragraph news that read:

US Oil refineries cut output to boost profit

That's what I call news.

As you may may have heard, the Economic Forum is in full swing in Davos. I must admit I am impressed by these guys. They have been gathering for the past 30 years and the world has never ceased to get more f... up (pardon my French, I could not find a more accurate word). It seems to not matter how much progress scientists make, how many diseases can be cured... every year, the World is growing more insecure (I am not talking about terrorism) and unstable (I am not talking about the middle east).

I mean these guys don't read the news, just this week, an Asteroid is coming within feet of the earth and a single guy was able to blew up $7.6 billion (who knew the French understood anything about finance). One billion dollar is the equivalent of spending $46,000 per day for 60 years (without counting interest). Most people don't even make $46,000 that in a year.

No, after 30 years, the happy few of Davos continue sprinkling the world of their wonderful wisdom. Let me take an example. Thursday, I saw Bill Gates's picture with a great smile and crowned with this title: "Bill Gates Issues Call for Kinder Capitalism". His talk at the Economic Forum was also echoed by the Seattle Times (please note that the Seattle times is not yet using APP, the resources are stored in a "vortex" based on the URL, I am sure they can't wait to upgrade to a workspace).

I don't want to comment on the article, there is really nothing to add, here are some quotes (warning: you might reach a point where you can't stop laughing):

Bill Gates [calls] for a revision of capitalism...[that he calls] creative capitalism that uses market forces to address poor-country needs that he feels are being ignored.

We have to find a way to make the aspects of capitalism that serve wealthier people server poorer people as well.

He has grown impatient with the shortcomings of capitalism (NDLR: Microsoft reported the largest income and revenue in its history this week)

In particular he said he is troubled that advanced in technology healthcare and education tend to help the rich and bypass the poor.

Three weeks ago, on a flight home from vacation in New Zealand, Mr. Gates took a yellow pad and listed ideas about why capitalism, ..., is failing much of the world.

Here is his plan [to win the Nobel Peace Prize]:

Companies should focus on building products and services for the poor

Mr. Gates sees a role for himself spurring companies into action.

Mr. Gates acknowledges that Microsoft was hardly a charity. "We weren't focused on the needs of the neediest"

Key to Mr. Gates's plan will be for businesses to dedicate their top people to poor issues.

There is more to Adam Smith, he added, "The Theory of Moral Sentiments" was written before "The Wealth of the Nations". It argues that humans gain pleasure from taking interest in the fortunes of others.

A core belief of Mr. Gates is that technology can erase problems that seem intractable...increases in wealth and technology would offset shortages in energy, food and global resources.

As a disclosure, I am an ultra-liberal (in the US sense, in France, it means exactly the opposite) and I strongly believe that "pure" capitalism is the best and only system that fulfill the needs of "we, the people". It is kind of an odd combination, but let me explain.

I am not an economist in any way, but I can add 2 and 2. For the past 20 years the productivity increases have been unprecedented in human history. Let's assume that it takes today 50% less time (as in people's time) to produce everything we need when compared to 20 years ago, where these 50% have gone? not in my pocket for sure, not in less work hours either.  Now consider that a lot of what we "need" is now produced in Asia at a 30-40% discount, where did this money go? Strangely enough not a single time Mr. Gates talks about productivity gains.

The bottom line is that I strongly believe that we have the man power (and the natural resources) to meet the needs of 6+ billion people. (I said the needs not the dreams). The solution of the problem is not at the bottom of the pyramid but at the top, the base of the pyramid is the top, if you know what I mean.

Has Mr. Gates ever considered the influence of:

• establishing a maximum wage (say 5 M per year) and a lifetime wealth cap (say 500 M). (I have no doubt that Mr. Gates is a good person, but imagine that $50 billion would fall in the hands of somebody a bit less "good").
• returning to a true market economy by taxing short-term profits by 95%.  (see below)
• capping profit margins (say to 20%, beyond that , this is called armed-robbery)
• capping interest rates to 4% for homes and 10% for consumer loans (do you think humans can spend 25% of their time to pay somebody else?)
• capping businesses wealth (non-productive assets) to one year of payroll or 10x R&D budget -which ever is the biggest (reward employment and research).

Let me explain the second point because this is the most important, I think it dwarfs all the others. Markets are the best way to regulate supply and demand, but true Markets only. A true market is a market where buyers can't be sellers. On eBay there are people that spend their time buying items that they think they can sell again on eBay for twice the price. On real-estate, equity or commodity markets, there are people that jump in and out riding any variations up or down. I mean how smart it is for letting people to buy oil, store it for 6 months so sell it at a profit, is that the market economy we have in mind? This is a major, major factor of instability while being an activity that does not serve the need of the people, specially when it comes to energy or food markets. Now there are some markets where there are no choice (e.g. real-estate markets, stock market...), you have to be a buyer at some point and a seller at a later time. Cutting down short terms profits to the lowest levels possible will be the biggest factor in emancipating humanity to meet its needs and consume less resources in the process.

Now, you can debate how this "extra-cash" (sorry I mean activity) should be used and shared between increased wages and government projects (education, health, retirement ...). Obviously there is room for debate, I like a good balance. Please note that security and justice budgets should go way down with more balance.  BTW, if there is a surplus of "time", why don't you give it back to "we, the people". Mothers and fathers can use a bit of it. Others might want to get a better education or contribute to the "fortunes of others".

At the end of the day, money represents nothing other than people's activity. If you consider $50 billion dollars, it means that Mr. Gates can control the lives (for 40 years) of 27,375 workers earning on average $46,000 per year. It actually looks very puny. Now assuming that these people on average can save 5% over their lifetime, $50 billion dollars is really the lifetime savings of 547,500 average Americans or about 0.5% of the working population. If you factor interests, these numbers are actually a bit larger. When Michael Eisner was CEO of Disney, I learned once that he was making 1 M per working day or roughly 250 M a year. It was hard to explain my 3 year old that I thought Mr. Eisner was robbing parents and I would not buy any more Disney product, but I did it. Do we think as a society that it is fair that someone can "swap" "time" with others at these levels? To give you a point of reference, my mum in all her life made about $750k in today's dollars.

These 5 little "tweaks" in the economy would simply return the activity of "we, the people" to meet the needs of "we, the people" while still offering a comfortable lifestyle to "they, the people" that can't live without their yacht, mansion(s) and Jags. In the 21st century, technology and capitalism have made it possible to give a decent and fulfilling life to everybody. In particular, the Web has given us an unprecedented opportunity to pin point the needs of others and swap our time. The question is will the Davos Jet Set let us do it? What I know for sure is that we, the people, don't need charity, we just need our time back, capitalism works just fine.

01/25/08 :: [SOA] Inter-action DLs and PLs[permalink]

Proceed to the next section if you don't want to read my quick update on the REST discussions (my usual rant on REST).

Tim did not provide any explanation to his post on WSDL. Not surprising but sad.

Bill Burke asked me to reconsider my comment on the "super-fluid" logic that Steve and Joe Gregorio applied to conclude that WSDL is bad. I have re-read their statements and unless I am mistaken (sounds a lot like the Obama / Clinton rhetoric) I have described their train of thought appropriately: (true) people do code generation with WSDL, (true) code generation is bad therefore WSDL is bad.

Fortunately there are great people in the REST community like Stu Charlton, Subbu Allamaraju, John Heintz or Teo Hui Ming (and I am sure many more) who genuinely are trying to create an understanding of how REST really works and make progress in the meantime. They are the crowd I would like to belong to. They are the league I wish I could play in. And I mean it. These people are really smart. They have an extensive knowledge and the right attitude. I am certain they, collectively, can turn REST in something even greater.

Here is Teo's response to my question on how to create an approval step in APP. Teo also provided a pointer to a great discussion based on yet another great series of posts on REST: Business Functions | the REST dialogs from Duncan Cragg. This series of post is a REAL attempt to explain how REST works. This is the best I have seen so far.

My favorite quote:

a resource can do any 'real functions' just by watching resource changes via GET or receiving resource data via POST on its URI and then mechanically transforming itself according to its internal rules - as defined by standard, convention or agreement.

Data operations are enough to enable much more than just data operations, as long as you have the internal transformation rules in place that animate the data in the face of current state.

so what's the point of using only data operations? That sounds a lot like invoking an action if you ask me except that your action signature is expressed as a combination of data schema and rules of invocations described somewhere in a document (otherwise you would not know what changing the value in a data field means). Semantically, what is the difference? Don't you think some smart-ass is going to create a framework that does code generation for that?

You will also appreciate the implementation of REST's event mechanism "by watching resource changes via a GET". I start to wonder who is the rebel and who is the evil empire.  Wouldn't there be an evil empire which aims to keep us in the maelstrom of poor & sloppy application semantics? If there was actually a programming model that would make the development of information system easy, wouldn't this evil empire loose all its power? That being said, I like Duncan's posts because he really talks about REST.

Sorry, just can't stop this discussion. Back to the topic of this post.

Inter-action Definition and Programming Languages

Mike Edwards wrote an introduction article on SCA which was published on InfoQ. I felt that this article was illustrating my point very well about inter-action definition languages and inter-action programming languages.

OO's interface definition mechanism (and pretty much all IDLs) are uni-directional. So how do you describe inter-actions with an OO language? well you use two interfaces as Mike explains. Here is his Purchase Order Request/Response definition:

public interface OrderService {
    public void placeOrder( OrderRequest oRequest );  
} 

public interface OrderCallback {
    public void placeOrderResponse( OrderResponse oResponse );
}

And here is the corresponding "port type" definition, yeap, you have to use both interfaces in the definition of your port type (service in SCA -just to confuse anyone):

<service name="OrderService">
         <interface.java interface="OrderService"
                                callbackinterface="OrderCallback"/>           
        <binding.ws/>
</service>

And Mike gives us the skeleton of the service implementation:

public void placeOrder( OrderRequest oRequest ) {
        // …do the work to process the order…
        // …which may take some time…

        // when ready to respond…

        OrderResponse theResponse = new OrderResponse();

        callbackReference.placeOrderResponse( theResponse );
    }

This implementation looks trivial, but in reality it is not. As Mike points out in his article we live in an asynchronous world. When you click the purchase button on your shopping cart you don't have a sub-second delivery, nobody is at your door ringing with the goods you just ordered. Basically, this Java skeleton is flawed. The order response will not be in general in the thread that processes the order request.

I feel that I am saying something really trivial, but in the light of the discussions with Steve Vinoski, the comments from Tim Bray on WSDL and the fact that Nick does not want to talk about the programming model as a factor in reusability, I feel that I have to say this:

• WSDL is an inter-action definition language. It is not great, ok, it is broken (outbound bindings but SCA has fixed that), ok. Give me something better and I'll use it, but give me an inter-action definition language. No more callback insanity.
• BPEL is an inter-action programming language. It is not great, ok. Give me something better and I'll use it.

The programming model that "some" will never let go is flawed, terribly flawed, tragically flawed. The very reason why "re-use" is not possible is simply because "things" that can be re-used "inter-act". They are not nicely layered in tiers that invoke one another but as peers that invoke each other.

The Client/Server model is deeply and totally artificial.  SCA is on a mission to fix that deeply and totally. It has still some progress to make, but it is on the right path. In particular, it enables the definition of inter-action interfaces from languages like Java and it allows you to use an Orchestration language such as BPEL from any language. This means that these programming languages don't need to be retrofitted to deal with either. This is a major step forward in the realm of computer science.

So, I am sorry, Steve, Tim and Nick, you don't think you see the elephant in the room. You are holding us back, way back. The future can be seen, if you decide to look...

01/20/08 :: [SOA] WSDL sucks deeply and totally [permalink]

This is how Tim Bray still speaks these days. I asked for some clarifications or a link. Let's see what he comes back with.

He explains that he is not yet sure that he needs a Web Service Definition Language and comments:

Then after reading Dare’s piece, it dawned on me that I just spent the last three years of my life helping develop a Web Service Specification language, namely the Atom Publishing Protocol’s Service Document

Since Steve complains about "There’s simply no room in technical discussions for the negativity and hate that causes situations like that". I decided to play super positive today, I mean the Pats are 18-0, ready to win the Superbowl against the frozen Giants, how could you be negative in any ways. Steve also points to Joe's critic of WADL. (These guys are so far behind in their understanding of WS-* that it's not even funny anymore to discuss anything with them). Their motto is that WSDL is bad because you can do code generation (if you want) and code generation is bad, therefore WSDL is bad. Wow, how logical is this proposition? This reasoning is so profound that we should lobby to replace Harvard's entrance gate motto ("Enter, to grow in wisdom") with it. The world's elite's got to reflect on this every day. We should also make sure that any presidential candidate has been initiated to this new powerful form of reasoning. The future of the free world depends on it.

Steve comforts Tim's proposition by saying:

Similarly, an AtomPub service document is nothing like IDL or WSDL either...those documents essentially inform you of service URIs and media types, but they don’t define methods or operations. They don’t have to, because of the HTTP uniform interface.

I decided that contrary to by dearest habits, I would "boringly proceed with useful logical discussions". So, here is what Tim and Steve are talking about. I created my understanding of APP as a UML diagram. This is the latest addition to the REST family of specifications and possibly the RESTian crown jewel (click to zoom in).

Wow, I am impressed, you mean that's supposed to be the WSDL of REST. Wow. How long did it take you do write this spec? You said, 3 years just for the Service Document element. Wow, I mean, I can't take my brain off this abstraction, I am just blown away. Wow, just with four little verbs you have been able to create a spec that describes how to create member resources (entries) in a collection and how to edit them. And wow, the "workspace" concept, I mean wow, this is brilliant, that's much better than parking resources behind one service (or more than one service). Now they are inside a workspace. Wow, I mean, I am sure the resources appreciate the difference.

Wait, actually, the more I observe this wonderful abstraction the more questions I have. So now, let's say I have a corporate blog and I want the employees to be able to post blog entries. But since it is a corporate blog, I kind of want to monitor what's going on, so I have a simple state machine for an entry: entered, approved, published. How do I do that in APP? must be a PUT on the resource right?  

I am also wondering how  CORBAsian APP is? At a high level this is an object model with methods.

How does this design approach scales? I mean, if it took you 3 years to come up with an interaction model for feeds that can't even really support an approval step, how long do you think it is going to take me to do an insurance claim or policy? I don't have several years to come up with this kind of thing.

Ok, enough non-sense, Tim, Steve, when you'll have something of value to tell us beyond REST itself, let us know.

The UML file is available on WSPER.

|

01/20/08 :: [SOA] Article: Why Interaction is more powerful than algorithm [permalink]

The best part of blogging and having discussion with people of different opinions is that you discover some pieces of knowledge you would have otherwise never came across. 

Francois Leygues pointed to me this article written by Peter Wegner and published in 1997. Every line of this article is pure delectation (not just in the Epicurean sense).

Some quotes from the article:

The growing pains of software technology are due to the fact that programming in the large is inherently interactive and cannot be expressed by or reduced to programming in the small.

Artificial intelligence has undergone a paradigm shift from logic-based to interactive (agent-oriented) models paralleling that in software engineering. Interactive models provide a common framework for agent-oriented AI, software engineering, and system architecture.

Though object-based programming has become a dominant practical technology, its conceptual framework and theoretical foundations are still unsatisfactory; it is fashionable to say that everyone talks about it but no one knows what it is. “Knowing what it is” has proved elusive because of the implicit assumption that explanations must specify “what it is” in terms of algorithms. Accepting irreducibility as a fact of life has a liberating effect; “what it is” is more naturally defined in terms of interactive models.

The inability to compute more than the computable functions by adding new primitives proved so frustrating that this limitation of Turing machines was also called the “Turing tarpit.” Interactive computing lets us escape from the gooey confines of the Turing tarpit.

Turing machines cannot, however, accept external input while they compute; they shut out the external world and are therefore unable to model the passage of external time.

Though the thesis is valid in the narrow sense that Turing machines express the behavior of algorithms, the broader assertion that algorithms capture the intuitive notion of what computers compute is invalid.

Turing machines extended by addition of input and output actions that support dynamic interaction with an external environment are called “interaction machines.” Though interaction machines are a simple and obvious extension of Turing machines, this small change increases expressiveness so it becomes too rich for nice mathematical models.

Interaction machines can model objects, software engineering applications, robots, intelligent agents, distributed systems, and networks, like the Internet and the World-Wide Web.

Whereas interaction histories express the external unfolding of events in time, instruction-execution histories express an ordering of inner events of an algorithm without any relation to the actual passage of time. Algorithmic time is intentionally measured by number of instructions execution cycles.

Interaction, parallelism, and distribution are conceptually distinct concepts. Parallel algorithms, studied in many textbooks and university courses, are necessarily noninteractive. Distributed algorithms, in textbooks on distributed computing, are likewise noninteractive. The insight that interaction rather than parallelism or distribution is the key element in providing greater behavioral richness is nontrivial, requiring a fundamental reappraisal of the roles of parallelism and distribution in complex systems (Steve any comments?).

Interfaces are a primitive building block of interactive systems, playing the role of primitive instructions. Interactive programmers compose (plug together) interfaces, just as algorithmic programmers compose instructions.

 

|

01/20/08 :: [SOA] Understanding SOA [permalink]

It seems to me that somewhere in all these discussions we have lost the understanding of SOA. You read the different SOA columnists every week and you don't get a sense of people having a clear understanding about SOA, everything and anything seems to be said about SOA, good or bad, for or against it, SOA is this or that... Things like EDA or ROA have simply added to the confusion. 

Ok, I acknowledge that the SOA technology stack is not the cleanest, and I don't want to go there to explain my understanding of SOA. I don't think looking at the OASIS SOA Reference Model is going to help you either because this work was done from a "service" perspective, not a a Service Oriented Architecture perspective. The SOA RM is rather a Service RM (at best). It is a collection of facts about services coming from different specifications rather than a deep understanding of what is a Service Oriented Architecture is and where it may apply. It is an a posteriori justification of some spec work.

So, what's the problem we are trying to solve?

Up until the emergence of the Web technologies, there was no capabilities to construct solutions from components running across wide area network boundaries, often across company boundaries (the WAN was not really there either). Let's take an example. In 1999, I designed and built for NEC System Labs a procurement solution that would let you browse catalogs running at different suppliers (off premise) and drag an drop items in a shopping cart running on your own servers (on premise). I used IE's new drag and drop capabilities, the wonders of HTML in terms of presentation aggregation and some XML product descriptions. The procurement PO (after being accepted) was then processed and dispatched to all individual suppliers using a standard called OBI (Open Buying on the Internet). These were the days and small standardization groups were forming such as the ECO framework and small startups such as Veo Systems. 

The bottom line is that without these technologies, procurement solutions required complex catalog aggregations and constant updates to run the who stack and product catalog on premise.

In another context, in 2001, Amazon realized that it could not scale with a monolithic application model. Different pieces of their "application" had widely different scalability, availability and security requirements, maintenance cycles... So what did they do? they broke it up in lots of pieces assembled again at the presentation layer.

This is all great, but in the case of my procurement solution (and probably in most cases for Amazon -though this is pure supposition) there was no server-to-server communication. All interactions were mediated by the user drag-and-drop action in the browser.

At the end of the day, SOA is an architecture where elements of the business logic are factored in autonomous software agents which can interact. The picture below represent a basic reference model for service oriented solutions.

The solution is assembled as a series of units of work (activities) from a series of software agents of three basic types:

• human tasks
• services
• coordinators

A coordinator is a software agents that supports the interactions of other software agents (a directory, a transaction coordinator, a pub/sub engine, an activity lifecycle service, various security services, a choreography context service... are all coordinators).

Services can be Resource Lifecycle services,, decision services, master data services...

Typically services, human tasks, and sometimes coordinators run in a container. WCF is a service container, and ESB is another one. A task engine is a human task container. It manages task lists, and tasks lifecycles. From a service perspective, a human task looks like any other service.

It is perfectly ok to build your own service container and even have more than one container in your SOA (not too many though because they share common infrastructure and operations technical services). Different service containers offer different capabilities. For instance WCF originally did not offer any back-end integration. It made WCF good for writing services in .Net languages but not really well suited to front-end legacy applications. It is actually fairly rare to think you will re-implement your services entirely. If your legacy application supports it (in terms of scalability, availability and security) you may want to invoke application components as part of your service implementation. Legacy applications become "systems of record" and manage the content of "resources" such as Purchase Orders, Invoices... Resource representations are exchanged during service and human tasks interactions as work is performed to advance their state and populate their content.

I think today, Amazon is one of the best examples of Service Oriented Architecture on the planet from front to back. I don't think the picture I represented above would be news to anybody there.

Now I had promised Subbu a long time ago to explain how "choreography" fit in the picture. More recently I had discussions with Francois Leygues, a French Architect, who is building RESTful solutions. I think our discussion has been very constructive and we ended up talking about choreography and assemblies. Stu Charlton also suggested to use choreographies to describe the interactions of the resources. 

I worked on the concept of "choreography" for 6 years. I worked with a bunch of great people: Dale Moberg, Monica Martin, John Yunker (from Amazon), Bob Haugen, Sally St-Ammand... and many others (sorry I don't recall all the names). There were a fee dark characters too, they ended up giving up because of our passion. They all quitted, one after the other, sometimes after we uncovered their little scheme (yes, this is what happens in standards group, so don't be surprised at what comes out).

I told Francois that even though I worked so much on Choreography, I did not think this was an appropriate technology to model service interactions in the enterprise. "Choreography" is a concept that makes sense for B2B.

The reason is quite simple. In B2B when you have hundreds or thousands of business partners you need to tell them how you expect the interaction to happen. They can use it at design time, and also at run time to validate that a message is not going to violate the expected sequence of messages. Imagine if dozens of business partners start sending you out-of-sequence or erroneous messages. Since a lot of these message exchanges involve a "business transaction" with transfer of value, they are not trivial to compensate in an ad hoc fashion.

In the enterprise when a service is reused in different solutions, the choreography is going to change (slightly) because the solutions will be different, assembling different services. Creating a choreography for a single unit of work is lots of work. You are much better off creating an assembly. A choreography is actually quite a strong coupling too, at least it is going to be of no help to diminish the coupling between components. It works well in B2B because you want to lower the cost of bringing new partners in, and choreography are the best way to do that. In the enterprise SCA gives you a very powerful assembly mechanism that allows a single service to participate in different solutions (even with different configuration parameters). IMHO, SCA is bound to take off over the next couple of years as the keystone of SOA. It is unfortunate that one more time, the politics behind vendors and some individuals are preventing that to happen faster -we all loose because of a handful of egotistic people- but it will happen, you can trust me, like I think you have trusted me for the last 7 years when I talked about BPEL as a programming language or the architecture of business process engines as being decentralized, or yet again when I talked about an emerging service oriented, process centric, model driven programming model.

For the record, in the OASIS bBP group we have nothing to sell, only our passion and knowledge to share. You'll never catch any of us making recommendations that we don't believe in or that we have not verified. This is the culture that we have successfully grown into our group, and I have been really proud to be part of this group. All I ever learned on SOA and B2B, I learned it in that group.

Voila, I don't think SOA is that complicated, there are tons of solutions which value can be augmented by leveraging off premise software agents and there are tons of solutions that can offer some value to other solutions should the technology that allow them to do so exist (and they do exist). This is what SOA is about, it is not about REST, WS-*, SCA or BPEL. There are many ways that lead to Rome, I have to pick one, I can show you which one I pick, I can explain why I picked this one, but this is your choice and your choice only. I don't want to sway you behind be, I might even follow you at some point!

SOA is exciting, it is the way forward, because reuse makes sense and contrary to what people tell you reuse works provided you know how to factor what needs to be reused and leverage the right composition technologies. SOA is also exciting because for the first time we have a programming model aligned with business processes. The next ten