SOA architecture, but just one endpoint please.

I mentioned earlier that I work with a healthcare software company. In any EDI project, there is usually a common protocol involved, in healthcare that protocol is either HL7 or X12. The easiest way to speak those languages is to rely on an EDI mapping tool or "interface engine" to be your middleware.

There are several vendors out there that would love to sell you an interface engine, for the price of a garage full of Ferrari's. You can control the price some by limiting the number of endpoints through which you can send data to your app.

So now I have a project where my P2P path between our engine and our app will be thorough a single endpoint. Yay. So I have to build a hereIsEverythingFigureItOut() web service, in order to minimize the number of endpoints that we have to pay for in this quarter.

What's a boy to do?

As an architect, I am still compelled to do the right thing and build a proper API as it truly should be and let this assinine single entry point talk to an adapter class which tickles that API.

Addendum 8/27
Boy was I whiny that day... Sheesh. Sorry about that. The truth is that we did bring in the Rhapsody interface engine, which in its latest release is quite slick. I haven't had any hands-on time with it yet, as our senior analyst is hogging it (truthfully, I've been far too busy). As far as this project, we ended up not going with web services at all, but rather continued on with our legacy framework for the time being. Since then, I've been turned onto RESTful web services, which I'll have to do a post about at some point.