In-Depth

Breaking Down Walls

Information silos have generated massive amounts of information that may not be easily accessible. SOA can change that.

When I started Informix Software in 1980 my goal was the same as the goal of service-oriented architecture (SOA) today: to break down silo walls. At that time the silos were just simple tables of data, usually read and written by COBOL programs. The Customer file would be managed by one COBOL program, and the Orders file by another. If the boss wanted a report of all the customers, each listed with all their orders, a third program would have to be written, and the programmer would have to get the file definition parts of the source code for each program copied into this new "composite application" that they were creating. That was our tool to make the silo wall go away between that Customer file and that Orders file.

I am glad to say that we got smarter over time, so we invented the relational database management system to do it in a less labor-intensive way. It is now the most valuable tool in all of data processing, relating millions of tables with each other every second of the day all over the world. But we have used it so much that we have created new silos—each enterprise application has its own database and its own application server. That application server was also a great invention, and during my days at Vantive and Visigenic Software it was a privilege to join with others and pioneer the "three-tier architecture" where application servers held the running business logic that did transactions with the databases.

Since a silo's database might have thousands of tables, and how they relate to each other might be subject to change daily as restructuring is done for performance or other reasons, it is only safe now to interact with the logic in the application server that knows how to do things like find a customer or put an order or credit on hold. Those "little software robots" of business logic might work with one database one day, but maybe need to check three databases the next day after a merger of companies, or even just a merger of product lines within a company. Because change is constant, we as a species have graduated to another level of modeling. The business logic in our production servers is now the model of how our enterprise works. This model used to be a tower of babble, with some of that code being expressed as C functions, some as COBOL subroutines or CICS transactions, Java methods, or whatever flavor on whatever operating system using a wide variety of remote procedure call mechanisms. Web services resolve that. The mechanics of how to talk to any "little software robot" is now clear.

Then Came SOA
However, just because we can talk to them doesn't mean we know what to say. How do you authenticate to this Web service versus that one? One server has robots for customer data, and another has robots for order data. How do you get the orders for a particular customer? What if the order data operations return more data than certain users want or are entitled to see? How can we "project" the data down to a smaller subset? The technical term for this changing the inputs and outputs of operations and the data structures that come and go is refactoring the objects. We use a friendlier phrase called modeling up—we advocate that you model up from the Web service operations you have to the ones that you want, and we give you the tools to do it.

Issues such as "object right-sizing" and the semantics of what to send to, and what you will get back from, a Web service are the challenges remaining in bringing down the silo walls. You need tools that sit "above all" of the business logic in an enterprise and create the model of all of your business logic and how it can be utilized. You need tools to model up and compose several Web services, possibly from several silos, into one Web service that has just the right information in it. Your organization might need several models of "a customer and his/her orders" such as "a customer and his/her backorders, but just the critical parts so that when I build an application for a PDA it doesn't send too much data over a slow connection." Or, you might want "a customer and his/her orders that are on back order" or "a customer and his/her orders and the product details about those products on that order" from yet a third silo.

Breaking Down the Last Silo Walls
I think you get the idea. It is great that Web services make it easy, mechanically, to get to all your enterprise silos. But to make use of those Web services you need a new metadata repository that knows about the input and output objects of those operations, and how those objects work in composition with each. And we need a new engine—not a database engine, but a new engine that performs composition operations on Web service operations, to build and deliver on the fly these "modeled up" models, which are what the businessperson wants to see and use.

Building an SOA is what we help you do. We help you take the programmer's interfaces that are your existing "little software robots" and model them up to the businessperson's "transactional objects" of different kinds that the business users of your organization really need.

Most   Popular