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.
Best Answer
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.