ACORD is a Guideline NOT a Standard

Apologies to my readers who are not in the insurance industry and do not care about the ACORD XML "Standard". I have gabbed a lot about it lately. Perhaps this applies to other "industry standard" xml efforts. I know that it also applies to my experience with OAGIS. I also recently posted on canonical message format as well (related). I hope that this post and the comments that may ensue will put this topic to bed for a while.

While at the ACORD conference last week in Las Vegas, I challenged myself to interrogate every vendor, carrier, and ACORD employee on whether ACORD is a standard or a guideline.

To a person the consensus was that it is a guideline.

Perhaps I am just a stickler for words, but this really bothers me. I listened to executive after executive and industry analysts yapping and banging drums about "standards" and how everything is just great in the insurance world on the wire. I listened to the Gartner insurance dude spaz out about ACORD "standards" and then recommend that carriers fork it (excuse me, use ACORD as a guideline) in one sentence. The insurance analyst panel (Gartner, TowerGrouup, Celent - liked their guy Matthew Josefowicz the most)) was pretty comical - one of the more arrogant groups I have seen. Sniping at each other, challenging each other to dare to question the standards -- saying things like, "the standards have never been as close as they are today ...". They certainly all know more then I do about the insurance business, but someone needs to remind them that their PowerPoint presentations don't compile. They should take a look beneath the covers of a couple SOA projects and check to see what is really on the wire.

I talked to several aggregators and AMS reps who said that in their eyes ACORD is at best a guideline. They did say that since carrier xml is often ACORD-like and at least has some similarities, it makes things better then if everyone started from scratch. I can buy that - but that isn't standard.

I listened to a presentation from a reinsurance intermediary (Guy Carpenter) on an event driven impl. They forked the ACORD standard and have no regrets. By the way that was the best presentation of the show (even though it was called "Using ACORD XML Standards to Build Enterprise SOA"). I have a feeling that the presenter, Paul Fox didn't name it that.

I challenged some CIO level folks who were talking the standards bit. They quickly folded and agreed with me.

What bothered me the most about the ACORD conference was that there was no serious discussion about the realities of ACORD XML in practice today - no sessions, no critical thinking - zip. Everyone just seemed to wink and nod and say nice things about standards. Also, zero talk about 2.0.. Perhaps I just wasn’t in the right sessions.

Every sane person I spoke with is following the prune strategy accepted in 2.0.

I still believe that it is appropriate to use the ACORD guideline as an starting point for a insurance entity's canonical form - provided it is aggressively pruned and there is no requirement to keep up with future versions of the ACORD guideline. Most importantly, don't spread the illusion that your canonical form is "standard" -- that there will be some magic interop some day. There will not. This is ok. Owning your canonical form outright is far more important then conforming to a standard that doesn't really exist.

ACORD Conference - lots of vendor-pires & some that get it

Wow, lots of vendor-pires large and small here.

I had dinner last night with some folks from Skywire Software - we use one of their products, Insbridge.

What I like most about them is that they aren't a vendor-pires and aren't trying to be. They are SOA based and stay out of your way. I wish there were more vendors like this - that just offered service based software.

Instead, every vendor seems to want to invade your whole stack. I met with a couple of these vendors yesterday and told them straight - "I would never buy this - it will lock me in and make me miserable". Most of these vendors have crazy GUIs and scary proprietary scripties that are intended to make your life easier. "Easier" sadly also = lock in and esoteric skills that few developers want to acquire.

IMHO, SOA strategies that rely on lots of extensive clickie tool support are doomed to failure. Or at least lots of bites from various vendor-pires. I'm all for tool support - just not invasive tool support. As long as the tool isn't generating files with weird file extensions and isn't required to build a service, you are probably ok.

Insbridge. does have a clicky tool, but the way you call it at runtime is via a service. So the clicky is useful and contained - that works for me.

Update 17-JUL-06 - Now that it is possible to determine my employer by reviewing my blog posts, I must follow my employer's blog policy.

This is not an endorsement by Liberty Mutual, but my personal view. Vendors are NOT free to quote with attribution.

ACORD Conference

I, standards basher, am at the ACORD LOMA Insurance Systems Forum in Las Vegas.

The conference really starts tomorrow. I went to a technology forum run by insurance agents. It was fairly interesting. I have gone to several agencies and watched these people work. As the saying goes, "they don't call them independent agents for nothing". They all do business differently, use different tools (agency management systems (or none at all), aggregators, etc.), yet they want everything integrated and simple. Makes my life fun, what can I say.

At the agency technology forum, the word "standard" was tossed out there quite a bit. I kept muttering to myself, "what version?", "who's extensions"?

I had an interesting conversation with one of our aggregators in the conference hall. An aggregator is used by insurance agencies to do comparative rating. Basically, they just type in an insured's info once and click one button and get back rate quotes from N carriers (think Travelocity with airline tickets). If anyone should be benefiting from the industry standards that we all say have such a high payback with no questions asked, it should definitely be him. Guess what he told me? Every carrier that his system integrates with uses dramatically different XML on the wire. There is no "standard" XML that they send to each carrier.

Now I found that pretty funny.

He did say that it is nice because each carrier's XML has some resemblance, but then conceded, with some prodding, that the whole thing is b.s.

Anyway, I still hold out a slim bit of hope for Acord 2.0, but time will tell.

Don't get me wrong on standards - I think they are fine. I just get miffed when people blindly cite them as a panacea when I know under the hood what is going on isn't standard. I think we might get there someday with Acord XML - it just is going to take a long time IMHO.

EDA Lessons Learned - Performance

See EDA Lessons Learned for the list

For starters, specify a requirement or two on what acceptable performance is. Then, start measuring early. Better to know that you are way off the mark early on IMHO. Fixing services that are way too slow late in development or once they are in production often means rewriting the service from scratch in my experience (of course you still call it refactoring in meetings to make everyone feel better ;) ).

I have seen the most performance problems with Persistence.

Another thing to focus on early is how your services will scale. Our system resembles SEDA (Staged Event-Driven Architecture).

• Thread Safe - in our system that is built on top of JMS at the core, we use a JMS ServerSessionPool impl that makes adding threads (sessions) to a service configurable. This is a great way to scale and throttle a service. Sadly, we deal with some obscure stuff that isn't multithreaded - so we have to configure just one thread. For most services, however, you can have 10+ threads waiting to process events
• Competing Consumers & Shared Subscriptions - Anyone familiar with JMS understands competing consumers with Queues. We use SonicMQ, which, also offers this concept with Topics. We use these heavily. It is great because you can spread processing across machines. You can have 1 logical service running on N machines. When it is flooded with events, the processing is evenly distributed across the logical instances of the service.

Another area to focus on from the start is service granularity (the black art of SOA/EDA) - this is a lot harder to get right then a lot of people think. Especially when you are dealing with many services. Its like anything of sufficient complexity - there are 3-5 ways to do it right and 50 ways to do it wrong - pick one of the right ways.

Last thing I'll mention is async processing. This is huge in an EDA system - basically everything is async. But some developer's little minds don't like async and want to make it sync. You must find these people early and get them off the project. Just kidding (kinda). We had a couple problems with performance like this. Our login for instance was a dog at one point. This was because it was sync and the granularity of service calls was awful. So we "refactored" (where "refactor" means tore out old code and stomped on it and called it names, then wrote it again from scratch). We rewrote it in a way that was async. When a user logs in, an event is generated that the system responds to. Immediately after the login event is produced the first page of the UI is displayed. Other events in the backend are produced that the UI is interested in. So it listens for these events. The key is with the rewrite, we don't make that process sync. When the events the UI needs are produced, the UI receives them async.

EDA Lessons Learned - Scaffolding

See EDA Lessons Learned for the list

Scaffolding is useful all over the place in software. EDA and SOA really can benefit from it.

Scaffolding is especially useful in large new development efforts. Services reach code complete at different times. You are totally hamstrung if you wait until all services are complete to start testing. The scaffolding (i.e., mock services) can be used to simulate the services that are still in development.

Once developed, scaffolding can be useful when a service that is not available. If you don't have scaffolding, development and testing can grind to a halt while you wait for the service to come back up.

Scaffolding certainly doesn't come for free - you have to develop it like any other service & it can be every bit as complex as the real service. Its often worth the investment though. You don't need a scaffolding impl for every service you write. Mock services are particularly helpful for services that wrap a volatile resource or a service that is outside of your control (e.g., different org. that has a different development schedule).

A SOA or EDA that provides good location transparency makes swapping in/out scaffolding easier. For our EDA style system we just disable the real service and enable the mock service. The mock service subscribes to the same JMS Destinations, and produces the same event types. This is great because you don't have to modify anything on the clients to swap in the scaffolding. You can achieve the same thing with UDDI or RSS - I do really like the EDA style though - when you are working in an event cloud you get extreme decoupling which rocks.

SOAP vs. REST Pointless?

Steve Jones thinks that SOAP vs. REST is pointless. I assume from his post that he thinks that POX is pointless too.

I can understand that opinion. I think everyone in IT integration is frustrated that every wave that comes by that promises to give us massive reuse fails.

The good news is that IMHO services are here to stay. At the very least, they will get a fair shake. Especially with success stories like this from Amazon.

Regardless if Steve thinks the arguments are pointless or not, the WS-* standards aren't there yet. And SOAP really doesn't buy you all that much out of the box. Sure maybe if all the higher level standards amount to something it might, but I'm not holding my breath.

I think that dissent is important.

Steve argues as Anne Thomas Manes does that the tools will save us. He even cites XDoclet as an example. Funny that I use that as an example on why tools are not the answer.

Like I said, the good news is that services are here to stay. How about we just go back to the drawing board on some of the things that are broken instead of slogging on with the 60+ specs? I don't see that happening. There are too many vendor-pires too heavily invested at this point.

The only answer is enough simple OSS rebel frameworks and hopefully enlightened vendors that treat POX, REST, and whatever innovative ideas come next as first class citizens. The truth is there is massive premature standardization occurring. We might get there some day, but you can't just beat people into submission. IT Integration isn't the commodity that Steve describes. At least not where I work.

A big complaint I have against drinking the SOAP/WS-* Kool-Aid is I haven't seen any real success stories on following the WS-* approach with heavy integration. There are many around SOA, but strangely the specifics of what is on the wire are often left out. Admittedly I may be missing these - please let me know if you know of any.

In general I think that the concepts of SOA and EDA are what are really important today. If you can break things down at the proper level of granularity and use whatever you want on the wire (try a couple!), you will be fine in the end. People including me in the past do a lot of hand waving about standards, service contracts, tool support and what not which are important - there just not as important as you think - at least today.

Brighter Sun

Good to hear via James Governor that things are looking up for Sun.

I have largely made my living off of Sun's innovation (Java) for the past 10 years.

It has bugged me that they haven't open sourced Java, but sounds like they have decided to do so now eventually.

And sounds like Jonathan Schwartz is bringing a much needed new direction to the company.

I think that we all had enough of the negative Sun - I'm looking forward to a brighter Sun (impressive come back - you just have to love OSS).

Service Contracts = Hall of Mirrors

Nice post on service versioning by Dare Obasanjo. He refers to posts by Tim Ewald extensively.

I generally agree with their conclusions. Sadly, it demonstrates that "design by contract" with web services really is a hall of mirrors.

I beat the "contract first" drum as loud as anyone. The truth is, however, at runtime, the true contract between my services is very loose. This is due to lots of things - complexity of WSDL (I try to avoid at all costs), over engineering of XSD, industry standard schemas, etc.

Tool support / code gen from XSD used to be important to me. I came to services via CORBA and was enamored with the whole IDL thing. IDL in CORBA was much simpler - just basic C structs etc. It generally worked, but was certainly not without its problems. So when I first started writing web services in 2002, I dedicated myself to making WSDL an IDL (i.e., contract first). As I've said in various parts of this blog, that was a very painful experience.

I moved on from web services to just dealing with services that use XML on the wire. That XML has always been backed by XSD. As Dare and Tim recommend, the contracts are very loose.

Until recently, I have been ardently pro tool support with this (i.e., just simple XSD) approach. You can get any tool to work when you dumb things down (e.g., .NET xsd.exe, JAXB, Castor, XMLBeans). I always put the generated classes in some package like "msgmapper". I then write some helper classes that serve as a level of indirection to the generated classes.

I used to think it was pure unadulterated evil to generate XML by hand via JDOM, Xerces, etc. Now, I almost prefer that approach. Maybe I am just getting tired. Maybe I am taking the simplicity thing too far. Its just that all the tools come with baggage. You have to run them in the build, they spew out thousands of classes, developers forget to isolate them and they bleed deep into your code (and are hard to extract) etc. With the brute force approach, you go to the "msgmapper" package and there is your code that generates your XML - no fuss, no muss.

More and more I think that any tool that generates code (at least for high level languages like Java & C#) is to be avoided at all costs.

So are contracts important? Of course they are. The thing is the devil is in the details & there is no tool that is going to just give it to you or even make it easy. IMHO contracts are more of an art then a science.

Stonefly Hatch

I am anxiously looking forward to a fly fishing trip I have coming up on Oregon's famous Deschutes river. Some friends and I are trying to time the stonefly hatch perfectly. It is a very famous hatch. Trout go nuts for these huge orange bugs. The stoneflys (orange and the size of your thumb) crawl out on reeds and alder branches along the river. The wind blows them in. The soneflys flap their wings furiously to get out. The trout hammer them. It is a very brief hatch. It is tough to time it right.

The Deschutes is my favorite place to go. I totally zone out and don't care about anything else while I'm there. It is a "blue ribbon" (i.e., kick butt) fishery. The trout in the Deschutes are called "Redsides". They are legendary for their size and fighting ability. They are wild trout that have been there forever. The Deschutes is a big western river. Strong current all year long. Makes the trout strong.

I used to wet a fly at least every other weekend. Since I had a baby a year ago, I don't get out as much anymore.

What does this have to do with EDA, SOA, or ESBs? Nothing - I'm spent. I have been travelling a lot lately. Man that sucks the life out of you. I used to travel almost every week for 5 years. Now I thankfully usually only do it once or twice a quarter.

Anyway, I'll take some pictures.

Temporary MOM bigot

I'm currently a MOM bigot, but only because I haven't seen another viable way to do extensive service oriented integration today.

I yapped about Message-Centric vs. Service-Centric a month or so ago.

I heard that SOA Software acquired Blue Titan this week. This is an interesting development. Here is a good post on why this happened (via Stefan Tilkov).

As I tried to get going on the Yahoo REST message board and in various posts in this blog, this is where I'd like to see things go. Leverage HTTP, but add:

• guaranteed delivery
• durable destinations
• event driven support (i.e., pub/sub)

It is ok to support SOAP, WS-* for the true believers, but do not mandate it. If anything, tolerate SOAP/WS-*, but prefer POX and REST. I wouldn't buy something that preferred SOAP/WS-* and had an extension or subset of support for POX and REST.

Now, I have no idea if Blue Titan even does this (I haven't used it) - it sounds like it does some of this or will. Anyone worked with it?

Ideally, I'd like to see OSS impls or at least dual licensing of this type of thing. This type of infrastructure is too critical to rely on a small vendor for. I can't afford another vendor-pire.

EDA Lessons Learned - Content Based Routing

See EDA Lessons Learned for the list

I have found Content Based Routing (CBR) to be helpful in EDA when a sink receives events, processes them, and then produces a subsequent event.

I like CBR because it pulls the routing logic out of the code. The code just processes an XML input and builds an XML output. It does not set the next Topic explicitly. The routing is controlled in the configuration of the sink. This keeps the code simple and reduces coupling. You can also change the routing without changing the code.

We had success using XPath to determine the next Topic. You can use anything in the XML output as part of the next destination. Or you can have several XPath statements building up the next destination based on attributes/elements in the XML. Examples include event type and event status.

I found an article from IBM from way back in 2000 advocating this approach: Using the JMS API and XML in content-based routing. Glad to see I'm so ahead of the times ;)

Spitting up the J2EE Hippo - now what about WS-*?

Richard Monson-Haefel continues to take the gloves off on J2EE and WS-* (at least the Java WS-* impls). I might not be reading closely enough, but I wish his firm, Burton Group would do the same on WS-* (I'm a customer). He and Burton Group have been consistent on J2EE, but Richard's boss Anne Thomas Manes continues to beat the WS-* drum. I read a couple of her pieces on a plane this week and she has totally drunk the WS-* Kool-Aid. She isn't a total zealot on it or anything, but she is astonishingly pro WS-* in the face of a lot of criticism and lack of success stories in the field. To be fair, it is possible that I just haven't found the right research. Richard - are you (or have you already and I missed it) going to take the gloves off on WS-* in your Burton Group writings? I love your blog, but it only makes a real difference if it is in the official Burton Group position papers.

Also, if J2EE is on the ropes today, who is to say that WS-* won't be in a couple of years? Given its trajectory compared to where J2EE was in the beginning, I think it is quite possible that WS-* will die a much quicker death then J2EE.

Update 08-May-06

To clarify, I thought that Anne's research was very thorough in terms of coverage - it was quite useful. I just was disturbed that given the history on things like J2EE she so easily assumed that WS-* will survive and thrive. Perhaps its her job to be hopeful like that and to try to get momentum going in one direction. My focus is solving integration problems today and in the not so distant future. Perhaps our requirements are different.

Update 13-May-06

I found some interesting links to Anne's response:
James Governor
Mark Nottingham - (he used to chair the WS-Addressing WG at W3C)
Dave Johnson

EDA Lessons Learned - Canonical Message Format

See EDA Lessons Learned for the list

I posted about Canonical Message Format a little over a year ago. I still agree with most of what I said then.

I have been exposed more to the Acord insurance standard since then. Sounds like Acord is addressing a lot of my complaints in the 2.0 version. Main quote that caught my eye is:

V2 will be delivered with an option to "slice" or prune the schema down into smaller files with the message content of your choosing.

That says a lot on how "standard" the XML really is on the wire in the insurance industry. This is essentially admitting defeat IMHO. Nothing wrong with it - just facing reality. The truth is that every carrier has differences - you make a valiant attempt to map to the standard, but you still have 20% more to go. There is an extension mechanism to account for this.

The trouble I have with industry standards like Acord is that if you follow them without pruning the original schema and making it your own (i.e., owning your contract), you have a very loose contract between services.

I'm all for using the industry standard for integrating with third parties. I think it is ok to use internally too, but it makes me nervous. People tend to toss the "standard" term around and act like the fact that it is being used as the canonical message format means something major - as if you are going to get a huge payback for it. I have never seen anyone get a big payback from any XML industry standard. And it takes a lot of effort to follow the standard. New versions come, the company has extensions, etc. At some point, people throw in the towel and have something that looks like the standard, but the chances of it resulting in any sort of out of the box interop with anything are nil.

So I think its mostly about setting expectations ... it is ok to use an industry standard as your canonical message format. I think it is wise to go into it with the "prune" strategy. Just use the standard as a reference. Don't event attempt to use the standards schema files. Just lift the structures. And dumb it down as much as you can to make it a tight contract. You will stray from the standard eventually - better to just admit defeat going into it IMHO. No shame in that.

Here are some more thoughts:

1. Avoid request/response designation in your root elements.

   EDA is not sync - don't act like it is. Even if you have some workflow that is sync, don't bake it into the messaging model - it will likely change over time. The request/response in the XML will just confuse people.

2. If using XML schema, keep it simple - avoid the fancy stuff
3. Question elaborate tools that make managing your canonical message format easier

   These tools often make it easier for you to make things more complex then they need to be and lock you in. They typically require training - so only a couple people know how to use it (single threaded through them). Your canonical message format should be simple & should only require something like XML Spy, source control, and a web site for easy reference.

EDA Lessons Learned - EDA and Object Oriented Design

See EDA Lessons Learned for the list

Event producers and event sinks are very often services written in an Object Oriented language. All the same OO rules apply. OO Design Patterns are still applicable.

This is a pretty minor point, but I have seen a lot of people throw this stuff out the window with EDA/SOA.

In my opinion, services (i.e., event producers & sinks) should have good separation of:

• service handler (should have minimal code - just delegates to message mapping and business logic)
• message mapping (e.g., O/X)
• business logic
• domain model
• data access layer

An aside I'll add is that the Spring Framework also works just fine for Java based services. I only mention it because I have found that its usage tends to have a positive affect on the OO design of services.