ted@tedneward.com | Blog: http://blogs.tedneward.com | Twitter: tedneward | Github: tedneward | LinkedIn: tedneward
Some of it for the better, some for the worse
More importantly, the goals of what "the Web" are meant to be have changed
So how do we build "Web apps" today?
What exactly is a "Web app"?
Is building a "Web app" really the point of what we want to do?
The Web has gone through several technology iterations
not so much the approach, but the tools and technologies
and the way in which we used it all
and, as a result, how the Web is built and used
Project Xanadu was the brainchild of Ted Nelson
"A word processor capable of storing multiple versions, and displaying the differences between these versions"
"On top of this basic idea, Nelson wanted to facilitate nonsequential writing, in which the reader could choose his or her own path through an electronic document."
http://en.wikipedia.org/wiki/Project_Xanadu
"Xanadu, a global hypertext publishing system, is the longest-running vaporware story in the history of the computer industry. It has been in development for more than 30 years."
"Xanadu was meant to be a universal library, a worldwide hypertext publishing tool, a system to resolve copyright disputes, and a meritocratic forum for discussion and debate. By putting all information within reach of all people, Xanadu was meant to eliminate scientific ignorance and cure political misunderstandings. And, on the very hackerish assumption that global catastrophes are caused by ignorance, stupidity, and communication failures, Xanadu was supposed to save the world."
Source: http://www.wired.com/wired/archive//3.06/xanadu_pr.html
Every Xanadu server is uniquely and securely identified.
Every Xanadu server can be operated independently or in a network.
Every user is uniquely and securely identified.
Every user can search, retrieve, create and store documents.
Every document can consist of any number of parts each of which may be of any data type.
Every document can contain links of any type including virtual copies ("transclusions") to any other document in the system accessible to its owner.
Links are visible and can be followed from all endpoints.
Permission to link to a document is explicitly granted by the act of publication.
Every document can contain a royalty mechanism at any desired degree of granularity to ensure payment on any portion accessed, including virtual copies ("transclusions") of all or part of the document.
Every document is uniquely and securely identified.
Every document can have secure access controls.
Every document can be rapidly searched, stored and retrieved without user knowledge of where it is physically stored.
Every document is automatically moved to physical storage appropriate to its frequency of access from any given location.
Every document is automatically stored redundantly to maintain availability even in case of a disaster.
Every Xanadu service provider can charge their users at any rate they choose for the storage, retrieval and publishing of documents.
Every transaction is secure and auditable only by the parties to that transaction.
The Xanadu client-server communication protocol is an openly published standard. Third-party software development and integration is encouraged.
Show me HTML!
This was the era of the static HTML page
Geocities, MySpace, "home pages", remember?--- http://www2.warnerbros.com/spacejam/movie/jam.htm
This was an age of entirely HTML-based web pages
Then we wanted some small amount of server interaction
Web page "hit counters"
Temperature conversion
Access to server-side environment values
Maybe even store a form to a database
This was the era of CGI/ISAPI/NSAPI/etc
Perl scripts, bash scripts, C++ plugins
Pages could now be slightly dynamic
HTML is too limiting; give me power in the browser
Applets, Flash, Silverlight--- other technologies came and went here, too
Server remained simple, though its complexity was growing
for example, applet could make CORBA calls to the server
or, applet could (w/the right JDBC drivers) call the database
But applets were ugly, and non-uniform--- not to mention a "security hole"
So processing shifted to the server
Servlets/JSP/"Model Two"
ASP/ASP.NET
Ruby-on-Rails
PHP
"MVC" server-side designs/patterns emerged
Enterprise systems needed ways to connect with one another
Firewalls made "traditional" interop tools difficult
HTTP was easy to punch through firewalls
Enter SOAP, WSDL, and the WS-DeathStar
At the same time, the Internet itself changed
Alternative access devices appeared (mobile!)
These access devices had their own UI technologies
So "Web APIs" began to emerge
Characterized by "simplicity" and nominally "RESTful"
JSON or XML over HTTP
Link rot
No integrated or universal identity system
No redundancy (unless you build it yourself.
What if we need to do more than, say, peruse content?
Buy things, sell things, trade things
Examine data, manipulate data
And any other domain-related thing you can imagine
The Web is not HTML
The Web is not HTTP
The Web is not HTML + HTTP
It may have been any or all of these things, once...
... but it's a lot more than that now
"Architecture"
A set of predetermined answers to the questions that developers will ask
"Web"
On, around, near, or in the Internet, even if just a little
"Modern"
As in, not considered "legacy" for at least a year or two
One that avoids the Fallacies of Distributed Development
The network is reliable
Latency is zero
Bandwidth is infinite
The network is secure
Topology doesn't change
There is one administrator
Transport cost is zero
The network is homogeneous
One that avoids the Fallacies of Enterprise Development
New technology is always better than old technology
Enterprise systems are not “distributed systems”
Business logic can and should be centralized
Data, object or any other kind of model can be centralized
The system is monolithic
The system is finished
Vendors can make problems go away
Enterprise architecture is the same everywhere
Developers need only worry about development problems
Modifiable (extensible, evolvable)
Scalable
Performable (actual, perception)
Reliable (testable, monitorable, recoverable)
Composable
Securable
Interoperable
Discoverable (somewhat)
Internationalizable
It's a platform
You're building a platform on which you (and others) can build parts or all of a system of programs
Let's call it "platform-oriented development"
What is a "platform"?
Wikipedia: "A computing platform is, in the most general sense, whatever pre-existing environment a piece of software is designed to run within, obeying its constraints, and making use of its facilities. Typical platforms include a hardware architecture, an operating system (OS), and runtime libraries."
What is a "platform"?
"A software platform is a set of subsystems and interfaces that form a common infrastructure on top of which a set of related products are developed." (McGrath, M. 1995. Product Strategy for High-Technology Companies. Homewood, IL: Irwin.)
What is a "platform"?
It is a set of components, services or interfaces that are designed for developer consumption, built around a common infrastructure and designed specifically to be used by internal developers, external developers, or both, to create applications/tools/components of use to users.
Examples of platforms
Windows (Win16 API, Win32 API, COM, .NET, WinRT.
Salesforce.com
Many platforms are developer-based, because that's what developers know best
But platforms are not about PAAS, nor do they imply scale
Platforms are domain-centric and -focused
A single company may in fact offer several different platforms
... and a platform may (and often will. stretch across companies
Platforms may/will stretch across platforms
a company's financial services platform reaches to Windows, Mac, iOS, Android, ...
What is a "platform"?
a communication backplane
a set of data types/entities
one or more data storage environments
a shared execution context
an implicit or explicit versioning strategy
(usually) a shared security context
(usually) some level of data reporting/visualizing tools
additional features as necessary/desired
Yes: this is what developers consume, most of the time
No: the platform isn't always about developer infrastructure, but business-related domain elements
Maybe: the APIs are executed within a known context or envrionment, which may or may not be defined by APIs
POD implies high interoperability
HTTP clearly provides a great deal of that
But so do other communication approaches
It is, by definition, a SOA
But it doesn't have to correspond to any particular specifications
Nor does simply conforming to a SOA spec create a platform
In fact, it doesn't have to be a specification or standard
but it helps for interoperability reasons if it is
Why not? They're really an implementation detail
More importantly, they provide a common backbone for extension
Important choice, however: what is your gateway into the system?
It could be that your platform exposes an HTTP API...
... or you could use the messaging/event-bus as the entryway
Either way, consistency and interop is key
Or any *AAS (IAAS, PAAS, SAAS, etc.?
Truthfully, where the platform lives is partly an implementation decision
What infrastructure or platform provided is also implementation detail
Note: your platform is not the same as the platform provided by a PAAS
It's kind of all three
It depends on what you're trying to build
Functional concepts are important
Objects are a useful modeling tool
Resources are the heart of REST
Chances are, it's some combination of both
Leave implementation details hidden!
These are easily used in a Modern Web Architecture
CQRS/ES can easily expose state, but it approaches it differently
... which means the API is exposed differently and people call it differently
... or those differences are implementation details behind the interface/API
Mobile being the big one
But even within mobile, there's a serious spread of capabilities
HTML alone (and MVC on the server. is no longer sufficient
This is why you are building a platform!
But it's not the ONLY Modern Web Architecture
Plenty of others are, can, and will be
And if it turns out you need most of it, build a platform!
Who is this guy?
Architect, Engineering Manager/Leader, "force multiplier"
Principal -- Neward & Associates
http://www.newardassociates.com
Educative (http://educative.io) Author
Performance Management for Engineering Managers
Author
Professional F# 2.0 (w/Erickson, et al; Wrox, 2010)
Effective Enterprise Java (Addison-Wesley, 2004)
SSCLI Essentials (w/Stutz, et al; OReilly, 2003)
Server-Based Java Programming (Manning, 2000)