Contribution 60

From WikiContent

(Difference between revisions)
Jump to: navigation, search
Current revision (00:09, 14 July 2008) (edit) (undo)
m
 
(8 intermediate revisions not shown.)
Line 1: Line 1:
== Heterogeneity Wins ==
== Heterogeneity Wins ==
-
There has recently been a surge of interest around ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.
+
The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in ''polyglot programming'', which refers to the use of more than one core language in the provision of a software system.
-
Polyglot programming has been around for some time. An often-cited (but somewhat misguided) example of polyglot programming is the mix of SQL and programming-language code. This does not constitute ''true'' polyglot programming, as SQL is really a domain-specific language for persistence as opposed to being a direct contributor to the core, functional requirements of a system. The key differentiator is that SQL is not Turing-complete; perhaps then, the better definition of the ''modern'' sense of polyglot programming is where more than one Turing-complete language contributes to core functionality.
+
Polyglot programming is not a new concept: one prominent example from the past is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.
-
But alas, even 'Turing-complete' polyglot programming is not new: consider (for one) the old Microsoft architecture of Visual Basic front-ends talking to C++ COM objects on the back-end. So, what change has taken place that fuels the interest in polyglot programming?
+
So what changes took place to fuel this renewed interest in polyglot programming?
-
The change was that ever-increasing bandwidth and computing resources conspired to enable text-based protocols to become a reality: gone are the days when arcane binary protocols were a pre-requisite to efficient distributed systems. Text-based interoperability began with XML/SOAP-based web services and continues with RESTful architecture implementations[1] and other, 'smaller' protocols including Atom and XMPP (for example).
+
The change was that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues to evolve with RESTful architecture implementations and other 'smaller' (but no less important) protocols such as Atom and XMPP.
-
This new breed of interoperability technologies affords far broader opportunities for the development of heterogeneous applications simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and at no time in the past has this been more possible than the present. Text-based interop has blown the doors off what was previously possible, the impact of which is largely underestimated.
+
This new breed of technologies creates far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible.
-
Architects can now combine specific, powerful tools in the provision of software that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. As an industry we are just beginning to see this effects of this; there has been a combinatorial increase in the technology topologies of modern systems. This is not just a reflection of their diversity, but is a testament to new possibilities.
+
Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ ''the right language'' to now being able to employ ''the right paradigm''. The effects of this change has begun, and manifests itself as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their inherent diversity, but a testament to new possibilities.
-
While choice is not always a good thing[2], it is 'less worse' than the alternative in the context of architecting modern software systems. As an industry, we are faced with very serious problems[3], and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[4].
+
While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].
 +
 
 +
Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.
-
Your job as architect has become even more challenging, because technology silos are crumbling in the face of the new interoperability; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.
 
By [[Edward Garson]]
By [[Edward Garson]]
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
This work is licensed under a [http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
 +
== Footnotes ==
== Footnotes ==
-
[1] - Many architects prefer the RESTful architectural style over SOA, because most SOA implementations degenerate into the architectural equivalents of old-style RPC, the only difference being XML as the payload format as opposed to some binary protocol.<br/>
+
[1] - The impending multicore era may well prove to be the most significant problem yet faced by the software development community.<br/>
-
[2] - _The Paradox of Choice - Why More Is Less_, Barry Schwartz<br/>
+
[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>
-
[3] - The incumbent multicore era will prove to be the most significant problem yet faced by the software development community.<br/>
+
 
-
[4] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm<br/>
+
Back to [[97 Things Every Software Architect Should Know]] home page
Back to [[97 Things Every Software Architect Should Know]] home page

Current revision

Heterogeneity Wins

The natural evolution of computer technology has brought about important changes with respect to the tools that architects are able to employ in the provision of software systems. These changes have brought about a resurgence of interest in polyglot programming, which refers to the use of more than one core language in the provision of a software system.

Polyglot programming is not a new concept: one prominent example from the past is Visual Basic clients talking to COM objects authored in C++. Fundamentally speaking, this architecture leveraged what those languages were good at in their heyday.

So what changes took place to fuel this renewed interest in polyglot programming?

The change was that technical standards together with ever-increasing bandwidth and computing resources conspired to make text-based protocols viable: gone are the days of arcane binary protocols as a pre-requisite to efficient distributed systems. Text-based interoperability largely began with XML/SOAP-based web services and continues to evolve with RESTful architecture implementations and other 'smaller' (but no less important) protocols such as Atom and XMPP.

This new breed of technologies creates far broader opportunities for heterogeneous development than ever before, simply because the payload is formatted text, which is universally generated and consumed. Heterogeneous development affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible.

Architects can now combine specific, powerful tools that move the yardstick from previously being able to employ the right language to now being able to employ the right paradigm. The effects of this change has begun, and manifests itself as a combinatorial increase in the architectural topology of modern software systems; this is not just a reflection of their inherent diversity, but a testament to new possibilities.

While choice is not always a good thing, it is 'less worse' than the alternative in the context of modern software architecture. As an industry, we are faced with very serious problems[1] and we need all the interoperability we can get, particularly as the incumbent platforms are not well equipped to resolve them[2].

Your job as architect has become even more challenging, because technology silos are crumbling in the face of new possibilities; embrace this, think outside the stack, and leverage the new diversity: heterogeneity wins.


By Edward Garson

This work is licensed under a Creative Commons Attribution 3


Footnotes

[1] - The impending multicore era may well prove to be the most significant problem yet faced by the software development community.
[2] - The Free Lunch is Over - Herb Sutter, http://www.gotw.ca/publications/concurrency-ddj.htm


Back to 97 Things Every Software Architect Should Know home page

Personal tools