I work for an insurance company and we're getting ready to use a new vendor tool for creating insurance illustrations. The tool has a web service that accepts an ACORD XML message. We want to put a web service in front of the vendor web service to abstract it away, but the complexity of the data model makes it hard.

Our first method on the custom web service will probably just pass through an ACORD XML message to the vendor service and return the result. But, I'd like to have methods on our service that are more succinct. I'm not sure if that is possible yet as we're still doing analysis. Is there a way to create simpler data models for ACORD? The ACORD message is a TXLife 111.

Edit: We are a mixed shop with .NET and Java, so I need to consider that Java clients might, at some point, be requesting illustrations through our .NET web service.

  • The web service is just an available interface. Building the web service in such a way as to convert your data into another format (e.g., ACORD XML) will decouple your application from the vendor. The client becomes language agnostic (meaning it doesn't matter what language is used to build the client). Jul 11, 2014 at 18:17
  • I only mentioned the languages because I wanted to ward off suggestions that might preclude Java. Jul 11, 2014 at 20:53
  • Does your current software already support insurance illustrations, or is it completely new functionality? In the first case, you might want to create an adapter service that translates the original API to the new vendor's API. Jul 12, 2014 at 7:23

1 Answer 1


I also work for an insurance company (P&C, not Life). I'm quite familiar with the nastiness that is ACORD XML. Talk about something designed by committee, huh? It's simultaneously verbose (lots of nodes) and vague (limited guidance on which nodes to use for what)... hard to believe.

My suggestion would be to build something like a facade pattern out of the web services in question. In other words, you have this vendor service that expects ACORD XML for a request payload. Your clients don't need to become ACORD experts -- they probably have a small amount of data that they collect. So, build a facade that accepts something that's easier to provide (maybe a JSON REST endpoint), transform the JSON data into ACORD XML (into the proper parts of the node tree), and then run a process that "enriches" the bare ACORD XML so that it's acceptable to your vendor. Then do the same thing in reverse on the way back.

You'll want your "enrichment" component to be as "rule based" as you can make it. So for example, it'll know all the parts of the ACORD node tree that are mandatory, and will have default implementations for all of them. It should also add nodes into the ACORD message that spell out precisely what it changed/added and why (you'll probably want to come up with an interface or abstract class that every rule implements). Then, when you hand the response back to your client, you can tell them all the decorations you did to their request, which will become important because they're providing you maybe 10 pieces of data, you're enriching it to 100, and they're going to want to know where the other 90 things came from and why.

You may also want to build some kind of affinity between the REST endpoint payload and the enrichment component. What I mean is that you may want to put something in the endpoint so that there's a defined way to "override" what your enrichment component does -- accessible clear back to the rest endpoint request. That way, if your consumer decides one of your rules is dumb, or not applicable, they have some way to get around it without you doing all the coding. It might be something like a defined way to spell out an ACORD XPath and a value that you add into the node tree after your rules have run, and a defined way to delete an ACORD node list.

Finally, make sure you do good logging in your enrichment component. Make sure you have a way to easily reconstruct what happened from the point where you receive the JSON request to the point where you hand back a JSON response to your consumer. That kind of transaction-level logging becomes critical in this type of app.

Hope that's helpful. I've done things like this for 15 years. This general approach will save you a lot of headache.

  • 1
    I wouldn't limit this approach to ACORD xml. Jul 15, 2014 at 0:32
  • +1 for keeping clients unaware of ACORD. We're looking at doing a builder pattern for assembling the ACORD messages within the facade service. Jul 15, 2014 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.