The HTML Form is The Answer

I assert that REST already has a full web service description language built into it in the HTML Form.  In the most normal of cases, that of human web browsing itself, the HTML Form is already used in a manner declaring the exact parameters to be passed and matching the parameter to its user defined, dynamic value.  The HTML Form provides a standardized format to the definition of what query parameters are required for a given service.  For though the query parameters may be said to be self descriptive (REST proponents typically assert this, and SOAP advocates cite this as an argument against REST), without an HTML Form, a user or client will have no prior insight into the full set of parameters required or optional to invoke the service.  The HTML Form as RESTful service descriptor adheres to the text of the Fielding REST definition itself, where hyperlinks provide the “engine of application state.”  The HTML Form action parameter provides the hyperlink required to direct the transfer of state from the client to the service.

As for the common desire to automatically generate a service from a given HTML Form, taken as a web service description, we should look no further than the myriad of CGI languages and frameworks available, from Perl to C to Java to .NET to Struts and more, all of which provide to the developer a simple key/value pair for everything passed in the request.

WADL is Not the Solution

Why don’t I see WADL as a solution?  Because it assumes that the typical SOAP implementation of code/class generation and the corresponding marshalling and unmarshalling is what is wanted or needed.  I would assert that the reason that the number of RESTful web services implementations is growing and the reason that the web itself has been so successful is that RESTful services (or web pages themselves) are very simple and very scalable.  Simple in a way that WSDL, WADL, or any other heavy description language will never be.  Scalable by default in a way for which SOAP implementations must intentionally strive.

XForms

What about XML payloads then?  Well, you could of course declare an XML type for a parameter in an HTML Form, but that would not really meet the expectations of those that will otherwise develop SOAP based enterprise services, desiring a strongly typed description language.  The solution as it turns out is the successor to the HTML Form, XForms.  XForms provides a full MVC approach to web application or web service description.  An XForm can be represented as a simple HTML Form, or may take on much more complex capabilities, such as defining specific XML parameter types and sending XML directly to the server.  In this manner, XForms may be transformed to provide a human readable interface to a service, or may also be read by a machine in raw XML form to determine proper parameters and service location.

Concerning REST service descriptions:

• Debate: Does REST Need a Description Language?
  
• REST Service Description Conventions (RSDC)
• A discussion of the use of WSDL 2.0 to describe REST web services
• Describe REST Web services with WSDL 2.0
• Does REST need a service description language? – [asserts that a WSDL like language is not needed for REST]
• WADL REST API description language getting some attention
• Representational State Transfer (REST) Architectural Style

Concerning XForms:

• W3C Forms Working Group
• XForms FAQ
• XForms Essentials
• XForms Tutorial

Also interesting:

• XForms as part of the XRX Application Architecture  [Forms on the client, REST interfaces and XQuery on the server]

While I applaud Sun for getting on the bandwagon, and while it is true that imitation is the best form of flattery, I’m not sure if Sun might be a little too late to the dance. Linux just has too much momentum today, and trying to re invent Unix this way seems like a long-shot. Linux today is a real enterprise solution, used by almost all of corporate America, and the only OS that is actually growing in sales. On the one hand, while it is the hope of open system aficionados everywhere that this Sun venture succeeds, I’m not certain that as a company, Sun would have been smarter to stay with pure Solaris and their SPARC-based architecture and played to their strengths. This is what IBM has done around their System p architecture and it has served them very well in recent years. At the end of the day, you are what you are. I’m not certain that Sun really knows where they are today.

In my opinion, Sun’s objective has generally been to get or stay in various markets by competing with Linux as a presumably valuable open source option. This has led to a seeming corporate schizophrenia at Sun, with separate and aided missions to also sell proprietary hardware and a proprietary UNIX.  Sun has provided many great open products, yet has a lot of trouble relinquishing control. Only recently have they decided that they loved Java and Solaris enough to really set them free. They would probably be better off making OpenSolaris interoperable with Linux by kernel and user space contribution. If Sun were to concentrate on providing better tools for Linux, we’d probably see a value added advantage for Sun, placing it in a good position for the future — If.

If you absolutely have to run Solaris I’d recommend OpenSolaris. Otherwise and always, I’d recommend Linux (which distro would be up for debate), as Linux is the agile answer. Linux is the answer that you will wish you had made in years to come, as everything will run on it, and it will run on everything. Efficiency and optimization should not come into play, as next month’s hardware will outpace tenfold the few and minor empirical differences in efficiency that can be argued for Solaris over Linux.

In Vitruvius’ Ten Book on Architecture, Chapter 1, The Education of the Architect, Vitruvius calls for a wide foundation of knowledge for the architect, including art, math, history, philosophy, music, and medicine.  That a good architect should strive for a breadth of applicable knowledge.

He also points out the usefulness of understanding the nature of practice and theory in all of these subjects, that a balance should be maintained.

2. It follows, therefore, that architects who have aimed at acquiring manual skill without scholarship have never been able to reach a position of authority to correspond to their pains, while those who relied only upon theories and scholarship were obviously hunting the shadow, not the substance. But those who have a thorough knowledge of both, like men armed at all points, have the sooner attained their object and carried authority with them.

I would argue that the same logic is very well applied to our occupation today, in that over-specialization is not particularly suited to success.  That is, EA practitioners are IMHO better as generalists, with a breadth of knowledge, both technical, and non-technical.

For my part, I typically look for experience and success in the following areas:

• business (corporate and entrepreneurial)
• software development (multiple languages and types [OO, functional])
• systems administration
• creativity and problem solving skills
  
• engineering
  
• open source
• open standards
• development methodology
  
• Unix/Linux
  
• marketing
• writing
• speaking/presenting
• more…
  

In the real world, I see too many architects relying upon theory alone (hunting the shadow as it were), create problems for themselves and their teams.  For this reason, I’m a big fan of the people at CodingTheArchitecture.

Ten Books on Architecture from Project Gutenberg:
http://www.gutenberg.org/files/20239/20239-h/29239-h.htm

Originally Posted by john joseph roets at the-enterprise-architecture-network Google group, an example of reuse in writing.

Post in complete context here:
http://tinyurl.com/a8w5tk

• The Development Game (Dr. Dobbs)
• The Continuous Integration Build Game (JDJ)
• The Continuous Integration Build Game Hudson Plugin

MS wants to downplay US developer/IT quality to make the case that they need more H1B workers, in order to:
1. Bring in workers of dubious quality
2. (And the real reason) to lower the market rate on US developer/IT workers.

The same holds true on MS arguments on security clearance requirements for US Govt. work (MS is against).