Copia

I found out today that not only is the Linking Enterprise Book now available but it is also freely available online as well as in other avenues (Springer and pre-order on Amazon):

Linking Enterprise Data is the application of Semantic Web architecture principles to real-world information management issues faced by commercial, not-for-profit and government enterprises.This book aims to provide practical approaches to addressing common information management issues by the application of Semantic Web and Linked Data research to production environments.

I wrote a chapter ("A Role for Semantic Web Technologies in Patient Record Data Collection") discussing the debate around SOAP-based web services and Representational State Transfer (REST) that focuses on a specific, deployed use case that emphasizes the role of the Semantic Web, a simple Web application architecture that leverages the use of declarative XML processing, and the needs of a workflow system for patient record data collection.  It touches just a bit some of the use of XForms to manage patient record content as special-purpose XML dialects for RDF graphs that I mentioned in my last post but is mostly focused on how to use RDF to manage workflow state to orchestrate data collection of patient data.

Business Process Management Systems (BPMS) are a component of the stack of Web standards that comprise Service Oriented Architecture (SOA). Such systems are representative of the architectural framework of modern information systems built in an enterprise intranet and are in contrast to systems built for deployment on the larger World Wide Web. The REST architectural style is an emerging style for building loosely coupled systems based purely on the native HTTP protocol. It is a coordinated set of architectural constraints with a goal to minimize latency, maxi- mize the independence and scalability of distributed components, and facilitate the use of intermediary processors. Within the development community for distributed, Web-based systems, there has been a debate regarding the merits of both approaches. In some cases, there are legitimate concerns about the differences in both architec- tural styles. In other cases, the contention seems to be based on concerns that are marginal at best. 

In this chapter, we will attempt to contribute to this debate by focusing on a specific, deployed use case that emphasizes the role of the Semantic Web, a simple Web application architecture that leverages the use of declarative XML processing, and the needs of a workflow system. The use case involves orchestrating a work process associated with the data entry of structured patient record content into a research registry at the Cleveland Clinic’s Clinical Investigation department in the Heart and Vascular Institute

So here's Infoworld's daily nugget of wisdom, poised over the provocation: "Should you fire your enterprise architect in 2007? Take the test."

The largest and most disturbing issue ... is the fact that there seems to be a huge chasm between the traditional enterprise architecture crowd, and those looking at the value of SOA. Indeed, enterprise architecture, as a notion, has morphed from an approach for the betterment of corporate IT to a management practice, at least for some. Thus, the person that is needed to understand and implement the value of SOA is sometimes not the current enterprise architect in charge. -- David Linthicum.

So the SOA wars are heating up. More and more smart people are pointing out that the emperor has no clothes; but stakes is still crazy high. Some folks haven't yet made all their money from SOA. So how do the stakeholders respond? With cold-blooded threats.

"So your architect isn't all bought into SOA, eh? Well fire him, dammit."

And oh, isn't it delicious irony that this dude is claiming it's the experienced architects cautious on SOA who are establishing a pet management practice within IT. Oh, there's no way the SOA sellers could be guilty of that. Noooo. Never. Never. Never. Neeeever!

[Uche Ogbuji]

Contract-First XML Web Service Design is No Panacea

Dare Obasanjo has had a lot of good comments lately on the whole REST/Web Services thing, and here he argues against claims that writing the interface definition first (the "contract") is the key to getting Web services right. I first heard this thinking that WSDL-first is the magic from Tony Hong years ago at one of the old SOAP interoperability derbies. I'd figured this was actually written into the WS stone tablets somewhere.

Dare dwells on the mismatch between WXS schema types and programming platforms, and gets at topics I discussed in "XML class warfare" and "The worry about program wizards" [both Application Development Trends], as well as other outlets. I think the mismatch alone isn't a problem: all modeling involves approximation. The problem is that people want it all to work without leaving the safety of their wizards, and I'm sorry for managers who don't like the smell of engineers, but all modeling also requires expertise. Wizards save some time cosmetically in the cheapest phase of development (implementation) just to charge very usurious interest on that savings throughout all the other phases. Customer problems such as Dare mentions are classic surfeit of the poisoned Kool-Aid, dating back to the 4GL heyday.

Model-first is still the key to solving such problems, I think. WXS and WSDL are too low-level to qualify. The model uses a specification language that expresses the solution in terms that are both formal, and close to the conception of the problem space. That takes collaboration between the subject matter experts and modeling experts during analysis and high-level design. It then requires further effort from a modeling expert to define the mappings between the model and artifacts of th eprogramming environment such as IDL, WSDL and WXS during the low-level design, which flows into implementation. No need for waterfalls or analysis-paralysis: these can all be rapid, iterative steps. But you can't just make a magic leap to low-level problem solving and expect not to pay the penalty in maintenance. This is the oldest advice in software engineering. It's amazing how few pay it the slightest attention.

[Uche Ogbuji]

Ironically, at the time when this thread started I was looking for some good reference material on the common arguments against the usefulnenss of WebServices and suggested alternatives to the mainstream architectures (SOAP and WSDL).

• SOAP 1.1 Specification
• REST Specification

[Uche Ogbuji]