What I took away this week

So I really enjoy training and instruction. This week I got a good week in. I think that the Wednesday content was the best. It was all about Service Oriented Architecture (SOA). It has been a buzzword for several years now, but can you really describe what it is. I could in a theoretical sense before this week, but I think I can in a technical sense now.

SOA is not a thing, it is a it is a development strategy. You don't wake up one day and discover that you have developed a SOA. Instead what you do is you make a commitment that you are going to look at processes and the systems that deliver those processes in the abstract. They cease to be systems and instead become a collections of components or services.

Generally there are three ways in which services are achieved. The first and most simple is to share a common database. This has risk though in in terms of load and functionality. It also may have problems concerning timing. The second Web Service we looked at was the point to point web service. It is good and I understand it but I didn't see how is was different from what came before in APIs for traditional applications. I have since done a little research to contrast the two and now I know that APIs are usually more language-dependent. Thus if you have a C# application the API is expecting to respond to C# requests. The web service makes an API more generic so that it can accept and respond to a greater variety of requests.

Point to point services are great, but what happens over time? The number of points and connections between them become a maintenance burden all by themselves. The web services are supposed to decrease maintenance but if alloowed to grow in this organic manner they represent an ever increasing burden.

That is why the third area of SOA is really gaining popularity. I hate to try to oversimplify it but the Enterprise Service Bus seems to me to be like the routers and switches that allow your network to work. Think about it, what does a switch do? It receives messages and routs them in the right direction. ESBs do that too. They receive the calls to web services and get them to where they need to go. In this sense the ESB is like the phone book (directory) of web services for the organization. Additionally the ESB can help you to understand the dependence you have on external web services as well. It is only with this level of visibility that we will be able to implement governance with teeth. The reason I say this is because I could have service A, and someone unknown to me could create service B which is exactly like service A. Assuming that the same service is provided by two different applications my ability to discover this service and force convergence of these two is less likely without an ESB.

Anyway, good stuff I really enjoyed it.