Reuse is the Key

Reuse 101
In my first computer class (many many years ago), there was discussion about reuse. Back then we called our reusable chunks of code subroutines...today we call them service components. Reusable chunks of business logic. Back in the day, we talked about structured code, which was never to contain a goto statement. Oh, those were the days weren't they!

Below are nostalgic memories of how the idea of Reuse has evolved over the years and then an explanation of how SOA fits into the evolution of reable computer programming.

Assembler - Painful to write but FAST!
Then came that assembler class - wow, was that painful. But then again, you couldn't write any code that operated faster than assembler did! When I worked at the Chicago Stock Exchange (about 1985), we didn't want to put the "real time" data into our Oracle database - why not? Because writing to the database added an extra layer, which affected performance. Eventually we stopped writing Assembler and started relying more on higher level programming languages and even on the database! What happened to those performance considerations? Did we just throw more hardware at it? Fortunately yes, but also the benefits finally outweighed the performance implications.

Hardware Portability - Reuse 102
Oracle had developed a platform that ran on most any hardware! The fact that we could write our code and store our data on any platform was incredible. I remember writing an Oracle Forms application for a large bank in Chicago in the early 90s. They were running Oracle on a large mainframe...and we did our development on our desktop machines - i.e. 286s! How cool was that? We were able to write the code and deploy it on any platform that the bank wanted to run it on. Those Forms might still be in use today!

You Have to Love PL/SQL - Reuse 201
Oracle came out with their own programming language - PL/SQL to add procedural logic to SQL. PL/SQL procedures and functions brought re-usability to everything we did. All of our business logic was attached to the database - right on the same platform. Reusable units of code.

What Ever Happened to CASE?
Some time ago, Computer Aided Software Engineering (CASE) seemed to be the way of the future. The upper CASE tools were used to design our systems and via the lower CASE tools, our specs were going to write all of our code! For a period of time, those specs did generate a lot of code. I was fortunate enough to have the "opportunity" to try to enhance some of that code. Fortunately that phase disappeared about as quickly as it came. For years programmers feared they would no longer be needed. Fear no more!

Along Came Java - Reuse 202
Today we were talking about Java programming and wondered what we did before Java? A language that runs on all platforms - how cool is that? Write your code, access your database and deploy it on any platform - for free. There is so much "free" code available today, it's absolutely amazing! Again, reusable components at your disposal.

Ah, ha - No More Comma Delimited Files - Reuse 301
Then along came XML. The ability to share / reuse our data inside and outside our company. Re usability was great, but without standards for delivery, reuse was inconsistent. Along came SOAP and Web Services. A protocol to enable the delivery of data (based on XML).

Is it Time to Graduate Yet?
So here we are - in a layered world. Assembler, operating systems, databases, programming languages, XML, SOAP and so much more! What does it all mean? How does this fit into your environment? Do you need reusable components? Of course, we all do!

I Get it. Reuse is the Key!
In IT, we'll continue to layer it on and we'll continue to improve upon what we've developed. We might be nearing our undergraduate degree, but we're far from our graduate work or our doctorate aren't we!

Reusing Everything You've Built Already
What if you could reuse all of that business logic that you've already built? Wait, you can! That's what the service architecture is all about - reuse. Another layer of abstraction has just entered our programming world. The ability to build a service and use it everywhere is here. Not just within Oracle or across Oracle databases (i.e. executing a PL/SQL function across a database link), not just across platforms or programming languages, but across your organization and even across organizations!

It Seems So Complex or Too Good to Be True
When I first read about Web Services (or .NET in the Microsoft world) I thought it sounded too good to be true. How can I execute a program (written in a language that I don't know) on a server (on an unknown platform or one we "don't support?"), get the data back and make a decision based on that information? How would I know the inputs required for that program? How would I interpret the output? Do I just get a simple response in a string? To the contrary - the output can be as complex as you can imagine it might be - nested objects, arrays, etc.

The WSDL
An XML syntax called the Web Service Description Language (WSDL) defines all of the reusable components (by name) and the inputs and outputs for each of these components. Yes, it's that simple. Today, almost every development tool imaginable understands how to read a WSDL. So if you're doing Java development using JDeveloper, Eclipse, NetBeans, or whatever tool - it knows how to read a WSDL. If you're writing your applications with Oracle's Application Express (ApEx), it understands WSDLs. You're using a mashup or portal tool - they know how to read a WSDL.

For Example - The Customer Domain
Let's say that you've already created a PL/SQL package that contains a series of reusable business logic. For my example, let's call the package the "Customer" package. It contains the business logic required to add a customer, update information about a customer such as marking a customer's status and so forth. In addition, you have a view that can be used to pull all of that customer information together (from the underlying storage objects / tables).

The Magic
Let's say that you were able to expose the above package and view as services. The services would each have a WSDL associated with them. The WSDL tells another tool (or developer) the inputs to the available operations (i.e. functions) - such as the customer number or name and the outputs that will be provided by the operation. Imagine that - any program can now access your business logic and business level data. Magic right? How's that for reuse? But wait, nothing is magic, so how do you bridge this gap? From a package in the Oracle database to service that anyone can use?

Insight
It's much easier than you might think! Thinking back to my high school and college math for a minute, I remember that I learned the "long way" to do calculus calculations and then the "short way." In my programming classes, I can remember writing code the long way (i.e. assembler) and the easy way (i.e. not assembler).

When it comes to the creating a service architecture and service components, the same is true. You can use tools like JDeveloper to wrap an existing package into a service. You can put all of your pieces together to deploy your application to your application server. There are many "manual" methods of creating these services.

There is also an "easy" way to accomplish this...and create a registry of services at the same time. Why is the registry important? Everything goes full circle of course - reuse! You don't want to create a service that you already have AND you want to be able to easily locate the services you have! Back in March I first blogged about Instant SOA - our code name for our new service creation product. We've now renamed Instant SOA as Insight.

Insight greatly simplifies the process of exposing your existing business logic as reusable components! Literally within minutes you will be creating (and consuming) your first services.

Sharing with Other Departments
Once you have these reusable services, how can you use them? First off, you might choose to share those services with other departments. So that they can add new customers or so they can look up customer information. Imagine how powerful this reuse will be for your company!

Sharing with External Organizations
Another option is that you could share your data with external organizations. You might allow your customers to maintain their own addresses through the services. Or maybe you want to provide them with access to their orders or other valuable information. You could allow them direct access to add new orders, look up inventory/product availability and the like.

Service-Oriented Workflow
When services go beyond your department, you might need to orchestrate the flow of tasks that occur. For example, when it comes to adding a new employee to your company, several departments (and systems) might be involved in this process. Today's workflow engines know how to read WSDLs! This makes the orchestration or coordination of the workflow a simple diagramming process!

Service-Oriented Integration
Or you might be interested in integrating your systems together. Historically we built point-to-point (or one-time wonders) integration programs. These typically involved FTPing a comma delimited file, which was parsed, loaded, exceptions were handled, etc. Now that all systems have access to other systems, integration becomes much easier than it was previously.

Reuse is the Key
Why reinvent the wheel? Why re-write your code? Why not take advantage of all of that business logic and data that you already have throughout your organization? You can take what you have into the service-based architecture - it's time!

Here's the real kicker - this is even better than being able to reuse everything you have today! Once you build your service components, you'll be able to use those components everywhere - inside your company - outside your company - talk about reusability!