At AMIS they are working on teaching a lot of us about the fundamentals of SOA. We just had the first couple of events in which Lucas and Peter taught us stuff about XML and BPEL. To get an idea of what SOA and webservices actually are and how we should work with them.
At the start of a SOA project, it will take additional investment to develop functionality in a way that makes it reusable (publish it as a service rather than as just some buried part of an application), develop all the small building blocks, but in the long run 
you will 
benefit from these building blocks in different projects. Think of the building blocks as pieces of Lego. There are a lot of different pieces available all with their own characteristics. Some are really small, others are bigger, but they all have a well defined interface and purpose. Using a lot of these (and other) small(er) blocks, you can build a bigger project that fits your needs. I have been playing with Lego since I was a little boy, and now I play with Lego again with my little boy (over 20 years later). I have noticed that in the mean time a lot of the blocks are still available, although there have been a lot of new types of block available today.
I think this analogy should also work for the SOA architecture. Today we need to build a lot of building block which can be used to build an application that currently fits our needs. When time goes by, our application needs will change (definitely) and we will have to build new services to fit our needs. But we can use available services to build these. And of course we can rebuild the ‘old’ services by using the building blocks that are available at that time, which is probably a larger set than when the service was built in the first place. Maybe it can respond faster or be more efficient than what was possible before.
In my current world, this is known as refactoring. Thinking about this a bit more, services are supposed to be like black boxes. I know what I have to put in (what are my input parameters) and what I get out of it. Maybe I don’t know the exact result (that’s why I’m using the service), but I do know what the result looks like. For instance, I have a (web)service available to which I have to feed the Postal Code and a number to get the the complete address as a result. This list is maintained by someone else (not me or my program) but we have agreed on the interface along which we both communicate. It’s like coding by contract.
If it is agreed to communicate via XML messages, the input and output message could look something like this:
request:
<?xml version="1.0" encoding="Windows-1252" ?>
<request>
<postal_code>3439 MN</postal_code>
<number>15</number>
</request>
reply:
<?xml version="1.0" encoding="Windows-1252" ?>
<reply>
<street>Edisonbaan</street>
<number>15</number>
<postal_code>3439 MN</postal_code>
<town>Nieuwegein</town>
</reply>
I know what the interface of my request should be and I know how the result will be returned to me, but I don’t know where or how the service gets its information. And I don’t need to know either. I assume that this service does its work correctly and that the result this service is correct. It is like a black box to me.
This brings up another issue: You don’t have control over all the parts of the application anymore. When a customer provides you with an issue in the application, you should consider all the external services as black boxes. The way they work is outside of your control. Now, there are two possible scenarios with these services. Hopefully the services being used already exist for some time and have pretty much all their bugs fixed, so they can be considered quite robust and less fault sensitive. But it is also possible that a bug arises in one of these services and that it is outside of your control. This can be a real error, but it can also be a problem with the response time of a service you call. The problem is that the issue provided by the customer can be in your code or in a service you call. This makes it a bit more complex to debug your application. It is possible that the issue is in a service you call and therefore outside of your control. The bright side is that all the external services you call can be tested individually for possible defects (according to your specs). It is very important to have good agreements (SLA’s) with the provider of the service you are using, regarding up-time, response time etc.
When you consider the services as building blocks, like the Lego blocks, you can build big things with these tiny blocks. It is also possible that a couple of service are being used over and over again in the same way, the same order, what makes it useful to build a new service which you can call that in turn calls the other services in the order needed. A bit like making a procedure or function in PL/SQL. Using the small blocks
you have created something new
that can now be used as a whole new building block, where you don’t have to remember how the different pieces should be put together to create this.
Overall, I think I have a lot to learn about the world of SOA and services, It’s a different way of thinking from my PL/SQL based way of thinking, but it’s always nice to learn new things. Maybe it’s just seeing things in a different way or just seeing things that have always been there in a different light.
