Ross Mason: Hi, my name's Ross Mason, I'm the CTO and co founder of MuleSource and today I'm talking about the first steps to SOA.
No one has heard of SOA but once you get past the business and marketing hype of SOA, what does it really mean to introduce SOA into your organization?
Typically you might have a CRM system, you may have a billing system, you may have a general ledger and you may have a reporting system, as an example.
So the complexity here is, different applications run on different platforms with different protocols, different API's and different operating systems.
So the CRM for example, may be on Linux, and it may be running web services. The billing system may be very old on a mainframe system, and using only ftp to communicate. Your general ledger, again, might be on Linux, but supports JMS. And finally your reporting system may be on Windows but using.Net and web services.
So those are some of the challenges of SOA, you have different operating systems, you have different platforms, you have different protocols and you have different API's.
Where this gets even more complicated is when your CRM system needs to talk to your mainframe app. Again, your billing system, based on mainframe, wants to talk to your Windows reporting. Your reporting also wants to speak to the CRM system and it wants to speak to the general ledger. And the general ledger needs to talk to the CRM and also the billing.
So you can see here, each of these dots is your integration challenge, and each one of these integration challenges represents code that you have to write inside your organization and maintain over time. Furthermore, if you need to add functionality to these integration points, such as security, error management, and transactions, you have to build that yourself as well. This adds even more complexity into your SOA application.
So most enterprises will actually look like this, they integrate applications over time in this point to point manner. The problem is that this doesn't scale very well, so how do we get away from this point to point integration?
Well one way of doing it, is by using the enterprise service bus. The enterprise service bus gives you a communication backbone between different applications. So what you need to do is actually just integrate your application to the bus, like so. And then that application can actually share information between other applications just by producing and consuming information on that bus. So now if my CRM wants to talk to my reporting, or vice versa, that information will be made available on the bus itself.
Another thing that the enterprise service bus gives you is a common set of services that your integrated applications can use. These are things like transaction management, security, error management, and reporting.
The enterprise service bus gives you a communication platform and a common set of services that allow you to easily integrate other applications inside your organization, and this is simply a case of identifying the application and then providing the integration to that application.
So if you're a CIO or an enterprise architect and this situation is familiar to you, or you want to avoid the situation, the ESB really is your first step to SOA.
