Service-Oriented Architectures by Any Other Name
The collective vision of the vendor community today says that a grouping of web services actually creates a services-oriented architecture (SOA). Despite the fact that the concept of SOA is met more with criticism and doubt than is the concept of web services, it's becoming clear that web services are starting to pay off as a database integration platform. That sets the stage for an SOA platform for early adopters.
The disparity is narrowing between the best practices and clarity of the enterprise application integration (EAI) vendors (including BEA and Siebel) and platform vendors (including SAP NetWeaver) and the actual results of companies adopting SOA strategies. Especially in services industries, there's a strong focus on creating five or more web services to streamline integration points in financial reporting and human resources applications.
The fact is that many IT organizations have an SOA and don't really know it. Abandoning the concept of using hand-built connectors and adapters for more scalable platforms has delivered SOA years ahead of the hype. Databases that have programming extensions for HTML, HTTP, and XML extensions have been added to these companies' platforms and today are serving as the foundation of an SOA.
Put aside the hype of SOA and start looking at your existing databases to bring in programming extensions and access points for web-based development languages. For manufacturers who have relied on ODBC either as a transport mechanism or for the basis of their adapter development, it's crucial to remember that the convergence of object-oriented programming languages to include C# and J2EE is making the storing of objects—not just data—the heart of what it takes to move into web services that matter.