Incremental SOA
Monday, January 5th, 2009Loraine Lawson recently did a great job of summarizing some of the predictions for 2009 for IT. Loraine noticed that there was one item that was common among the predictions by David Linthicum, Joe McKendrick and Eric Roch. Joe put it this way: “There will be fewer big-bang SOA projects rolled across the whole enterprise, and many more incremental, bottom-up efforts — many of which may be under the radar.” Although not mentioned in Loraine’s post, Dana Gardner also has this podcast interview with several pontificators who predict, among other things, that businesses in 2009 will emphasize projects that can reduce costs in the near term.
So, what technology do you want to use if you already have several services and you want to quickly and easily create a few new services, partly by building off of existing services and partly from scratch? Installing an ESB would be a mistake. If you already have one, that’s great, but a small project isn’t the right place to kick off the move to an enterprise-wide bus.
What about development technologies? Should you create your new services using JAX-WS and JAXB deployed using JavaEE deployment machinery? No. Why pay all of the complexity costs related to mapping XML and web services into Java in this case? The new business logic would be so dwarfed by all of the generated code and configuration files that it would be lost in the muck. Just the JAXB generated classes alone will usually be counted in dozens for any real XML document.
Why not use an orchestration language that is already designed to use XML and WSDL as the native type system for the variables and method signatures? In other words why not use BPEL? If the new service can’t be fully automated you can use BPEL4People to handle the involvement of people in the service.
Of course using the right language is not sufficient. For the project to be small and simple, it should also be easy to test and deploy. It should make it easy to manage running services. And just because you want high developer productivity doesn’t mean you can give up the need to develop truly high performance services. And if the project is really going to generate a quick ROI and operate “under the radar,” it has to be budget-friendly.
ActiveVOS anyone?
