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)
Tuesday, September 4th, 2007
In Does SOA threaten developer jobs?, much is said about supposed concerns that developers now have over SOA adoption.
So, one might surmise that Jacquard Loom developers once felt insecure about the goings on in assembler and C development, and that C developers once lost sleep over OO and Java development.
More…
Wednesday, August 1st, 2007
XML processing in hardware to boil down an XML doc for simpler binding to objects:
http://tinyurl.com/2syl99
Most importantly:
“We use an object binding framework,” he explained. “We use XSLT to
transform it in hardware. So when the XML comes in, all the validation,
all the business rules that are applied to it, all the transformations are
done, so we get a clean XML that is exactly fitting the object that we
want. So we can make one Java call, say un-marshal, and we have the
object, lo and behold. We don’t have compiled classes. We have no mapping. Nothing.”
Tuesday, July 3rd, 2007
One of the first notations made in my notes from the ZapThink session (see Zapthink LZA Reviewed) was a subtle disagreement about the relationship between Architecture and Technology. ZapThink asserts that “Architecture is not about technology.” They paraphrase “physical”* architects stating that buildings are and should be designed “for the space.”
What the Classics Say
While this is not untrue, a review of classic architectural writings reveals a fuller and more enlightened perspective. In point of fact, Architecture is about the spaces and the structure and the foundation. Physical Architecture does in fact concern itself in no small manner with the structure and foundation of the building. Without a solid and proper foundation, even the best and most suitable “spaces-based” Architecture will fail. The spaces based viewpoint might come from the fact that in the world of physical Architecture, structures and foundations are usually a known quantity, as a great deal of experience has been recorded over the past few thousand years. However, whenever a new material or technology is introduced, inherent unknowns often produce failure. With this failure and its study comes further understanding.
More…
Friday, June 15th, 2007
Interesting concept: REST, XForms, XQuery, and “skimming” –
Pattern of holding data on the server in a native XML database, and offloading all translation and processing to the client.
See: REST, XForms, XQuery, and “skimming”
More…
Thursday, May 24th, 2007
ZapThink launched LZA (Licensed ZapThink Architect) Boot Camps in early 2007 to provide a SOA credential and matched training. The Boot Camps were intended to provide both a common, objective understanding of SOA to practicing Enterprise Architects and the chance to obtain a credential from a qualified and respected third party (ZapThink).
createTank Attends…
More…
Sunday, May 20th, 2007
Many SOA advocates refer to the implementation of SOA as “wrap and replace” rather than “Rip and Replace.” createTank has determined through experience that a more refined description might sometimes be helpful — that of “wrap and replace ‘the squeaky wheel.’” This description is usually more acceptable to developers and management alike, as it highlights the possibility that a great deal of legacy code may not need to be rewritten at all (or at least not immediately).
More…
