I have an idea for an alternative web architecture I'm calling "symphonic". Picked that because I was lucky enough to catch NigelKennedy and the Sydney Symphony Orchestra play Vivaldi/Bach last night and realized what the BpMs people call "orchestrations" are anything but.

* The symphony is dynamic, varying its orchestrations to fit the availability of the players and the demands of the piece. BpMs orchestrations are static, defined up front by BusinessAnalyst''''''s. 
* The symphony is agile, varying their decisions about form and to some degree content by testing the audience's response with light short pieces up front. BpMs orchestrations are BigDesignUpFront, denying users the ability to vary their own workflows except by falling back on informal conversation. 
* The symphony controls its collaborative behaviour through feedback, both between individual members, as a whole, and in relation to the audience. BpMs orchestrations are controlled by projective business rules localized to individual states of a brittle FSM.

Inspired by the soaring example in front of me I conceived a SymphonicArchitecture for web apps. I'd already been wondering about ruby continuations for workflow, then thought of using ServerPush on the front for session management, then conceived of continuations as subscribers in a MultiCaster ...

But why not just REST? Well, RestArchitecturalStyle sucks. It's dictated by assumptions that never really held:
* That there's no such thing as continuations, so all web apps must be chopped up into MVC handlers - ridiculous, see SeasideFramework.
* That web-servers can't push - nonsense, see RealtimeOnRails or the various SlowLoad ServerPush adaptors.
* That sessions must be serializable and then adapted to stateless thread pools in the server. Fiddle-faddle, with Ajax there's no reason the server needs to implement session-based logic at all. Just AjAx the logic into the client as necessary to let your session-based objects live there and nowhere else.
* That RPC is more natural than MultiCaster. Balderdash, see LindaTuples or any of its progeny. Or just look at Excel. But we can do better than Linda - see RegularExpressionSetArithmetic or, more concretely, ExtendedSetTheory for addressing the MultiCaster space.
* That there's something in client-server architecture that's magically superior - more useful, more efficient, blah blah w3c blah - than P2P. Village idiocy - see BitTorrent.
* That you need some kind of OLAP database and associated model and/or data objects to serve transactions - addlepated obtusity, see PrevalenceLayer/MemCached.
* That WorkFlow is something only the suits do. Outright HippyDippiness - see TracProject.

'''What's SymphonicArchitecture?'''

It's a web app architecture in which opportunistic client connections managed as continuations maintain session state, a variant of MultiCaster reflects application state, and P2P techniques provide for scalability. The motivation for the architecture is to rich-client web apps that are simple to read and refactor, simple to modify and extend via OOP, and which scale much better than 3-tier enterprise architectures without the hardware provisioning those require.

'''How could that work?'''

Let's look at some precursors. Beginning with SeasideFramework and RubyOnRails. SeasideFramework is very cool. So is Rails, but it can't match SeasideFramework for maintainability on account of Ruby continuations aren't serializable. And SeasideFramework doesn't scale on account of continuations are too memory hungry in the server. But then ... why keep the continuations in the server?

'''So we can store them and maintain session state over multiple client requests.'''

Why store them in the server? They're represented by cookies and xml in the client - no reason to persist anything session oriented except its results as they are important to the person running the server. If there are any such results ... hence AjaxSmalltalk or similar.

'''Why MultiCaster?'''

* From a continuation's POV, all a human is is a data store - same semantics as a file in a file system. But if we have to glom such a continuation onto a deterministic main loop we'll lose all the asynchrony at that point - we'll be back to the RestArchitecturalStyle again. To avoid that, all control flows in our system must be asynchronous - publish and subscribe. If the pub/sub space is properly domain specific, which we'll need for good OOP, and if we scale by hubbing ... that's the MultiCaster pattern. The only extra trick here is we're happy for our agents to block all they like - every block forming a continuation.

'''How can you avoid the hardware provisioning?'''

The purpose of a server is to reflect client state for multiple interacting clients. Well now we just need to get the clients talking directly to one another and only use the server for transaction service, persistence, and name services.

'''Where can I find an implementation of this supposed architecture?'''

Nowhere, yet. Symphony in Red was an idea about it. But now that handsome young man in the red hood and cape has tossed a few more spanners in the works and is rebranding it WebThreePointZero or some such nonsense, a SmalltalkLanguage extravaganza. Different architecture, same intent. Oh the humanity!
----
CategoryWebThreePointZero