Sean McGrath & John McDowall have touched on a subject that is important to me - the use of the dbms in the soa. Yes, one of my first jobs was working for an RDBMS vendor on the mainframe (Must Software - Nomad). Everything we did was based on the relational model. Everything COULD be done via a database (if we wanted to). Hell, you want two applications to share data?? Stick it in the database!!! We preached Boyce-Codd normal form, we used terms like "sargable predicates" and "shippable selects" - we were cool.
Well, we ended up misusing the database and creating ER-models that glued everything together. Later, the middleware people (CORBA, EJB) figured out how to front-end these meshed data-spaces with services, but they didn't actually un-screw the data normalization problem. The fact is that we use surrogate keys and auto-gen id's because they are efficient for the dbms and they are easier to use in our SQL. However, generally they are vendor specific and implementation specific. We all know that "Data Coupling" is the exposure of internal data to the external world, leading to the coupling of two distinct systems (failure to encapsulate internals). Want to see something funny? Take a look at the sForce web services api and see how they dealt with the issue. Ask yourself these questions:
1. Did they expose internal database Id's to the outside world?
2. Do they provide any queryable artifacts to access the constraints (e.g., I need a Customer record before I can insert a Customer Order record)
3. Do they provide ER-Diagrams (data view) or some new service view (activity / sequence) diagram?
After you look at these questions, you can begin to see some of the problems that will be surfacing in providing external access to internal data. The art of service enabling the db is still early - let's learn from sForce and advance the art.
No comments:
Post a Comment