|
|
| Service Oriented Enterprise |
|
|
Saturday, July 12, 2003 Databases & SOA 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. posted by jeff | 8:48 AM Web Service Frameworks (WSF) I have a strong interest in web service frameworks. In general, I am of the opinion that the WSF is where MS & IBM wil have their next major battle. So, they HAVE to agree on a certain sub-set of functionality (those concerns which must be remedied at the protcol level), but beyond protocols, the field is open and the battle will begin shortly. Right now, Sun has a set of api's that they call J2EE (JMS, JNDI, etc.) They expose each of these api's in a "java only" format. Microsoft has a similar set of api's on the .Net side. In my opinion, we will quickly be moving to the exposure of technical architectural elements as web services (web services front ending LDAP, web services front ending databases, etc.) We will also see web services frameworks for horizontal domains (accounting, crm, etc.) and vertical domains (insurance, travel, etc.) Each of these horizontal and vertical frameworks will have to pick a substrate layer to work with. One of the more interesting web service frameworks is GAIA from TME. I like the fact that TME knocked out a quick impl of a soap engine (glue) and are quickly moving into the substrate. They are looking at the world from a set of concerns (scalability, availability, deployability) and identifying remedies (balancing, resilience through redundancy, etc.) Many of the problems that GAIA takes on are concerns that either were done in proprietary hardware (cisco stuff) or concerns that were handled in a monolithic app server (availability through clustering). I am a huge fan of re-addressing these remedies via a consistent web services approach. Using a balancing web service, or a caching web service inside of an orchestration makes a lot of sense. Other frameworks have popped up, but at a higher level. One such framework is the sForce web services api from salesforce.com. The sForce api is early. It provides some real basic services (insert, update, delete, change password, logon, etc.) You can really view this framework as a "data service" framework - and from this perspective, it does the job. Their choice to use a significant amount of abstract data types (records & maps) facilitates versioning and adding new data fields easily, but has the trade-off of potentially introducing typing errors at run-time. Sidenote: This framework looks a lot like the old MS My Services (aka Hailstorm). Web service frameworks are now emerging. It shouldn't be long before MS & IBM throw one (or several) out. It will be nice to move beyond protocol crap (ws-boring, service substrate) and into value-add. posted by jeff | 8:13 AM Tuesday, July 08, 2003 WS-Federation Released Just caught this: http://msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-federation.asp Haven't had time to read it, but it looks like it competes with the old Project Liberty stuff; that is, distributed realms of trust. It is part of the larger security profile (ws-security). posted by jeff | 5:50 PM |
|
|
|
|
||||||||||||
|
 |
|||||||||||||||
|
||||||||||||||||
