<<Question: This talk of SOA 2.0, how do you define that and how is it different from just regular SOA? Is it just marketing? Erl: I think you would have a case to call it a marketing initiative. I think it started with Gartner almost two years ago. The initial concept was that, in the early stages when SOA was emerging, it was based primarily on use of Web services that used a client-server- or request-response-type model. When a consumer application would want some information, it would ask the service and it would provide the information. That became sort of the norm, even in larger organizations where you had more services linked together as a composition.
But all the while, event-driven architecture (EDA) has been part of the messaging framework. It was popular because it did not require that every request be followed by a response and it allowed us to establish different types of relationships between programs. With event-driven architecture, you have the ability for one program to establish a long-term relationship with another as a subscriber to a certain type of event. It can basically say, "If anything happens related to this, let me know." It means I don't have to keep checking with you. Then the program being contacted acts as a publisher, so that when a certain event occurs, it has a list of subscribers and will notify those subscribers with the data it has from that event, whatever that is. And though it's not as simple and straightforward as a simple request-response relationship or traditional client-server relationship, it's more efficient. It's a more streamlined architecture because you only really communicate when you actually have data to exchange. As vendors began offering more sophisticated features, because of the fact that Web services are based on messaging, it was possible to revisit the EDA model and allow a subscriber relationship with services that could act as publishers It provided more design options as far as what we could do. And so that step forward was considered relevant enough to be labeled SOA 2.0, though when that term was introduced, there was a mixed reaction. There was some backlash. It was criticized as being simply a marketing ploy. There was a push to make it a new industry term, but it didn't really achieve that status. We've never used that term or even seen that term actually used in practice. But it highlighted that the EDA model was being made in support of SOA. It's like one being built on top of the other, and if your platform supports that, it provides some valuable design options. Question: Can you give me an example of how this might be used? Erl: A really simple example would be if you had a service that represented a body of data, let's say it's human resources data. But say you have (another) program that needs to know when the status of an employee changes. [Employees] might go from part time to full time, perhaps they're on a leave of absence or perhaps they've been fired or they've retired. But these status values don't change much. They can be active for years. So you don't want this program to check every day: "Has the status changed?" You might have hundreds of employees and it's just a waste. So you could set it up to notify the program when there are changes. You can set it up to notify the service when there are any changes or only when the status of specific employees changes. Question: So is this making things simpler or technologically more difficult? Erl: It does increase the complexity of the architecture because it can lead to more unpredictable messaging exchanges. And that's a subjective statement. If you come from a client-server model, which represents the majority of IT, then to you this would be complex. But if you come from a messaging background and you're used to dealing with messaging or a middleware environment, then it wouldn't be that complex because you've seen it before. You now have messaging that can occur at any time, unless you put parameters on them, but when the messages occur and how they occur, if not properly designed, could lead to convoluted architectures. But the simplicity aspect of SOA has to do with the target state you work toward. Once all this is established, one of the key aspects of SOA is to establish this environment where you have all these services in a particular domain that are interoperable, they're highly compatible and you can reuse them as much as you want. Once you reach that target state and you have to build a new business solution, you don't have to start from scratch. You might be able to use 60 or 80 percent of the logic you already have in your inventory of existing services, pull them together with the 20 percent you're adding of custom code, and you have a new solution. That target state is what's so attractive to organizations. Question: Are vendors moving to this subscriber-publisher model as well? Erl: Some are doing it more seriously than others. It is expected to become a common design option. For example, one of the books that I'm working on, which will be released later this year, is on design patterns. A design pattern is a proven solution to a common problem and one of the patterns is for event-driven messaging. It's very much based on EDA within the SOA context. The fact that it has become a design pattern in the SOA world shows that it already has become an established part of it. It does not represent SOA as a whole, it's just a new design option that you have. It's simply an indication of how SOA is evolving and becoming more sophisticated, because there's so much support for it in both the standards and vendor communities to kind of push it forward. Question: How do you see SOA evolving in the next few years? Erl: If the predictions from the analyst firms are accurate, there's every indication that SOA is becoming the next de facto architectural model for distributive computing. So the prediction is that you will be doing SOA by default when you're building a new custom solution or even if you're purchasing out-of-the box solutions from vendors. The support is for inherent service-oriented design principles and for delivering out-of-the-box products as a collection of services that you can do different things with outside the controlled environment established for the product. That is becoming increasingly common. Whether you're building custom services or one with custom services and out-of-the-box products like ERP systems, if they all truly support SOA and truly support service-orientation design characteristics, then you do reach that state where you can mix and match services, build all kinds of creative compositions, and not just build or align business agility, but evolve your IT enterprise as a whole in tandem with how your business evolves. If the business has to go in a new direction, IT can respond and change course without huge impacts. IT becomes an enabler of the business instead of an albatross. Question: What other points would you like to make about SOA? Erl: There is often such a focus on the acronym SOA. Because there are so many perceptions of what SOA really is or what is means for something to be service-oriented, it's hard to know whether you're actually doing your project in the right way. But we've found that the most valuable way to approach that whole segment of IT is to understand what service orientation is. If you understand service orientation as a design approach, then you understand specifically how you have to design your solutions so they are legitimately service oriented. And once you have that understanding, you can view the whole SOA marketplace, and the community as a whole, with increased clarity. You know when something is service oriented or not and you know what it will take for you to build something service oriented in your environment, with your constraints and with your goals and your requirements. There might be products out that that have not been marketed as SOA products that still might be the best ones for your environment. It just gives you a roadmap about how you should proceed >> You can find this interview at: http://www.itbusinessedge.com/item/?ci=40350&sr=1 Gervas
