What's wrong with SOA being 'enterprisey'?

Enterprisey middleware may be just what we need to get the job done, says Anne Thomas Manes.

A new word has entered our lexicon: 'enterprisey,' which is being applied to SOA. Is this a word with positive or negative connotations? (Wikipedia defines it as a "derogatory" term.)

Tim Bray (Sun) agrees that being enterprisey is not a good thing, and recently made the charge that SOA/WS-splat is too "enterprisey," and a shift was taking place to the far simpler REST model.

Anne Thomas Manes (Burton Group), however, begs to differ. Recently, she spoke out against criticism of SOA and the WS-splat stack as being "enterprisey" with this retort:

"WS-* is entreprisey. But is that really such a bad thing? If you need comprehensive enterprise-class semantics (security, reliability, session management, transactions, etc), then it really helps to use an enterprisey middleware system."

While Manes acknowledges that with 60+ specs out there, WS-* can be complex to fathom, but toolkits should eventually handle most of that complexity. (Microsoft Indigo/WCF is one.) "Developers should really only need to be concerned with a handful of the specs: SOAP, WSDL, and XML Schema--maybe WS-MetadataExchange. Everything else should be handled transparently by the toolkits," she said.

Manes says WS-* is the best approach where robust middleware is required, but also adds that she doesn't recommend using WS-* for all service interactions, especially mass consumer-oriented services. "If an application doesn't require enterprisey infrastructure semantics, then it's much more appropriate to use a simpler middleware system, such as plain old XML (POX) over HTTP."

I concur that 'enterprisey' should not be a "derogatory" word. The very term 'enterprise' suggests a talent for marshalling people, resources and systems to provide products and services that the market demands. SOA promises to greatly streamline that capability.