Here’s another filing under the heading, “Why aren’t my SOA initiatives working?”
I call it “Database Overreach” and it’s when an enterprise level ETL or SOA tool uses adapters to “reach over” and scoop information out — and worse, poke data back in to — a database. The number #1 indicator that you might be doing it is using database adapters of ETL/SOA tools such as Tibco, WebMethods, Oracle SOA Suite, &c.
Why is Database Overreach Bad
1. Moves the responsibility away from the owner of the database. For instance, if the app admin is responsible for the application he or she must be responsible for the database. The most common scenario however, is the integration folks become adjunct app admins: it’s very rare for the app admin to make the leap into XML, XSD, WSDLs, RESTful API, and the like. So what looks like the easy way is to skip it and connect straight to the database. Your app admin loses control of the app.
2. It may be because the database doesn’t have a front-end at all. I call this a “naked database” and it’s so loathsome I will write a different bit on that alone. There’s an unfortunate laziness in not creating a proper front-end for a database. Symptom of a naked database? When you have a near-dedicated person who is the only one who knows which special SQL/DML command to run to free up your payroll or un-screw the procurement processes.
3. It steals the opportunity for your database to become a member of your event- and service-enabled fabric. The whole point of using HTTP is lost by leaving the service exposed on port 1433 or 1521. Overprivileged user credentials, funky ports, vendor-specific interfaces. All bad.
[Aside, I’ll take this opportunity to say that an RDBMS exposed as native JDBC or ODBC is absolutely service-enabled (and therefore all perfectly “SOA”), but so is CORBA, and for that matter DCOM. There is a quality attribute to service design that becomes pretty important. Ultimately the point I hope to make is that RDBMS-exposed services are extremely low quality.]
What a bad pattern looks like
System A calls the super-dandy database adapter tool (e.g., Oracle Fusion Middleware, Tibco, WebMethods, JBoss, IBM, etc.).
The adapter tool uses fixed credentials and hard-coded information (point-to-point, brittle, hard to maintain over time) to reach completely over the API, the app, and directly into the application database.
What To Do
Wrap your naked databases in an application API layer and bring it up to speed in the API world. Folks who sell tools like Oracle SOA Suite would have you think that’s what you’re doing. But I see a lot of places that use database adapters extensively then don’t undestand why the “SOA” is so inflexible and brittle. SOA Suite has a bold-case, underlined big #1 use case: long-running orchestration. For that, SOA Suite is amazing. Using it to match impedence between HTTP and JDBC? There are better ways, better “applicationist” ways.
My team and I have been standing up high-quality, highly-secure, and now cloud-published wrapper applications for years. Ask about how we can help you can start separating your database applications to improve reliability, resiliency, and to avoid the brittle “upgrade hell” path that comes that from too tightly coupling the database to your service-enablement tool.