previously, we've introduced the idea behind soa and how architecture has evolved over the years to reach this refined design architecture, and why we have the new need for a different type of architecture that's aligned with business processes. now, we’re going to talk a look at the technologies behind soa.

let’s first point to one thing before going through soa technologies. a lot of people struggle when they are trying to understand what is soa. basically, soa is a set of standards and technologies that work together to make business development easier. so, if we brought an soa suite (oracle, ibm, tibco, jboss, wso2, .. etc. ) that is a managed server that goes along with any application server like weblogic perhaps, eventually it’s not something you just put in place, put the application into, and say make the soa! that’s not the way it works.

you have actually to design your application in an soa framework and architecture. that’s why it’s important to understand what soa is. also, an soa server actually enables all different technologies and the management of these technologies. so, when we’re ready to deploy our soa application, we can go relatively easy in monitoring them and setting up applications that use those technologies. that is what soa suites are doing for us; it’s not going to turn an existing application into an soa application, just to plug it in soa suite.

let’s now focus on the different technologies that make up soa. one of the core technologies that goes along with soa is what we’ve mentioned before: the web service. a web service is something that you can think of as a kind of black box. a black box is something that you know the input, something happen in the box (business logic) and there is an output. in a large system like enterprise systems, we’ve got many modules and many different sets of code for: accounts payable, account receivable, warehousing, purchase orders, human resources...etc. these systems have become so large and complex, it can be really challenge to go there and make a change.

if we can take the specific functionality that is in each one of those pieces breaking it into a web service this gives us a whole bunch of advantages. from a developer stand point, imagine that we have something like credit check. if we have a large organization, we probably have a set of code for two different types of credit check: we might have credit check for individual consumer, another one for a vendor, another one in different organizations in terms of transferring, warehouse, inventory numbers...etc. it’s really hard to maintain that at the business level, we might make a different role changes to the credit check. so, we have to go to all of these different places to: change their codes, test and redeploy them while we have different programming languages and different operating systems.

if we can consolidate all the codes that go along with credit check in one place and turn that into a web service which can be called by any other application, this would be a really nice advantage. we can think of a web service like a black box which has a discrete business function that takes an input and produce an output and can be exposable over the web. the question here, once we have this web service created, how i would know about it or how other developers and other programs make use of this web service?

we have something called wsdl (web service description language). it’s not more than xml file that describes the web service. so, if we need to describe the type of input/output fields the web service is expecting, then this should be defined in the wsdl. xml is similar to html, but the main difference is html has a pre-defined tags ( p for paragraph, b for bold) while xml we can define our own tags (tags that describe data, tags that describe meta-data), we can have a complex structure. xml is kind of a standard language for soa. so, when we have programming language that wants to call a web service, we should look at the wsdl in order to figure out how to call the piece of information and the code that should be written based on that. all most all modern programming languages allow us to create a web service out of the box as well as creating the web service client by providing the wsdl which describes all needed info.

it’s important to note that the web service, wsdl, and xml are not specifically soa technologies. web service and wsdl exist outside soa environment while xml exists all over the web but all of these, but soa can bring together in a philosophy of breaking down the application into small pieces and putting them together into what called composite application.

once we have these entire web services isolated, let’s say that we have a whole bunch of these different black boxes together, how can we link them all together? for example, based of the output of the credit check we might go to some form ware: if it fails, we need to send an email and display something on the screen, if we succeed we need to go to the next step of the process in the credit check (going to inventory module). how can we link these different black boxes together? it can be done with something called bpel (business process execution language). most programming languages have graphical tools which allow us to manipulate the link between different pieces through graphical representations of how we want the flow to go, then they can generate the code automatically. so, bpel is a technology which allows us to link web services together.

we have another tool which comes as part of soa called esb (enterprise service bus). it manages all messages between different web services, between different systems that we’re integrating through soa. esb has a whole bunch of different functions those monitoring and routing web services messages (in/out). also, it resolves contention between web services that might happen during the interaction. esb allows us to make version of the web services, for example if we create credit checks and want to enhance it, we may add more input/output parameters, then what about the existing programs? the existing programs will not be able to use the enhanced ones because they have different inputs/outputs. that’s why esb introduced versioning which resolves this issue, it will be smart enough to direct the caller to the correct version. esb has other common services that are needed by the application like: event handling, data transformation, data mapping message queuing, message sequencing, security, exception handling, etc.

so the esb handles a lot of different stuff, it can manipulate data, transform data that goes in/out of a web service depending on the type of the application that called it, we can queue events, sequence different events, and more. putting esb in place can give you a lot of flexibility and it becomes easier to make changes in terms of requirements in complex systems. it also scales from what's called point-solution to enterprise-wide deployment. there is central role engine, there is no center broker and it’s very easy to implement patching, we can implement patch with zero down time. with esb, the enterprise becomes refactorable without need to break down the environment specially when we operate 24/7.

in the next part, we will talk about the business drivers and how each one of these makes a lot easier for businesses to implement soa and gain some real benefits in short period of time.

see also:

oracle soa vs. ibm soa
how to navigate a sea of soa standards