Idiots!

Someone please whack these idiots with a clue stick: Industry analysts attack plans to increase prices. - Feb. 28, 2005. Raise the prices? How about lower the prices?! It isn't like they have any production costs; send the bits to Apple or Napster and cash the checks.

But just as music lovers are being coaxed into using legitimate download services, price jumps could prod them back to piracy, industry analysts said.

"I think whoever came up with this idea understands the online music industry about as well as a cow understands algebra," said Phil Leigh, senior analyst for Inside Digital Media.

"If the labels really want to fight piracy, it defies logic to increase prices and create more of a disincentive for the consumer to use legitimate providers. If they want to encourage the public to use legitimate online pricing, raising prices is about the last thing they should think of doing."

Duh!

Cage match!

Sean suggests that our problem is that we don't have a common understanding of what the meaning of 'is' is:

One thing I know for sure. Integration folk (including me) are using words in a certain way, to mean certain things. We *think* the people we are talking with are using the same words in the same way. Words like "message", "asynchronous", "semantics", "API", "transfer", "resource", "service", "interface"... the list goes on. We don't have shared semantics for any of these terms - including the word "semantics" :-(

It is hardly surprising that we do not seem to be making progress. In an ideal world I would put the following people into a room full of white boards and feed them coffee. Their task - sort out the terminology guys!

What? No pizza and beer?

On a more serious note; in a sense, he's quite right. Don't believe me? Check out this thread from days gone by.

20 Questions

Via Stefan: 20 Questions Fascinating. It missed answering correctly in 20, but got the answer in 24. Here's what it had to say about that (my responses in italics):

You were thinking of a terrier.
Is it black? You said Partly, I say No. Well, as puppies they are black and brown.
Is it a wild animal? You said Sometimes, I say No. That depends on your definition of "wild animal" as being an animal in the wild or sometimes acts wild. I say, Sometimes they act wild.
Is it colorful? You said Yes, I say Doubtful. Again, depends on what context the adjective "colorful" applies. From WordNet: 2: striking in variety and interest; "a colorful period of history"; "a colorful character";...
Is it useful? You said Rarely, I say Yes. I say, what is this thing smoking!?

Still, pretty impressive.

Who's ill-informed?

Scientists feel stifled by Bush administration (emphasis mine):

Asked for comment, White House spokesman Ken Lisaius said, "The president makes policy decisions based on what the best policies for the country are, not politics. People who suggest otherwise are ill-informed."

Kurt Gottfried of Cornell University and the Union of Concerned Scientists said a survey of scientists in the U.S. Fish and Wildlife Service found that about 42 percent said they felt pressured to not report publicly any findings that do not agree with Bush policies on endangered species.

He said almost a third of the Fish and Wildlife researchers said they were even pressured not to express within the agency any views in conflict with the Bush policies.

"This administration has distanced itself from scientific information," said Gottfried. He said this is part of a larger effort to let politics dominate pure science.

He said scientists in the Environmental Protection Agency have been pressured to change their research to keep it consistent with the Bush political position on environmental issues.

Kafka would be proud

Read today's WaPo editorial: Injustice, in Secret

ATTORNEYS FOR the Justice Department appeared before a federal judge in Washington this month and asked him to dismiss a lawsuit over the detention of a U.S. citizen, basing their request not merely on secret evidence but also on secret legal arguments. The government contends that the legal theory by which it would defend its behavior should be immune from debate in court. This position is alien to the history and premise of Anglo-American jurisprudence, which assumes that opposing lawyers will challenge one another's arguments.

In short: we're not going to tell you why the case has been dismissed because, well, its a secret.

Hitch

Cheryl and I just got back from seeing Hitch. We both laughed 'til our stomachs hurt. I may have to see it again to catch the bits I missed while laughing, (and while the two old ladies behind us were talking).

Definitely worth the price of admission.

Bring out your de-ad!

Via Mark, who was spotted recently dancing around a fire like Rumplestiltskin wringing his hands gleefully while chanting:

"Today I bake, to-morrow brew,
the next I'll wake the vendor's child
Ha! glad am I that no one knew
that RESTafarian I am styled."

comes a link to a post on the Manageability blog proclaiming that SOAP is comatose, but not officially dead! which concludes:

So here I'm going to reiterate again that SOAP is brain dead. I sincerely hope not to write similar piece years from now when the conclusion would be entirely obvious.

In addition to citing some recent quotes from the blogosphere, which purport to support this conclusion, the writer (whom I don't know) proceeds to (inaccurately) trash SOAP ("but, I'm not dead yet!") as being somehow fundamentally flawed with regards to interoperability:

However, let's go beyond this name-calling and look at the crux of the matter. The primary rationale behind Web Services is to support interoperability. So, let's examine SOAP today to discover if it is superior to REST in supporting the primary requirement.

As alleged evidence to support this claim, some interoperability guidance from a presentation by Simon Guest of Microsoft is cited:

• Avoid returning empty Arrays.
• Services that share datatypes should be handled with care.
  
• Do not test for Null, rather check if the a returned object is Nil instead.
  
• Avoid null Dates. In .NET dates are a value type, in Java they are reference types
  
• Don't make exact Date comparisons.
  
• Always use a Trace tool.
  
• Learn how to change the URL and ports.
  
• Unit test.
  
• Use doc/literal.
  
• Always start from the XML Schema Definition.

This is followed by an analysis of this guidance, most of which I agree with, but none of which is inherent exclusively to SOAP or Web services. The analysis concludes (emphasis mine):

Of course, the last 2 tips are the most revealing of all. If everything is sent over the wire as a XML document that is described by an XSD then it all boils down to how easy you can work with these documents. That is working with XML api's like DOM and XPath.

Yeah, riiiight; easy... NOT! At least not for your average code slinger faced with dealing with a complex schema.

As recent blogosphere entrant, and SAX API creator, David Megginson readily admits:

I have to admit that Dare is absolutely right – building complex applications that use SAX and DOM is very difficult and usually results in messy, hard-to-maintain code.

The problem is that I have not yet been able to find an XML API that doesn’t, um, suck. So-called simplified APIs like StAX or JDOM always look easier with the simple examples used in introductions and tutorials, but as soon as you try to use them in a real-world application, their relatively minor advantages disappear in the noise of trying to deal with the complexity of XML structure.

The simple truth is that none of the alleged flaws of SOAP cited in the Manageability post have anything at all to do with SOAP. Arguments which try to assert that REST and SOAP are somehow mutually exclusive, and that POX (I love that acronym!) over HTTP is soooo much simpler than SOAP are nothing more than simplistic, uninformed, and inane drivel.

Even Mark acknowledges this, and for once, I have to agree with him:

Again, it's a shame SOAP is getting caught up in this backlash, since it's not the spec that's the problem, it's how people are (mis)using it.

The interoperability issues being incorrectly attributed to SOAP are in fact inherent to how the XML is being processed. The interoperability advice that Simon offers applies equally to POX over HTTP using RESTful style interactions (whenever the user agent is not a browser) as it does for SOAP.

The real crux of the issue is the inadequacy of the various programming models used for processing XML, whether it be POX or SOAP, and the tooling which developers use to "simplify" the task of cutting code. They are either considered "too complicated for average developers", or they are too simplistic (or constrained) in their underlying assumptions (most XML->domain object mapping).

Whither delivery assurance?

I've posted an entry on my corporate blog discussing the topic of delivery assurances (or seeming lack thereof) in the recently republished WS-RM.

Don't Panic!

I have to say that I am equally disappointed as Geoff with the trailer. Yes, of course I'll go see it (not without my towel, of course!), but the trailer is not what I had been expecting.

PropagandaGate

Frank Rich:

It is a brilliant strategy. When the Bush administration isn't using taxpayers' money to buy its own fake news, it does everything it can to shut out and pillory real reporters who might tell Americans what is happening in what is, at least in theory, their own government.

Read the whole article.

RDDL me this, Batman!

What do all these links have in common?

Could it be this?

Woo hoo!

I am very pleased to announce that IBM, Microsoft, BEA and Tibco have just republished the WS-Reliable Messaging specification (WS-RM) under Royalty Free terms. There are now two separate specs, one for the core protocol elements and one for the related policy assertion (WS-RM Policy Assertion).

I've published an article on IBM's developerWorks site that explains the changes made since the spec was last published in March 2004.

Also, Doug Davis has published an article on WS-RM and WS-Reliability which I highly recommend reading.

2+2=5, World is flat, film at 11

Michael Kinsey writes in today's WaPo -- The Meathead Proposition:

Bush might as well be proposing legislation that two plus two is five. And if that happened, there would be no shortage of Republicans prepared to endorse this view, experts on arithmetic to declare that it is a very difficult question, research to indicate that the answer may lie anywhere between 2.3 and 7.09, moderate Washington sages to urge caution, media to report both sides of the question, and media critics to accuse the media of a subtle bias in favor of two plus two is four.

ROFL! How true.

"This is why I don't use the computer!"

My wife, a card-carrying Luddite when it comes to anything related to the PC, has (finally) started to use it with a little more regularity (like, once a week, tops:-). She strolled into our livingroom this morning and sat down in front of our PC to order something online for some friends who just had a baby.

She logged in to her Windoze XP account and clicked on the exploder icon (despite the fact that I installed Firefox long ago). She was immediately assaulted with a seemingly never ending stream of popups both from IE, and from the AIM client that automagically launched itself (and logged in as my daughter?!). Her reaction: "See, this is why I don't use the computer!".

After I stopped laughing, I asked her why she wasn't using Firefox. She responded that it wasn't on the screen for her to choose. (I think that Windoze helpfully removed it when she clicked "Yes" on the friendly reminder that informed her that there were "unused icons on her desktop, would she like to clean them up?")

So, we (re)added Firefox to her desktop, removed IE from her desktop icons (which I should have done long ago), dismissed all of the popups, exited from AIM and IE, and launched Firefox. "Oh, this is much better!", she exclaimed. Another convert! (Maybe she'll remember next week when she logs on next:-)

Now, all I need to do is convince my daughter to start using Trillian instead of AIM for all her IM needs so that we will no longer be assaulted with AIM's inane popup ads everytime we log in to our respective accounts (there doesn't appear to be a way to get it to launch only for a given XP user account).

The Amazing Disappearing Trust Fund

Dan Froomkin writes in his article The Amazing Disappearing Trust Fund (washingtonpost.com):

Shouldn't Bush therefore call for an immediate cut in payroll taxes, effective immediately?

If Social Security is really pay-as-you-go, and any excess payroll tax revenue just goes into the general fund, why are American workers paying more than it costs to run the program? Why should they overpay Social Security payroll taxes for one more minute -- if in fact it doesn't do the Social Security system any good at all?

The latest numbers I've seen show that American workers this year will pay about $70 billion more in payroll taxes than will get paid out in benefits and administrative expenses. And it's a brutal tax. It's not the least bit progressive. In fact, because it's flat -- and capped at about $90,000 of annual income -- it's vastly tougher on the working poor than it is, say, on millionaires. Not to mention billionaires.

The only reason it's been socially acceptable to keep such a high, regressive tax on the books is that the system it was ostensibly keeping alive for the future returns money in a highly progressive way.

But if -- as of now -- that's not really the case, how can anyone defend it? A capped payroll tax is a pretty harsh way to raise $70 billion a year for the general fund.

Good question.

An even better question is: why hasn't the rest of the MSM picked up on this?

But the question I want an answer to is: if the Social Security system is in crisis, as our Dear Leader would have us believe, then why should we buy into his proposed "solution" of "personal accounts" (which are in fact just a loan from good ol' Uncle Sam) when that only makes the crisis conditions worse by increasing the deficit by trillions over and above the future value of the cost of redeeming the trust fund securities?

No, what the MSM should be asking the president either directly, or indirectly through his spokes model Scottie McC, is: so, does the administration plan on defaulting on the U.S. Treasury notes issued to the Social Security Trust Fund? Were the Social Security Amendments signed into law in 1983 merely a scam (disguised as "saving" Social Security for future generations) to convince working class Americans to pay a highly regressive tax rate to fund the Federal Government's crack addiction to deficit spending?

XML first, focus on the contract

Yet another blogosphere permathread started by Tim and Clemens, with great input from Steve. Stefan chimes in responding to Dare's comments on the topic. I have to say I totally agree with Tim and Stefan, but I think Steve nails it:

... starting from the implementation language and generating your contracts from it is just plain wrong, wrong, wrong, at least for systems of any appreciable magnitude, reach, or longevity.

...

When you start with the code rather than the contract, you are almost certainly going to slip up and allow style or notions or idioms particular to that programming language into your service contract. You might not notice it, or you might notice it but not care. However, the guy on the other side trying to consume your service from a different implementation language for which your style or notions or idioms don't work so well will care.

Exactly right.

To Dare's point:

It is actually much easier to make an uninteroperable Web service if one starts with the service contract instead of with object oriented code. The reason for this is quite simple and one I've harped on several times in the past; the impedance mismatch between XSD and objects is quite significant. There are several constructs in W3C XML Schema which simply have no counterpart in traditional object oriented languages which cause current XML Web service toolkits to barf when consuming them.

Patient: "It hurts when I try to map XSD to domain objects".
Doctor: "Don't do that".

Interestingly, the sentiment expressed in Dare's post is roughly that which motivated WS-I to charter the XML Schema Planning WG. Some wanted WS-I to profile (subset) XSD to the set of constructs that can be readily, and interoperably consumed by available tooling (what I would term the LCD approach). Others (like me) wanted to preserve the sentiment behind R2800 in Basic Profile 1.x.

There are a number of issues at play to be sure, as I have written about previously. Available tooling, in many cases, does an inadequate job of databinding for some schema constructs. JAX-RPC1.1, for instance, permits optional support for certain schema constructs; thus what might work in one vendor's offering might not do so portably in another's.

There are also issues with regards to consistency between various schema development tooling as to what is, and what is not, valid schema and as to what instances are, or are not, valid with regards to a given schema definition.

While WS-I has not yet formally decided upon a specific course of action, there will certainly be a decision made in the very near future.

Ultimately, I think the tension is between those who think of XML and Web services in terms of domain objects in their favorite programming language (XML? What XML?), and those who embrace the XML (Objects? What objects? This is a document). I suspect the truth lies somewhere between these two extremes.

Marc on the JAX-RPC 2.0 Early Draft 2

Marc outlines some of the new stuff in JAX-RPC 2.0 Early Draft 2.

Closet MESTian

Tim wonders if he is just a closet MESTian. ROTFL!

Fuzzy Math

This NYT Editorial nails it.

Whenever the Bush administration wants to sell a costly new program, look carefully before you accept any numbers it puts out. The math isn't just fuzzy, as the current euphemism would have it - it is often downright misleading, and deliberately so.

...

The deficit-addicted government that he [Bush] has created doesn't have enough money coming in to pay for the programs that the public wants and deserves, not to mention the nation's defense.

Trust? There is no trust

Regarding what the President said today (emphasis mine):

Some in our country think that Social Security is a trust fund -- in other words, there's a pile of money being accumulated. That's just simply not true. The money -- payroll taxes going into the Social Security are spent. They're spent on benefits and they're spent on government programs. There is no trust. We're on the ultimate pay-as-you-go system -- what goes in comes out. And so, starting in 2018, what's going in -- what's coming out is greater than what's going in. It says we've got a problem. And we'd better start dealing with it now. The longer we wait, the harder it is to fix the problem.

Josh has a point:

Second, what the president said today almost certainly violates his oath of office in which he swears to "preserve, protect, and defend the Constitution of the United States."

That would be the Constitution which reads (Am.XIV, Section 4): "The validity of the public debt of the United States, authorized by law, including debts incurred for payment of pensions and bounties for services in suppressing insurrection or rebellion, shall not be questioned."

According to the President, it's all been a shell game and we the people are the losers.

While it is true that there's no big pile of money just waiting for that day in 2018, or 2020, or 2028, or whenever we hit the crossover point at which the receipts are out-weighed by the payments for Social Security benefits, the Social Security Trust Fund is real, and it does have a pile of U.S. Treasury Notes and that pile grows each year until the supposed crossover point.

So, the President had better watch what he's saying, because the parents holding EE bonds for their kid's college education, the Japanese, and the Chinese, and the Europeans who have been holding U.S. Treasury bonds all these years firm in the belief that the U.S. will redeem them may just be listening. We wouldn't want to leave them with the wrong impression, would we?

Any questions?

Congresswoman Louise M. Slaughter - WH Briefing Room Scandal

Maps!

Now this is just too cool!

I agree with Sam's observation, Kudos to Google. Bah bye mapquest.

Update: Ian, this is my commute:-p Mwahahahahaha!

The big picture

Amen!

Dynasty

Patriots win 3rd Super Bowl in 4 years. Incredible! Three wins in four years. One of the best Super Bowl games I can recall in terms of the level of competition. Even the half-time show was pretty decent, for a change. Our favorite ads were the CareerBuilder.com ads with the monkeys.

Go Pats!

KISS

Stefan:

Sometimes the simple stuff just rocks.

Indeed!

Detailed EPR metadata proposal

Steve blogs about his Detailed EPR metadata proposal from IBM, IONA, Oracle, SAP, and Sun.

I believe in general, the proposal is a good one. However, I do have one serious reservation.

Why does the proposal permit the content of the wsa:Metadata element to be a choice of WSDL1.1 or WSDL2.0 service element?

<wsa:metadata>
[<wsdl11:service> | <wsdl20:service> ] <extensibility>* </wsa:metadata>

The use of choice here will (IMO) only serve to present the Web services community with unnecessary versioning and interoperability headaches down the road. At the very least, it will foster islands of interoperability where some subset of software is capable of consuming one flavor of EPR, another subset the other flavor and yet another subset capable of consuming either flavor.

Keep in mind the tenet that any optionality in a specification is the breeding ground of interoperability issues.

As I see it, the motivation for permitting a choice of either a WSDL1.1 or a WSDL2.0 service element is to allow Web services tooling and runtime software that has been implemented to a specific version of WSDL to easily produce and/or consume the metadata straight from the WSDL description itself. IMO, this motivation is both misguided and unnecessary.

Consider that software that consumes WS-Addressing endpoints carrying this proposed wsa:Metadata element has yet to be implemented (beyond any prototyping associated with this proposal). Thus, it will, of necessity, require a bit of engineering on the part of Web services runtime and tooling providers to incorporate support for EPRs that carry the proposed wsa:Metadata element.

Consider also that the essential information carried in both the WSDL1.1 and WSDL2.0 service elements is roughly equivalent. It is certainly the case that a WSDL2.0 service element is a superset of the information carried in a WSDL1.1 service element, although the WSDL1.1 service element's child port elements are not constrained to a single interface/portType as is the case with a WSDL2.0 service element's child endpoint elements. It is also the case that a WSDL1.1 description contains all the essential ingredients to populate a WSDL2.0 service element.

IMHO, it would be trivial, therefore, to transform, by whatever means, a WSDL2.0 service element to a WSDL1.1 service element and vice-versa. Thus, were the proposal to provide exclusively for a WSDL2.0 service element child of the wsa:Metadata element, we would improve the potential for interoperability between the componentry that issues the EPR and that which consumes it (regardless of which version of WSDL that software was designed to use) and eliminate a built-in versioning headache, at a cost of a trivial amount of code to transform the WSDL2.0 service element to a WSDL1.1 service element for software that is not based on support for WSDL2.0 descriptions.

Copy cat

Tom has also gone corporate.

I've gone corporate

I've started another blog on IBM's developerWorks site. There, instead of my usual rantings, I'll have measured, insightful and thoughtful commentary on things related to Web services, interoperability and distributed computing.

I'll keep posting regularly here though. :-)

Ah, the legerdemain continues

The WaPo has the details of the Bush plan to "save" the Sosul Security system: Participants Would Forfeit Part of Accounts' Profits.

In effect, the accounts would work more like a loan from the government, to be paid back upon retirement at an inflation-adjusted 3 percent interest rate -- the interest the money would have earned if it had been invested in Treasury bonds, said Peter R. Orszag, a Social Security analyst at the Brookings Institution and a former Clinton White House economist.

"I believe you should be able to set aside part of that money in your own retirement account so you can build a nest egg for your own future," Bush said in his speech.

Orszag retorted: "It's not a nest egg. It's a loan."

Under the system, the gains may be minimal. The Social Security Administration, in projecting benefits under a partially privatized system, assumes a 4.6 percent rate of return above inflation. The Congressional Budget Office, Capitol Hill's official scorekeeper, assumes 3.3 percent gains.

If a worker sets aside $1,000 a year for 40 years, and earns 4 percent annually on investments, the account would grow to $99,800 in today's dollars, but the government would keep $78,700 -- or about 80 percent of the account. The remainder, $21,100, would be the worker's.

With a 4.6 percent average gain over inflation, the government keeps more than 70 percent. With the CBO's 3.3 percent rate, the worker is left with nothing but the guaranteed benefit.

There you have it. It's just a scheme to cut Social Security benefits disguised as "personal accounts". It's not a 401K-like account, where you get to keep both what you invest and what you earn on that investment. You get to keep only the excess gains over an inflation adjusted 3 percent. The administrations wildly optimistic projections have you keeping roughly $21K after "investing" $1,000 per year for 40 years. The CBO's projections are for a more realistic average of 3.3 percent, which means you get diddly-squat over and above the guaranteed (reduced because you opted into the "personal account" program) benefit.

What a farce. Unfortunately, the ill-informed and disinterested public will be subjected to the administration's full-bore marketing campaign *cough*lies*cough* and FoxNews's cheerleading squad telling them how wonderful Dear Leader's plan to "save" Social Security is, and how terrible the Democrats are for opposing it. I suspect that unless there is rock-solid opposition from the Democrats and Josh Marshall's Conscious Caucus of Republicans, that the administration will be successful in its goal to eviscerate Social Security.

Thick or thin?

It's that time of year again, when high school seniors rush to the mail box to see whether the envelope is thick or thin. (I should note it is the only time they actually bother to retrieve the mail! ;-0) So far, my daughter is scoring 2 for 3 of the thick variety. Woo hoo! Fortunately, the one hold-out was her fourth choice of four. We're still waiting on the verdict from her first choice.

[Queue the Jeopardy theme song]

Over, Under, Sideways, Down

Jacek follows up on my MEST-Up post with the following:

I think the proposed name SomethingInterestingHappened (intentionally) leaves out the imperative and that's wrong. I'm not aware of any MustUnderstand semantics in the traditional message passing systems, and that's perhaps exactly what SOA(P) gives us. In other words, ProcessMessage represents a way for a sender of a message to be sure the recipient will do what the sender says (given compliant SOAP processors).

Yes, I was intentionally omitting the imperative (DoThis) because it implies that the sender knows what processing the receiver will apply to a given message. This necessarily requires an omniscient, top-down design of the over-all system; the antithesis of loose coupling.

However, the lack of imperative in a message's application-level semantic is orthogonal to SOAP's mustUnderstand semantic, which still applies in all its glory.

Both and Jim's and Savas's responses carry some great discussion in comments. I must say that I agree completely with Brian's comments to both follow-up posts.

Jim responds:

There are two themes which these comments are strung out along: that message-passing and procedure calls are equivalent; and that ProcessMessage is too low-level. Both of these are inaccurate and unhelpful

I don't recall making the analogy that message passing and procedure calls are equivalent. I certainly don't believe it to be the case. As to the point that ProcessMessage is too low-level; based on my more than likely limited understanding of MEST (and I'll have to admit that I only know from what I've read in Savas's and Jim's blogs. Ahem, guys... is there a paper we can read?) I tend to agree . I read with interest the ppt that Jim referenced. Specifically, chart 14, which reads:

Each Web Service we develop has to deal with message exchanges

• Those that it requires to expose its own functionality;
• Those that the Web Services it uses to interact with other Web Services;
• Message exchanges pertaining to the QoS protocols it supports.

Protocol demolishes the idea of Web Services as entities which are “invoked.”

• If you insist on having an operation to invoke, then “invoke” the ProcessMessage operation.

ProcessMessage is abstract, semantics:

• A transfer of a message from sender to receiver; and
• A request to process the received message.

What troubles me is that after reading this presentation, I am even more confused as to where MEST fits from an architectural perspective. Is it a programming model (as implied by the statement regarding invocation of an operation)? Or, is it an architectural style, as suggested by its namesake -- REST? Or, is it simply a retrograde slide towards what was once common practice before the layers upon layers of middleware made dealing directly with the lower-level protocol APIs, such as UDP and TCP/IP, a thing of the past?

Jim, citing the Waldo et al paper, correctly points out how things start collapsing like a house of cards when we fail to heed the collective wisdom in that paper. (Recall the infamous eight fallacies of distributed computing. Anyone designing a distributed system who does not first stop to cherish and grok these words of wisdom should be forced to have a scarlet 'E' tattooed on their forehead! But, I digress.). He continues:

Focussing on messages rather than procedure calls is a fine way to conceptualise and build services which are able to deal with the truth on the wire.

This statement is where I start to think that MEST is more about a programming model abstraction rather than an architectural style, such as that defined by REST. It's not that there's anything wrong with that, I just think that we shouldn't be confusing the two.

An eternal golden braid

Sean has a really good article on ITworld.com: Wall, Escher and Berners Lee: An eternal golden braid. Go read it.

MEST-Up

Someone posted a comment to my none of the above post that I think is worth calling out:

I think all this MEST stuff is simply giving a name (and a bad one at that) to a well known pattern that's been used in loosely coupled environments for years. It predates SOA by at least a decade. The rule is that everything's message-based. I don't need to think in terms of ProcessMessage. If I want a paradigm to associate with this then I think the pub-sub one is better: my message consumers subscribe to the network and my message producers publish to the network. I've used that approach many times before (and heard it used by others too) and most people don't have a difficult time understanding it.

Amen to that!

IMO, the semantics of messages in pub/sub aren't ProcessMessage, they are (or should be) more along the lines of SomethingInterestingHappened. Note the past tense. I think that is the key to achieving a loosely coupled enterprise.

Instead of CreatePurchaseOrder, you would have PurchaseOrderCreated. This important semantic difference opens up a world of loose coupling that is unavailable to the imperative-based environment of remote procedure calls. Subscribers subscribe to messages (events) that interest them and act on the event upon receipt of the message in whatever way they choose. Subscribers are not told what to do, they are informed when something has happened and react according to their programming. While one subscriber might insert the purchase order into an ERP system in the form of a Sales Order, another might simply log the event. Another might update the statistics in an enterprise dashboard. The compositional possibilities are endless. Subscribers can come and go without impacting the producer/publisher. This is the true nature of loose coupling.

Sun: Pledges? We doan need no steenkin' fancy pledges

Groklaw notes that Sun may be leaning towards permitting their 1600 patents to be used for any open source development, not just those with CDDL licensing.

This puts a slightly different perspective on Jonathan's recent post in which he claims that IBM's contribution of 500 patents to open source is not what it appears.

I am glad to see that Sun is listening, and hopeful that they will respond positively by allowing their 1600 patents to be used for any open source project that meets the criteria in the OSI definition, just as IBM has already done.

The Privatizer's Catch-22

Krugman:

They [the privatizers] can rescue their happy vision for stock returns by claiming that the Social Security actuaries are vastly underestimating future economic growth. But in that case, we don't need to worry about Social Security's future: if the economy grows fast enough to generate a rate of return that makes privatization work, it will also yield a bonanza of payroll tax revenue that will keep the current system sound for generations to come.

Alternatively, privatizers can unhappily admit that future stock returns will be much lower than they have been claiming. But without those high returns, the arithmetic of their schemes collapses.

It really is that stark: any growth projection that would permit the stock returns the privatizers need to make their schemes work would put Social Security solidly in the black.

I'm glad to see someone finally call the administration on this point. You can't have it both ways. Of course, the administration's deceitful marketing machine will certainly try to pull the wool over our eyes with their accounting legerdemain.

Additionally, a point that is rarely addressed, and which has been conspicuously absent from any of the discussion regarding the President's proposal: what about those people who become disabled before they reach retirement? Do they have to survive on the meager savings in their private accounts, or do they get full disability benefits? What about survivors? Do they get full survivor benefits, or do they have to get by on whatever the deceased had saved to date in his/her private account?

Finally, will the private accounts be federally insured, so that people need not have to subsist on catfood in the event that their private account is gutted by another Enron?

Enquiring minds want to know!