|
At Sun, we have long predicted the impending doom for systems that are often termed Generation 1 (G1), or as I call them, “linear architectures”.... systems that are wholey built from a traditional 2/3-tier architectural approach, in which all elements of the presentation, business and data management layers are solely constructed for a single application, not built for “sharing”.
For many reasons, G1 systems and approaches, have continued to have longevity, why won't they continue? For we have been using the same system paradigm since the mid-70's, a continual drive towards commoditization and manufacturing has thus far survived major disruptions.
The shear speed and power provided by the network of connected computing resources is seeing a shift in the paradigm from the network as a data transfer media, to the network as a fabric for the execution of complex distributed services. This is perhaps arguably one of the challenges facing our large scale SMP product line (but we're not alone in this challenge - IBM's Mainframe line is really having some challenges).
The problem that is becoming more apparent is the exponential complexity introduced by a complex Service Oriented Architecture (loosely coupled coarse/medium grain just in time compositional systems) when architected using the mechanisms traditional to G1 systems.
An example of this fractal complexity:
Company A including a service from company B in their SOA. Company B then compositionally includes services from C to complete, perhaps w/o A's knowledge, what happens if C uses the same service from A...
At best this means that identity and privacy need to be further protected, at worst we may have a re-entrant/recursive execution problem (yeah single box threading can be hard, but network threaded apps where you don't have control of the components or sourcecode?), or “ilities” problems as the G1 paradigm typically does not find the need to elaborate security, scalability, availability, manageability models as part of the core design since each “tier” is typically fully characterized only for use by the preceding component: “the EJB's only get called through OUR Servlets” or “the DB is only accessed through OUR EJB's”.
With the movement toward component compositional models, SOA's, and Grid computing we begin to realize that a new paradigm is afoot - both with it's challenges and advantages:
What are G.next's core challenges:
- fallacies of networking
- network “enforced” isolation through distribution
- contiguous system memory vs. distributed memory
- service operation model & recognition of partial failure
- federation of core “identity services” including identity, context/role, entitlement
But it carries substantial advantages:
- differentially granular and dynamically scaled systems
- ability to take advantage of locality / proximity in execution
- dynamic parallelization of workflow
- ability to version/add functionality (carefully) in-vivo
- declarative security levels and well known enforcement models
- enforce isolation rules / best practices through interface “encapsulation”, resource management and controlled access
What are some of the major trends that I forsee needing in the construction of G.next based systems:
- Majority of time in planning and assembly vs. iterative contstruction
- Improvements in model annotation to capture systemic qualities and referential patterns (micro-architectures) so that non-functional behaviors can be better understood
- Declarative models vs. code (though pseudo code could be used for declaration for rich syntax)
- Federation of core services ( a core tenant of SOA that many forget!)
- Ability to deal with distributed & distributable data
- Append only / constant query data models (fail in place, recover from clone)
- Omnipotent debugging, AOP and debugging languages like “D”
- Systemic (compositional) SLA managment ... what is possible & what is desired
- Micropayment environment to allow for “for fee” SOA services
- Fine grained identity & entitlements to allow for security level agreements w/ tooling
More later!
Permalink
Trackback:
http://blogs.sun.com/dhushon/entry/requirements_for_architecture_next
|
