Anyways, I was asked by a group called NOREX to lead off a forum on SOA. In order to better understand this, let me give a bit of background on NOREX. In essence they are facilitators. They have meetings and teleforums where they talk about technology without all the vendors pressing their individual goals.
I was told that most people attending this session would be still in the introduction or early implementation. This is my lead in for the SOA Teleforum. Hope it can benefit someone.
Jeff
NOREX State & Local Government Forum
SOA Teleconference
As you know, SOA has been having a lot of hype lately and probably why we are discussion it today. SOA was coined by Gartner Analysts Roy Schulte and Yefim Natis and has been like gangbusters ever since.
But what is it? What is about this new “architectural style” that gets people excited and gets Gartner to say that by 2010, this style will be used in more than 80% of new mission-critical applications?
If we extend the Acronym, we get Service-Oriented Architecture. I’m sure you already realize that Service is the key word, but how does that apply. If you look at any other field, a service is something that is done for the benefit of another. You could look at this as an electrical or water service, or restaurant waiters or tax accountants. This definition is exactly what is meant by the service in service-oriented architecture. A piece of software that does something for another. However, all of the other examples have another thing in common: multiple consumers of their service or put another way, they were not created for the expressed purpose of one consumer. If we look at tax accountants, he or she follows the same set of rules, procedures, etc for every consumer that uses the service although each may take a different path inside the process based on individual circumstances. The tax accountant is consumer-agnostic. The service is not built for the needs of 1 consumer, but all or a large set of consumers. The Service as part of SOA is the same way. As an example, if we build a web-service that is designed to accept input from a single source, then it is not a service, but rather an API or Application Program Interface only.
So, let us take a look at the key principles an SOA must meet:
• Modular
• Loosely coupled
• Distributed or networked
• Contractual
• Consumer-agnostic
• Abstraction and understandable
Modular and loosely coupled are things that Computer Science professors kept drilling into our heads. The saying that I had to learn is “Maximize Cohesion while Minimize Coupling.” SOA enables both of these concepts. As an industry, we have been trying to get this going for a long time. In particular, modular programming, APIs, DLL, CORBA have all been trying to accomplish this goal. We are continuing the work.
Distributed or networked is very critical. A lot of the programs that have created over the years put the intelligence of the program deep inside. To understand this, think of a billing system or point of sales system. The functional piece of code that calculates sales tax is used over and over, but generally is buried deep inside of the code or accessible only via DLL or library. Distributed or Networked principle says that it has to be accessible via the network or more precisely that it is not loaded as part of the code base of the consumer as would be in a DLL or library.
Contractual principle is a very interesting one. Any real-world service has either an implied or explicit contract. When you drop your clothes off at the dry-cleaners, you determine a price via a chart; you choose a pickup based on rules; you choose starch and other options. The same thing applies with SOA. You have a contract that indicates what will be done, the functional and non-functional requirements, you indicate the semantic definitions.
Consumer-agnostic we discussed earlier, but in essence, you build a service for a large set of consumers not one consumer. That isn’t to say that you might not build something as version 1 to fit a single consumer and then increase its consumer-agnostic ability as we get into version 2,3 etc. This amount of this attribute is directly proportional to the ability to increase reuse.
I saved Abstract and understandable to last because it is the most important. In fact, I called SOA: Service-oriented Abstraction. Abstraction is the ability to make a complex item knowable. It allows us to conceptualize. It is this conceptualization that allows designers to use it. A computer example is the idea of a disk folder. There is a lot of complexity to being able to read and write to a disk drive. Years ago, device drivers were created that generalized this and made a common interface and then visual folders were created. So now we have only had to drop a file inside of a folder and the machine takes care of getting it written to the actual physical hard drive. Services allow the ability to abstract. The question is at what level of abstraction you build your services. We could build a service pretty low level and just make some functionality like save-to-disk or we could make our services higher level and make it something that the business user will be able to understand such as calculate sales tax or create order. By building higher level services, then we increase the opportunity to allow business users to be more actively involved and even to be building their own code.
As you can see, all of these principles build upon each other. It is the building that makes things
This presentation would be wrong if I didn’t at least say how we can use these services. Once we have built services, we need to figure out how to apply them. Obviously, we can use them inside of traditional application code. We can build applications that leverage services from other agencies or external entities. We could also use business process management (BPM) to define the business processes of our agency. By building higher level of abstraction services, business users can create or change their process to innovate. IT needs to be involved from assurance, testing, etc. perspective, but this will allow a better integration between the business and information technology.
Still other perspectives are web 2.0 concepts like mashups where people take functionality and data from different places and combine it in a new way. Perhaps by solving a problem that is high priority for them, but low priority for the enterprise.
You will notice that I never equated SOA with web services or REST or CORBA. I believe the concepts are not equivalent. The latter are transports or how I get it from here to there. But by using the principles I laid out, and then we will be pulling the functionality and data that are trapped in the bowels of our applications and bring it to the surface where we can build off of it and inter-collaborate better than ever before.
