Loosely Coupled

When I first joined this SOA team, I questioned the architecture we were implementing. The application flow is basically linear and uses JMS to pass messages between the various functional components. The components themselves were not designed generic enough to be shared by multiple applications. Like I mentioned earlier , the main driver for rewriting this application was for speed. The whole thing seemed very unSOA-like to me. Since none of the components were reusable outside this application, why not code the entire project in a "traditional" way? This approach would improve performance, replacing the overhead of multiple marshal/unmarshal operations needed for JMS with direct function calls. My perspective changed (a little) recently when we needed to add new functionality to the system. We could have modified one of the existing components to implement the new feature. Functionally, it made sense to keep this related logic together in a single module. The main p

When developing Java RPC-style web services, I'm torn whether to follow a top-down or bottom-up approach. Using the bottom-up approach, you create your Java classes first and use the @ WebService and @ WebMethod annotations to specify that this is your web service interface. The WSDL for the service is generated automatically during the build (pretty nice). This approach has it's advantages in that you never have to leave Java to create the WSDL. Creating a WSDL file is not trivial and using this approach means you never need to think about the WSDL's <service> , <binding> , or <portType> elements and how they're linked together. Conversely, a top-down approach means you create your WSDL first, then use a utility (either your IDE or a command line program) to generate the Java skeleton. Using this approach you need modify the generated Java stubs to call your business logic. If the interface (the WSDL) changes, you'll need to regenerate t

I've started to use JCAPS 6 a little of over the past month and thought I'd share some of my initial impressions. Finally a JCAPS editor I can use! I found the previous version of the JCAPS IDE hard to develop with. It was based on Netbeans 3 and didn't have a lot of the features I had grown accustomed to using ( refactoring tools and a local history to name two). It was just plain old, clunky, and slow. The new version is based on the latest Netbeans and all the goodness is back. And it's fast. No more repository. Well, almost. JCAPS 6 has a few different modes to work in - repository based or non-repository. A repository based project allows JCAPS developers to work in essentially the same way they did with JCAPS 5 - JCDs , OTDs , connectivity maps, deployment profiles and yes - the repository. It's also the way to migrate legacy JCAPS project to the new platform - through a simple export and import between the repositories. I haven't used t

As the struggles continue with the application rewrite I'm currently involved with, I've read and reread these articles by Joel Spolsky , James Shore , and Chad Fowler on why this path generally leads to failure. After I finish reading articles like these I often ask myself: since many of the industry thought leaders think these projects are a bad idea, why are they still so common? I mean, Joel's article was written in 2000. Eight years later (an eternity in technology) that article is still extremely relevant, but it's lesson has failed to penetrate mainstream thought. There's not enough industry focus on how best to approach legacy system enhancements. Many software development articles that garner the most attention focus on quality improvements delivered through innovations in technology - new programming languages, frameworks, APIs , architectures, and hardware. While that stuff's definitely important, they're relatively little help to applicat

I wish I was on board at the very beginning of the project I'm working on. Maybe it would shed some light on the direction the client is currently taking. This project is a rewrite of an existing, poorly performing, data processing system. The rewrite is being done in two parts. Phase 1 replaces the front half of the system - responsible for receiving messages, routing the transactions to the appropriate business logic, then finally, transmitting a response. Analysis (performed before I got here) identified this logic as the application bottleneck. This portion of the application was rewritten in JCAPS and it's currently being tested (I haven't seen any performance data for the rewrite yet). The second phase of the project replaces the business logic, currently written in C++, with BPEL . Let me say that again... the second phase of this project replaces compiled C++ with interpreted XML . For speed. Anyone else confused? Now maybe implementing the business

Almost every place I've worked struggles (in varying degrees) documenting business requirements. Maybe not the initial requirements, but the new requirements/enhancements that emerge as releases are delivered. They usually stem from a conversation that starts out, "I really like this, but it would be really cool if it could also do this other thing I had not thought of until now." This is a bigger than normal issue at the place I'm currently working. Mostly it's because new requirements are not captured in the same documents as the original specification. Instead, a new document is created and placed into a shared folder on the network (or sometimes a series of different folders). Over time, there are a lot of distributed requirement documents and it's really difficult to figure out what the system is supposed to do (and where to look for this information). Please, place all your application requirements in a single coherent "document"! Make

We've had some interesting SOA desing questions lately. Here's a quick rundown with my thoughts... Is it a good idea to wrap DB calls in a web service? Some argue that this is a waste for internal applications. That these services don't provide any business value - query results are simply regurgitated back to the caller. While I agree that these calls don't add much business value, the benefit lies in abstracting the DB calls from the caller. In simplest terms, wrapping access means that callers need not concern themselves with managing database connections. Additional changes/enhancements to the schema can now be handled in a single place rather than mandated enhancements to DB clients - even the DB implementation, location, and authentication updates are transparent to users. To me, services like this - services that simplify interactions - are a big part of what SOA is all about. As SOA systems evolve/extend, is it a better idea to plug in new functionality or

In another discussion recently about SOA , it still surprises me a little that people, technical people, don't get that there's not much new here. For years it's been standard practice to separate functionality into functions, classes, and modules. The idea has always been that these smaller, highly specialized components are easier to share and maintain than monolithic blocks of code. Functionally, SOA is not much different. The goals are the same - reusability and easy maintenance. The biggest difference - in the case of a web service SOA - is that the shared library included in your application is replaced with an HTTP call. If you're already supporting message-oriented applications using MQ or JMS , these messages are now HTTP requests. The process of decomposing the application into reusable services is essentially the same. The real point here is, if you already have a modularized architecture and you're having problems with application crashes, a swi