Monday, February 9th, 2009
Much has been written concerning the need for a description language for REST based web services. Much of the writing has assumed that REST does not have a defined description language. Much of the discussion has revolved around REST’s proponents assertions that the request query parameters are the themselves the description. Some have also noted WADL as a possible solution.
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:
Concerning XForms:
Also interesting:
Monday, February 9th, 2009
From Linux Magazine:
http://www.linux-mag.com/id/7242
Microsoft is seeking a new open source director to help formulate a strategy against competitors (OSX, Linux).
They should have just adopted an open source kernel (prefereably the Linux kernel) for Vista. Imagine how that could have changed their future…
Tuesday, February 3rd, 2009
Great article here discussing the lack of mashups inside the enterprise, and comparisons of mashups to old-world spreadsheets as a tool of empowerment for the end user.
With or without the listed challenges resolved, we seem poised for rapid acceleration of mashups as REST APIs and “web sites as web services” concepts grow. A real goal should be to implement services inside the enterprise to foster internal mashups.
The 10 top challenges facing enterprise mashups
Wednesday, January 14th, 2009
In When to use Solaris vs. Linux: Operating system comparison, I’d agree with a lot of the points made, particularly the wrap-up:
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.
Tuesday, January 13th, 2009
This is a little esoteric, but I believe in it fully…
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
Wednesday, December 31st, 2008
Some links to reasonably comprehensive feature descriptions, pricing models, and philosophy for each of the offerings. A great starting point for an engineering trade study.
From MyTestBox.com:
Wednesday, December 31st, 2008
Some descriptions of games to add incentive to development team activity…We look to use a variation of these within createTank soon.
Monday, December 29th, 2008
In a long but good thread at the-enterprise-architecture-network Google group, Cliff makes an important point not often seen in EA discussion, that of the Architect’s responsibility to understand the interrelation between the business’ cash flow and the enterprise’s data flow.
Post in complete context here:
http://tinyurl.com/8qp4t4
Hi Biju, You are right that most EA frameworks are IT centric. That is a great failing.
It is interesting that if you talk to a typical business architect (typically trained in the IT camp), and ask for a model of the architecture of the business, they will show you a process flow diagram, showing the DATA flows.
But if you talk to a business person and ask for a model of the business, they will show you a spreadsheet that captures the CASH flows.
These are completely different.
This is the great disconnect between IT and business. And I claim that an EA should be able to explain each model, and inter-relate them.
- Cliff
On Dec 23, 9:58 am, “Biju Abraham” <abraham.b…@gmail.com> wrote:
> I agree that EA should not be IT centric..however if you look at the
> frameworks itself, they seem to be derived from technical level. eg.
> TOGAF… TOGAF is very descriptive at technology/information architecture
> level and not so at the higher levels.
>
…
Sunday, January 20th, 2008
In Can OSS Integration Server Software Enable EAI/BPM, Dennis Byron discusses whether open source software can compete in the integration server market.
Research has shown that often when cost is such an inhibitor, open source software (OSS) can help…On the other hand, everyone agrees that BPM/EAI/integration software is among the most complex software developed and offered in the market. Therefore—conventional wisdom says—it is no place for the OSS culture and development model…Conventional wisdom is wrong again.
createTank’s elemenope SOA framework is mentioned as one of the few FOSS competitors in the market area.
The elemenope framework is a classic integration server based on both OSS terms and conditions and OSS culture. It has been in development since 1999, almost since the start of the integration server era, and it has also enabled a service-oriented architecture (SOA) since before that term became popular.
Worth a read…
Can OSS Integration Server Software Enable EAI/BPM?
http://www.ebizq.net/hot_topics/open_source/features/8804.html
(Requires free subscription)
Wednesday, September 26th, 2007
eWeek serves up deception.
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).
