Java SOA Cookbook, by Eben Hewitt, covers the Service Oriented Architecture (SOA) topic from a Java implementation stand-point. In the book, Eben discusses the SOA model basics, its implementation using web services and tools and best practices. The book is written in a Problem-Solution-Discussion format. It's divided into 4 parts:
- SOA Fundamentals
- Web Services
- Business Processes
- Interoperability and Quality of Service
The author starts off the discussion with introduction to XML Schema and SOA Data Model and how to work with XML documents using the Java API. Creating web service applications with API such as JAX-WS and SAAJ is also discussed with code examples.
The role of web servies in implementing a SOA architecture using SOAP based and RESTful architecture styles is discussed. RESTful web service examples include creating a Plain Old XML (POX) document over HTTP Service with Servlets, a RESTful Service with JAX-WS and setting up JAX-RS implementation using the Jersey container.
The service orchestration with BPEL using Apache ODE BPEL engine is covered in Chapter 9. Some of the advanced orchestration use cases covered include executing activities in parallel, synchronizing activities executing in parallel, executing an activity at a specific point in time, executing an activity after a specific delay, selective event processing and adding Human Tasks to a Business Process.
Other topics such as SOA Governance is also discussed in terms of determining a data ownership scheme for services, documenting services, and setting up a Service Registry. The book concludes with the discussion on Enterprise Service Bus (ESB), role of ESB in SOA implementation, Java Business Integration (JBI), and commercial (Oracle Service Bus, Software AG/webMethods ESB, and TIBCO BusinessWorks) and open source (Mule, Apache ServiceMix and OpenESB) ESB containers.
InfoQ spoke with Eben about his book, the main motivation for writing it and other topics. Some of the topics covered in the interview are:
- Role of SOA in Enterprise Architecture
- SOA implementation in Agile and Lean software development environments
- SOA implementation frameworks and tools
We are also making an excerpt (SOA Governance chapter; 1,353 KB PDF) from the Java SOA Cookbook available for our readers.
InfoQ: What was the main motivation behind writing the Java SOA Cookbook?
Eben Hewitt (EH): I wrote Java SOA Cookbook in order to help Java developers write the kinds of applications that the SOA architectural strategy suggests. As SOA gained popularity some years back, there were truck loads of books written on SOA with a kind of "manager's guide" perspective; the advice was very general, very high-level, and you could read several of these books and think, yeah, that's great, that's exactly what I want to do, and then sit down at your IDE and not have any idea what to type. I wanted to close that gap. It has chapters on both the WS-* approach, stuff such as Addressing and MTOM, but also has a chapter on REST principles and how to use the JAX-RS reference implementation.
The book does have information on design, such as what kinds of XML Schema design patterns help you implement a canonical data model that you might use in your SOA. But that's not its focus.
In my role as architect, I needed to help communicate to the developers with whom I'm fortunate to work how all of these complicated APIs fit together, where to start, what you need and what you can throw out, and how to deal with the plumbing to help them realize the goals of SOA in a concrete way. So really it was written for them. There's a lot to sort out things like which XML Schema design patterns help you realize a canonical data model, and how the JAX-WS annotations map to WSDL, how to do validation against a schema, how to set up projects, and so on. So I started compiling my notes and realized that they needed to be somewhat formal to really help save developers time. I sent the book idea to Simon St. Laurent and happily O'Reilly picked it up.
InfoQ: What is the role of SOA in Enterprise Architecture (EA) space?
EH: For the EA office, service portfolio management is key. Whether you think SOA as it has been envisioned for the last few years is dead or not, services are here to stay. For what it's worth as an indicator, The Open Group has added a SOA module to TOGAF. I think the SOA wars are settling down, and it's time for the EA to consider the next step after service enablement. This could be BPM, which is terrific stuff, and it could be event processing, or, my favorite, both. I like to have my cake and eat it too.
Of course, EAs know that SOA doesn't solve everything, any more than a Model Driven Architecture solves everything. So for me, the role of SOA in EA is to elicit and act as custodian of the service catalog, create standards and guidelines around service design, development, APIs, versioning, monitoring, all that stuff, and then determine your own strategy about where to automate business processes, and how to work in an event model.
SOA has gone through its Hegelian sublation, and can just be part of the landscape now that enables new initiatives. In certain businesses, one of those initiatives might be an explicit strategy to use the service catalog to get free of legacy systems. Clearly the EA needs to keep a close eye on that.
InfoQ: Domain Driven Design (DDD) concept has been getting a lot of attention lately. DDD is about mapping business domain concepts into software artifacts which is what SOA strives to accomplish. Can a SOA implementation be successful without a solid domain model and implementation in the back-end? Does SOA complement DDD?
EH: The core of Domain Driven Design really encourages developers and analysts to focus on the domain, in the language of the business, and that works great with a variety of strategies, including SOA. DDD is particularly powerful if you're using a RESTful architecture and mapping domain objects you've identified to resources. I guess some analysts want to refer to this as WOA.
DDD is also useful in creating and sustaining a canonical data model, which is an important part of a SOA. So obviously I'm referring more to the mode of investigation, and less so the concrete Object Oriented patterns.
InfoQ: How should SOA be implemented in a software development environment where the teams are using Agile and Lean methodologies such as Scrum, XP and Kanban?
EH: Agile works great with SOA. It's how we practice SOA at my company. It works with Scrum and XP. Kanban is newer, and I'm not aware of any teams that are really pursuing SOA under a Kanban model. Typically Agile teams are devoted to a single project and are focused on getting that out the door, but with SOA you have this cross-project concern of eliciting reusable services. So as an architect you need to be aware of what the project teams are doing and help them see when something they're working on can be written as a service, or reuse an existing service. You can then add a backlog for defining the service interface and commit to it so the team doesn't get bogged down. Then you can work with the business to define the interface and write an API that the developers can rely on. Then developers tie it together on the back end and the service consumers have something to write against on the front end and it all kind of meets in the middle. This seems to maximize the opportunities for parallel development from different angles, including testing, and get stuff done quickly. That's worked pretty well for us.
Lean in particular is a good way to approach business process automation. You model your business processes, supported at runtime by service implementations, and measure their effectiveness using monitoring tools, and then run simulations that help you analyze where your process bottlenecks are. The Lean framework is a good fit for this life cycle, and something that we're starting to explore more.
InfoQ: Can you talk about the current state of SOA implementation frameworks and tools and what should SOA architects look for when choosing a SOA framework?
EH: Sure. The approach that we took was to start open source. I talked about this at JavaOne. I can be a bit of a standards wonk, so initially we did everything in straight XML, BPEL, JBI, XPath, Java, and so on, and chose tools that supported this. This allowed us several things. First, we could get started with the most minimal up-front investment, to test the waters and get our ideas straight. This helped ensure that our education efforts could be applied across a variety of platforms, so that we had an easy exit strategy if we wanted to go in another direction.
Ultimately, we did want the kind of tools that aren't really mature in the open source space just yet; in particular, certain vendors have terrific tools around creating automated processes with human tasks and BAM (Business Activity Monitoring). The productivity can be much greater too when you aren't buried in all that XML.
Whatever you go with, you want to understand the vendors' fundamental vision of SOA. Lots of SOA vendors came out of the integration space, and so they have all of these legacy adapters lying around, and you get their adapter for PeopleSoft and JDBC and Exchange wrapped up in a bow with an ESB sticker on it. That was convenient for vendors for a while, but that might not get you very far. Others have a vision of SOA as an event engine, which is very appealing to me from the perspective of loose coupling and analytics. Other vendors are really focused on processes, which is very cool too. Beyond simply creating a catalog of services, if you look at where the real productivity gains are, they'll be realized in automated processes, because the models can be understood by business people, and they can put KPIs around steps in the process, and get generated dashboards that help them visualize what's happening in the business and improve efficiency.
There has been a lot of shopping going on with the bigger companies, and a lot of consolidation. So be careful to make sure that your vendor is stable, and the stack really is unified. Just because the vendor prefixes 17 components with the same brand name doesn't mean they're actually integrated. You want to get some demos, do a proof of concept, see what a day in the life of a developer with their tools is really like. Really grill them on how the tools work together. If you're seeing a lot of importing and exporting going on between the tools in the stack, or seeing a lot of tiny snippets of code squirreled away here and there across development tools, you might just be moving your problem.
Alternatively, you can go best of breed for each aspect of SOA, get your favorite ESB, your favorite BAM, and so on. But then you have the problem of which throat to choke when something goes wrong.
InfoQ: What is your take on REST v. SOAP Web Services architecture models? What design and architectural considerations should SOA developers take into account when using one or both of these SOA models in their applications?
EH: To be honest, I think this is sort of a false opposition. As a developer or an architect, you need to have both in your back pocket. They both have compelling features. You'll need to integrate with back end systems that use SOAP, and you'll need to integrate with third-party services that use Atom or RSS or whatever. When you do have a choice, use the best tool for the job given the application, the performance requirements, client requirements, and so on. Ultimately, to be successful with SOA, you need to adhere to the same general principles: provide a relatively stable, standards-based interface; don't leak your implementation; hide behind an abstraction layer to remain protocol and implementation independent in your domain, use services for cross-cutting concerns such as security, transformations, and rules; make sure consumers aren't tied inappropriately to your model; have good documentation and a clear versioning and upgrade path; make sure you know what services you're actually running and have an idea of who is consuming them. You need to address all of these issues regardless of your choice of SOAP or REST, and these are the decisions on which your success really will depend. In the end, you don't want your consumers looking in the kitchen and seeing how the sausage is made.
But these also are not the only choices. You can do a lot too with, say, straight JMS, depending on your needs. This approach is very fast, very decoupled, standards-based, and vendors are starting to roll SOAP over JMS into their products. This started back with BEA and Software AG is implementing this as well. You can work with JMS from .NET. It doesn't solve everything, but there are options. I've talked with architects who have been happy with this approach.
These sorts of wars sell tickets, you know, but you can write good and bad applications in any language or in any style. Read the few relevant WS-* specs, and read Roy Fielding's dissertation to help choose what's best for you. But if you understand, and are committed to, SOA principles, you'll be fine.
InfoQ: Do you have any other comments or thoughts on the book and SOA topic?
EH: Java SOA Cookbook is doing pretty well, it's been well-received, and that's terrific. I hope it's useful to people and saves them some time.
In terms of SOA, I'll be very interested to see where it goes. What I'm looking at is how it can serve as the foundation for an Event-Driven Architecture, work in tandem with that. Events allow for loose coupling, a sweet opportunity for business intelligence, and tools like Complex Event Processing engines and Event Stream Processing engines can provide data correlation that promotes interpretation in ways that's harder within traditional domain approaches. So along these lines, I'm working now on the concept of a Deconstructed Software Architecture (DSA). This is really a divergence from a lot of accepted ideas. I studied some philosophy in graduate school, deconstruction in particular, and over the years watched Derrida's ideas on deconstruction get wildly misrepresented in the popular culture, but then they've also been applied in interesting new ways in fields from building architecture starting in the early 1980s to the culinary arts more recently. I think there's a lot we can learn from it and apply within software architecture. For example, in what I'll call a DSA, the strong domain model falls away in favor of events, which has certain constraints, and context becomes a much more fluid idea. I'm keeping my research here on spearsource.com if you'd like to follow it.
InfoQ: Thank you Eben.