What sells?

A comment from Adam V. on why complicated stuff like Share Point is productized, but something as simply beautiful as a Wiki is not as easily productized.

In response I think this is a two-sided coin, with a customer as well as a vendor.

I think there is something to the "monetizing" argument.

I think it also comes from the customer side... I continue to see a lot of behavior in large enterprises that seems to believe anything of *value* (not just cost, mind you) should by definition be big, complicated, and even cumbersome.

Really. I think the portal vendors, like other kinds of vendors, are just capitalizing on these behaviors. "Selling" something as simple as a Wiki, or even as simple as Smalltalk, is *more* difficult than selling the more complicated and costly approximations.

Reading vs. Taking

Mark Baker, in his comment to my "Is this ReST?" post, suggests "take" isn't often needed...

My machine's offline today, but I responded last night; yah, the unsafe GET isn't such a hot idea. And to add/respond to what Bill said, I'm finding that one often doesn't need TAKE semantics at all; just support indexing, e.g. /queue/?start=1&end=10, safe retrieval via GET, queueing of the documents for as long as you want/need to, flushing the old stuff after that point, and then returning 410 when asked to return a flushed document. Not totally general, but it's worked for me on a couple of occasions.

This could be so in a queue where there is one consumer or where multiple consumers have an agreed-upon policy for avoiding double consumption.

In the general case though, FIFO queues are just one desirable coordination model...

Is this ReST?

Is this implementation of queueing a good example of the ReST approach?

Mark?

In particular I am wondering about the use of GET to dequeue an item. My understanding of how GET should behave is contrary to this. That is, two consecutive GET's with the same URL should have the same result, assuming no intervening POST, DELETE, or PUT that would affect that URL.

Corrections or corroborations appreciated.

The problem with Share Point (and most "portals")

I love the way I can shape a Wiki to provide a "narrative" that is still a "web".

Why does Share Point (and portals in general from what I have seen) provide a sterile, partitioned, austere "user interface" experience?

Clearly the best of the web is based on self-navigable "narratives". Maybe there is a way to do this in Share Point, if I had the time to discover more about it.

If there is, this should certainly be the default behavior.

"Entity Aggregation" (i.e. data) and SOA

From the MSFT dotnet Architecture Center, "SOA Challenges: Entity Aggregation".

Speak of the devil. Another view on the SOA "data problem".

See for example the sections on "Cross Entity Queries" and "Entity Aggregation Service". Then the paper proceeds into some useful solution approaches.

We need a great utility player, not a specialist

Clemens Vasters on a pure message-based architecture vs. data-based integration...

It will make your architecture infinitely more agile...

Time will tell. I think the crux of the matter will be to determine where database integration makes sense, and where messaging integration does.

Again, I think there is a fundamental flaw in message-oriented architectures that can be addressed by improving the database-oriented architecture. We need agile databases as much as we need messages and events.

Good database design is a start. Manageable data platforms are required. Tuple spaces offer some insight too. They provide significantly more expressiveness than relational databases or message buses. A tuple space is like a great utility player in baseball.

I think "pure" SOA is SOL. The buzzword is actually a buzzkill. There will be long lessons learned where the victors will be SOA-based ERPs like SAP Netweaver and Microsoft's Business Framework (MBF apparently being horribly behind at this point). Yes, these systems are "SOA" but they also provide a data-based integration as well.

Why so late to the "table" (so to speak)?

The discussion was about how difficult was to map the db to an object model, how 'transparent' can persistence be, and the fact that noone wants to write ADO.NET code manually anymore.

I think it is a fair question to ask why Microsoft is so late to the table with O/R mapping? Many problems and solutions have been addressed in academia and industry for well over five years.

Waiting for the one, true, API (which will certainly have faults... this is software) is stretching out another couple of years, apparently, at best.

Do you think I like picking on Microsoft? It's just the company has never seemed to grasp that software has to evolve, or maybe it's just that I've never grasped the business sense of their "rewrite the entire API just once" approach to Longhorn. I can only assume there is great business sense in this. Technically it can't hold up, and so will cost "us" money for years to come.

What a concept!

programs will be stored as XML documents, so that programmers can represent and process data and meta-data uniformly

TkZinc

TkZinc looks cool.

XAML as a document format --- might work

Update: Wes writes in the comments:

Microsoft has foreseen versioning issues with XAML. The XAML parser does allow custom mappings between names of elements and attributes to their corresponding .NET types and properties, so that is not really an issue.

This would seem to allow a developer to map a version 1.0 document's class names and properties to a version 2.0 implementation's classes and properties. Good news. The original concern is still there: that XAML embeds the implementation at all is a stronger bind to dotnet than XML generally should have. But that's a business decision, not a technical one. At least within versioning dotnet applications, using XAML as a "document" should have an upgrade path for document versions.

Original post:

I am not sure about the wisdom of using XAML as a "document" format. As I wondered previously, wouldn't this embed in a "document" essentially the classes, instances, methods, and properties of the *implementation*?

Can someone explain how this isn't so? Or explain why this is a good thing for a document format?

Surely implementations should be able to change without having to upgrade their documents!

WikiTravel

Have you seen the Wiki Travel Guide?

Graham Glass on Programming Languages

Graham Glass...

"i truly believe that the days of coding software using low-level languages like java will be over in 5 years or less."

But I'm not sure what Graham means when he writes...

"frankly, i would have written glue and fabric (which would be classified as system-level software) using higher-level tools had they been available."

Graham was a Smalltalk (and Gemstone, I believe) developer before moving to Java. (Somewhere in there with he also worked with C++.) Maybe he was among the legions of Smalltalk developers who assumed it would die under the pressure of Java. Ha!

Belocolus

I have to point to this from Sean McGrath if for no other reason than it uses the term "belocolus".

But there's also some content worth quoting...

Your problems lie in two fundamental concepts that need to be central to how you think about business processes in a distributed world - (a) event driven execution and (b) temporal decoupling.

My problems lie in some other fundamental problems of the enterprise. Nevertheless this quote above is a good one to keep in mind before suffering a vendor or buzzword headspin.

More from the in-depth article...

Are you one of those companies we are constantly told about that is making great headway with Web Services behind the firewall? If so, I suggest you taken a close look at the amount of temporal coupling implied by your model. Remember: upside down is the right way up.

"Nullable Types"

Update: More concerns from Wesner Moise's blog on "Why elevate Nullable Types?". The interactions of complex features just create more complexity. Rigid languages resist change. Flexible languages rarely need to change...

The new nullable types syntax points to a weakness in the design of generics.

The constraints mechanism in CLR generics currently disallows C# operators from being lifted from the underlying base type to their nullable versions.

An explanation of Nullable Types which is a new concept in C# 2.0, as far as I can tell because the language designer did not get the concept of objects quite right. (For earlier evidence, consider the C# concepts of boxing and stack allocated structs vs. objects, read up on their justifications, and then consider the languages that don't expose boxing to the typical developer.)

I assume Nullable Types is a kludge for supporting database programming, because some column for some row might have a value or might be null. Of course, database nulls are themselves a bit of a kludge. They muck up database programming and should generally be avoided. So why move that muck up into the programming language? Again, I guess this is because C# can be used to write stored procedures in the next version of SQL Server. There's enough muck to spread around, hopefully something beautiful might grow from this, but I'm skeptical as usual.

Further muck...

There is special treatment for booleans. Nullable bools are a form of ternary boolean values, which can safely be used in if, for, while conditions and logical expressions without throwing exceptions.

This is assuming one wants Null and False to behave the same. (I assume this is the intended behavior.) This is questionably useful.

Integration Databases

Martin Fowler writes about the difference between an Application Database and an Integration Database. He continues by expressing his favor for a message-based integration rather than an Integration Database.

I dunno. The devil is in the details. Here are some thoughts...

For one thing, message-based solutions are often based on new technology, and often from a new vendor. Even if the quality is good, avoiding vendor lock-in is not easy, even with a "standard" like JMS.

Unless the developers have done message-based implementations already, new skills are needed. If the enterprise has an ERP like SAP R3, then there's another issue to deal with: is the messaging product the "enterprise bus" or is SAP the bus? The answer may not be ideal either way. Going outside of the ERP though can lead to duplicating functionality or at least "rules", and/or lead to too much effort at the boundary between messages and the ERP API.

(This gets better when the ERP implements messaging, but what about those "legacy" message buses?)

The lower the number of applications that need integrating, the more I favor using an Integration Database. Care is still needed if vendor lock-in is to be avoided, but most enterprises I suspect have their databases of choice, SQL Server, MySQL, whatever. The open source databases like MySQL and PostgreSQL are perfect for an Application Database or an Integration Database at very low total cost of ownership.

If one of the systems is an ERP, the more I favor an Integration Database, especially if the developers are familiar with the database technology and unfamiliar with a message-based solution. These databases tend to be an Application Database, although the they could be both: what we're really talking about is Application Data Model and Integration Data Model; both may be present in the same database.

I'd much rather get the best of both the data and message worlds, and more, by using a Tuple Space.

Databases are not hot right now, but they are certainly tried and true, and I bet the enterprise has a better license for them, and more developers who can handle them than it does for messaging. It may not be SOA, but you probably won't be SOL either.

Scheme SYNTAX-RULES How-To

In learning to write Scheme macros, I have noticed that it is easy to find both trivial examples and extraordinarily complex examples, but there seem to be no intermediate ones.

Got that right. Nice.

Improvements needed in VS Team Edition

Steve Loughran writes...

[it] is interesting to see what is in -what MS and their IT department customers think we need. In: all the Rational-class beaurocratic workflow. Not-in: lightweight presence indicators like highlighting who is editing which file.

The other amusing thing is that the Visual Studio Architect Edition doesnt include testing. That's right. Architects design with fancy UML tools; developers are separate people who write tests, testers are people who run them.

The Road from Genera to Longhorn

The Monad Shell in Longhorn would be really cool if the developers thought to use Presentations as found in the Genera Listener and now in the Common Lisp Interface Manager (CLIM).

Hopefully they've read the literature, and maybe own a Symbolics machine.

Blogger Problems

I've never been happy with Blogger. The quality is inconsistent at best, and remains so many months after the Google aquisition.

For example, I have no idea what happened to my "recent posts" on the right side. They disappeared sometime on Sunday.

Another example, I edited my template a week ago or so to remove the CSS indent from paragraphs in the items I post. OK, I need to look up the proper way to do this maybe, to avoid template changes coming from on high. But could I have a warning or a chance to accept the template changes?

Other changes to the template have been preserved. Maybe I just put the CSS changes in the wrong location in the template.

Smalltalk for Mobile Applications

What do developers of mobile applications need? They need a development and deployment platform that allows them to develop on traditional client platforms as well as on mobile devices. They need a platform that has the same power available on a full-scale platform, without all of the excess that normally comes with that. They need a platform that is easy to work with, and easy to update in the field...

• Creating software for mobile platforms is expensive. Using Cincom Smalltalk, development can proceed on a "pay as you go" model, driving down upfront development costs.
• Complete binary portability — Developers selecting Cincom Smalltalk can develop on their favorite platform and then deploy to any other — including Windows® CE, Windows Mobile for Pocket PC, Windows XP Tablet PC Edition and Linux® — with no changes. Cincom Smalltalk supports the x86, XScale, and StrongARM-based mobile devices, as well as standard Windows, UNIX, Mac®, and UNIX workstations and servers.
• Cincom Smalltalk has been under continuous development and deployment for over 30 years now with great success at a number of Fortune 500 firms. None of the competing solutions can point to a similar record of robustness and maturity.

Longhorn is becoming a Pig Pile

I almost don't know where to begin with this. The pressure is building on Longhorn to be more than magical. Does Microsoft not know how to deliver an evolutionary set of products and services? Is this self-destructive engineering or brilliant business? Or something in between.

Alan also told me that one of his goals was to come up with a unified model for accessing data across most Microsoft programs. It would be nice, for example, to be able to load up Microsoft Money data the same way you can in SQL Server using ADO.NET. If you put aside the emotion and really think about it for a second, that's one of the key reasons they're putting WinFS into Longhorn, to remove the "program-specific silos" that happen in application development today, and allow WinFS to be not only a file storage system, but an information storage system as well...

Microsoft wants to make ObjectSpaces the way IT'S OWN teams get data out of WinFS in the Longhorn time frame... And for most, normal, sane people, this makes a decent amount of sense.

So, ObjectSpaces is an important technology. Microsoft wants to get it right in V1. With every product being relied upon it when Longhorn comes out, they almost don't have a choice in teh matter. They don't want to have to wait for it to be usable until V3, like most Microsoft programs, they want it done right the first time. And that's admirable. It's not like you're not going to see bits shipped in beta form between now and 2006. You'll still get to use it, so what's the big deal?

It's a Vendor Fest

Ted Neward answers the wrong question. The question is not whether these things are needed ("security, transactions, messaging and quality-of-service communications efforts, and so on").

The question is whether the WS-* fiasco is the right approach and result.

I am diabetic...

...and I vote.

Patents

Simson Garfinkel... "Are you Roundup ready?"

And it's just May

Of course, Mr. Moore is being selective in what he chooses to include in his movie; he's a polemicist, not a journalist. But he implicitly raises the issue that much of what we've seen elsewhere during this war, often under the label of "news," has been just as subjectively edited.

WS-Wha?

Jeff Schneider proposes a new WS-* spec on the Service Oriented Architecture Yahoo Group:

"Absolutely Simple Services For Adaptive Content Exchange"

8^)

Movies

Jim is writing about his love of bad movies. This may be a spot to write about Shrek II, although it wasn't bad.

I went reluctantly last night to see Shrek II. I was reluctant because the first Shrek was so good, and the trailer for Shrek II made the latest seem like one of those forced sequels that falls way short of the original.

The trailer did not do justice to the movie. This is a rare instance where the sequel approaches (but does not quite match) the original. In other words, I laughed my ass off.