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...

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...

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...

Come hell or high water - this company is hell bent on including JCAPS as part of it's enterprise architecture, even though it doesn't plan to use any of the features that might set it apart from it competitors or open source alternatives. The long-term plan here is for the business users to use a BPMN-compliant tool (not the one from JCAPS) to create the business processes. These processes will integrate web service calls, creating a sort of business mashup of these services. The services will be written in .Net, not JCAPS. The only place JCAPS enters the equation is as the platform to run the BPEL generated from the BPMN. Make any sense? Not to me. Isn't a BPEL engine included in Glassfish? I'm sure this is just one of several free or low cost alternatives to execute BPEL. What I can't figure out is this company's infatuation with JCAPS. Given the shortcomings they've encountered already, why they are so intent on looking for more places to impleme...

I'm back at JCAPS training this week. This time the focus is on the eInsight Business Process Manager . eInsight is the JCAPS architecture layer used to combine web services. The services are connected using BPEL which is an XML-based language to define business processes. The latest version of NetBeans also includes a BPEL tool, and I'm anxious to see how they compare. We have some time scheduled at the end of the formal training to explore some of the JCAPS problems we've been experiencing. In addition to the problems I've already outlined with the repository . I'm hoping we can also explore the following: Lately, we've seen some weird behavior where things that were previously working stopped. The errors in the logs don't seem to make any sense. At first we thought it might be due to some code that was copied to a different location, but I've seen this problem where no code was copied. The only remedy we've found is to recreate both the...

In the midst of a job change, I've been spending most of the last few weeks handing my work off to others and writing some final documentation. With that almost complete, I'm turning my attention to my new position where I'll be working to integrate systems together in a Service Oriented Architecture (SOA). While I have SOA experience (creating & integrating web services as well as CORBA modules) my new company has chosen the Java Composite Application Suite (JCAPS) as it's SOA platform. It's (by far) the most comprehensive SOA solution I've had opportunity to work with. I'm really excited to get started. Here are some things I really like about the architecture and questions I have. The system is built on an application server and includes things like messaging, as well as consolidated user management and role based access built in. This is a big change from my current situation where I've needed to integrate (and implement) a lot of this f...