x Take the InfoQ Survey !

Interview: Frank Cohen on FastSOA

by Stefan Tilkov on Apr 05, 2007 |

InfoQ today publishes a one-chapter excerpt from Frank Cohen's book "FastSOA". On this occasion, InfoQ had a chance to talk to Frank Cohen, creator of the FastSOA methodology, about the issues when trying to process XML messages, scalability, using XQuery in the middle tier, and document-object-relational-mapping.

Frank has taken care to answer our questions in great detail; be sure to read the full interview and download the sample chapter.

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

DataPower by Jason Lenhart

FastSOA appears to be more of a software solution to many of the problem domains solved by DataPower.

Re: DataPower by Frank Cohen

Hi Jason: The patterns are platform agnostic, but they do require a persistence engine. As far as I know IBM's DataPower appliances give you the transformation and security decription capability. I did not see a persistence engine to let you do things like intelligent caching, transformation, and federation in the appliance. Did I get that wrong? -Frank

Native XML DB? by Jeff Highman

Are you using (in your metrics) the XML database?

I would expect that for a fixed data set (where the message itself had a high correlation to the physical storage) this would be more efficient. For a message that has customer, order, payment, and product to represent and "purchase order service" I would expect each entity to be persisted in a relational way so that another service might be “customer details” and another to be “product details”. I would expect the performance to go down as you had more needs to aggregate data from the XML DB. I am guessing that as the more aggregation was needed, the less a hierarchical db would be more efficient than an object relational solution.

XML is a hierarchical, so I presume that Native XML DB would also be persist hierarchical, but most apps have a need to store things in a relational database because of the relational nature of the information. While the transformations are a cost, shouldn’t this cost be compared on an aggregate level?

I have not worked with any XML databases so I was just wondering about the efficiencies of using them.

Re: Native XML DB? by Frank Cohen

Hi Jeff: Native XML databases are typically hierarchical in the way they store data and multi-dimensional in the each stored XML document have a different hierarchy. This is different from object databases where you truly didn't know exactly what you would be storing and querying ahead of time. Native XML databases now have the XQuery and XPath query syntax to work with the stored documents. Most of the XML DBs also have an indexing engine that uses one or more schemas to determine the correct approach to indexing the contents of a collection (the XML DB version of a row-set.) In my performance and scalability testing I find that native XML databases usually achieve 5x to 30x performance increase over using similar XML techniques on a relational DB.


Re: Native XML DB? by Jeff Highman

Thanks Frank, that's a pretty profound improvement. Looking forward to to reading FAST SOA.

How would you compare the FastSOA approach to NetKernel? by Mircea Cocosila

Hi Frank: It seems that NetKernel - - already addresses the problems FastSOA addresses. NetKernel also provides an uniform programming model using the resource oriented paradigm. How would you compare your approach to NetKernel?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

6 Discuss
General Feedback
Marketing and all content copyright © 2006-2015 C4Media Inc. hosted at Contegix, the best ISP we've ever worked with.
Privacy policy