Patrick Logan implies that the solution to having an SOA model inproc is Erlang.I am pleased Steve Loughran is taking a look at Erlang. He's a smart guy so I'm interested in his response.
Instead of "solution" though I would say "paradigm".
The origin of the name Erlang is in the history of telephony.
For my money, you either design for inheritance (and this is not an easy task, folks--it requires a tremendous eye for possibility and detail)--or it needs to be prevented.Again, this is because for all the mechanisms in Java-like languages, they still do not support the reality of software development. Developers get into trouble, and rather than make the developer's life easier, the language designer introduces another kind of straightjacket.
The problem is the straightjacket, not the lack of ten kinds of straighjackets.
The more I see and read from the MBF folks, the more I realize they should be in charge at MSFT. Just hope all the Whidbey/Longhorn nonsense doesn't slow up the good stuff.
But that doesn't mean that it doesn't need some improvements to meet our future challenges. ?Coordinating XML messages between applications? isn't quite the same thing as ?coordinating work between fine grained services?.
OK, if you *are* still interested in SOA tomfoolery, and you've turned on to Erlang, the next thing to consider is Micro-Workflow.
If any Microsoft employees read this cynical blog of mine, please note that Dragos Manolescu is probably up in Redmond today working on some stuff for you. Take him to lunch.
Part of a winding blog thread on what is a "service" in a "service oriented architecture".
Owing to the fact that I am losing interest in SOA bullshit rapidly, I will make one reference to those that have the answer to all this "in proc" hullaballoo.
Witness the continuing crappage.
What if...
If Sun had gone with Smalltalk rather than Java, where would they be now?
If Microsoft had gone with Smalltalk instead of C#, or way back in the 1990's when they could have forged something with Digitalk instead of their long and winding DCOM fiasco.
If IBM had simply *stuck* with Smalltalk instead of jumping to Java.
The head spins.
What if the Momenta management team had been competent?
Let's try to reconcile this...
I think it's going to take until 2010 until we really see the simplicity of Lisp come back to "commercial" programming systems.with this...
The whole 'partial' implementation of classes will come as a bit of a shock for most old school OO developers, who would probably cringe at the thought of implementing the class in different locations, using different languages for each implementation -- it seems quite messy and unstructured. But if we step back for a moment and think about the possibilities of using this style of code, we can see that its more than just having classes written in different languages, and in different locations -- it's about splitting the 2 layers, control and presentation.Seems quite messy and unstructured.
I offer another invitation to rethink the WinFS problem before it's too late. For example, what if you were to drop the idea of a schema?
Instead of trying to squeeze a database as you know it into a file system, how could you make a database more dynamic?
Slice the database in a different dimension. Throw it in a linear accelerator, smash the database particles, and see what you get.
Think "outside the box" instead of just trimming one box to fit inside another.
Ahh, components. Anybody heard this story before? I remember hearing it with objects, then components, now services.... Look, we've had ways to partition our code up before, and we've failed to take advantage of it. Note that I say that very deliberately: we failed. Not "the industry hype wore off", or "the technology couldn't deliver", but "we failed to use the technology as it was meant to be used". We've had our chances to build apps and systems out of constituent parts. The problem is, we've never done it. Or at least, not on any recognizable scale. What makes you think this time around will be any different, Harry?Well, this time we have XML. 8^)
From The Register reporting on a Business Week article...
WinFS appears to be the main casualty, having already been curtailed. A year ago Microsoft confirmed that Longhorn wouldn't, as expected, introduce an entirely new database storage architecture in which file systems NTFS would be a plug-in. Rather, Microsoft would add database like properties to NTFS. Business Week reports that the new features of WinFS will only work on local storage rather than across networks. That's been pushed into Blackcomb, which is way out towards the end of the decade.Allow me to toot my horn for seeing this one coming over a few items I posted in recent months.
To reiterate I think the problems being addressed by WinFS are far better addressed not as a file system but by rethinking "the database". But then that would even more directly eat into the SQL Server cash cow. Either way, there are some tangly knots along the way that had simply been bypassed in the several WinFS presentations I've seen.
This is a good call, but too bad Microsoft has put countless hours into the WinFS over a decade now, if you count the origins back in Cairo-pre-Win95. If I read the above as WinFS will always be a "local file system" capability, then this is a total loss. Come back when this thing understands multiple users and runs on the network with location independence.
i.e. Come back when it is *really* a database, but not complex and not naive and self-managing... this is not easy.
Reports from Redmond suggest that the Avalon UI archtecture and the "managed code" API are also likely to be trimmed in order to get this most reluctant of steers out of the gate.Two for two? Can we say goodbye to the waste-of-time XAML yet?
