Michael Gilfix Online

This is the first post for my new tech blog while I set up my new website. This blog will discuss various tech-related topics of my interest. These topics will likely range in specificity to certain implementation related issues, to architectural issues, and other tech industry related topics.

But first, a bit about me. In my day job, I work as a product architect in IBM's software group in the telecommunications industry. I currently work on a product called the Telecom Web Services Server. Of course the usual disclaimer: the posts here do not represent the opinions of my employer in any way, shape, or form, and are solely my own. However, my job tends to produce lots of interesting tidbits about J2EE, telephony technology, and other industry trends.

This is also my first foray into the world of blogging. Comments/suggestions welcome.

Oh, and for those interested: this site was created using the drupal content management system: http://www.drupal.org. Some very cool software written in PHP. I've found it to be very straight-forward, flexible, and customizable. Very useful for the advanced web designer or small/medium business web site.

As Web Service component models become more prominent (thanks to the push for Service-Oriented Architecture (SOA) style of design), more and more J2EE applications are starting to contain dynamic client-side Web Services that link together many SOA capabilities. Such applications make use of dynamic Web Services in that the endpoints for the Web Service are only known at runtime -perhaps as a result of user profile information or dynamic configuration.

The most common and widely used way to perform Web Service client invocations is through the use of a stub, using the model described in JSR 109. An auxiliary tool, such as WSDL2JAVA, is used to read the WSDL description of the Web Service interface and generate Java code that can be used to call the Web Service. This code presents itself to the user in the form of a Stub, which is a piece of code whose interface hides the entry point into the Web Services runtime used to make the actual invocation. Typically, the stub contains operations and arguments that map between XSD schema types and Java types; the idea being to hide the details of the Web Service invocation infrastructure from the programmer. Note: some of this will be alleviated by the new JAX WS specification for Web Services, described in JSR 224.

I've found that time and time again, when developing on top of application servers and frameworks, that many developers do not fully understand the threading model that they are working in and its implications. In a larger development shop, this can be difficult to catch until late in the development process. Typically, the design of the component in question is sound (and goes through the review process), but the implementation architecture (structuring of the code) does not consider these details. The problem is too close to the code and typical unit testing does not simulate a multi-threaded environment. These problems tend to be discovered either through code review or at the start of system test (functional test also typically tests one thread of execution), both of which tend to happen later in the cycle -particularly on projects with tight schedules and resources and which project doesn't fall into that category?

Once discovered, these problems are fixable, but typically the solution is of lower code quality than had the code been written with multi-threading in mind in the first place. By lower code quality, I mean that the code tends to exhibit higher defects and often times lower performance. For example, a developer keeping multi-threaded code would try to reduce the number of locks acquired and time the locks are held by consolidating update to state in a single location in the code in a particular path of execution. A developer unaware of the cost of synchronization (or that synchronization was even needed at all at first) might spread out the updates throughout the code. When the time comes to add locking, locks must be distributed throughout the code, typically resulting inefficient acquiring and releasing of the same lock. In addition to being more error prone, this code is also more difficult to maintain. When another developer takes over the code, it can be hard to surmise the concurrency strategy in the code and the effects of change.