Michael Gilfix Online

I have a friend who recently joined a startup in San Fransisco, where they are looking to start development on a product in addition to their consulting business. This prompted a good conversation on what technologies to use when starting a product from scratch with a wide open playing field on choices. There's definitely no one-size-fits-all answer here; the technology choices will be influenced both by the needs/goals of the business and the nature of the application.

The interesting part of the conversation was identifying the questions / criteria to use in guiding the decision making. The answers to these questions definitely vary depending on the growth plans of the business (e.g., is the goal to scale to a big development shop? Is this a small auxiliary effort to a core business like consulting?). Technology choice is about investment. It's the foundation for building something that must be evolved and supported. In my friend's case, time-to-market, cost, productivity, and agility were necessities of the startup environment.

The following questions seem pretty helpful in guiding the decision making, regardless of the particulars of the technology:

• What skills do I have available right now?
• Do I have confidence that my technology choices will be able to meet the evolution of the business?
  • Will the application be able to scale?

OK, so I haven't posted in a long time. Figure I'll ease in with an issue that I wanted to write about a while back. Oh yeah, and I turned off comments because the spam was out of control :)

For those watching the REST space, I'm sure Joe Gregorio's work on the IETF URI templates draft is interesting. The initial draft (draft-gregorio-uritemplate-01.txt) took a simple approach to describe URIs with variable parts. The idea was that parameterized variable parts would have { var name } within the URI to indicate the variable parts. A simple example would look like this:

http://foo.com/accounts/{accountID}

where the account ID could be substituted with an appropriate ID in an instance of the REST URI:

http://foo.com/accounts/9991234

This approach was simple enough. It could be used in a straightforward manner when calling a REST service by substituting the variables parts with values prior to the invocation. It could also be used somewhat for matching inbound requests by transforming the template into a regular expression, replacing the variables with non-greedy matches.

In the process of updating the template specification, and despite many questions about matching inbound requests on the mailing list, Joe Gregorio stated that he never intended for URI templates to be used for matching but only for substitution. Indeed, the next version of the specification (draft-gregorio-uritemplate-02.txt introduced a bunch of new operators aimed at the substitution. The primary use cases that Mr. Gregario was interested in solving where client-side: simplifying the process of making a RESTful request from a JSP input form, for example, which would substitue the input form variables into their respective places in the REST request.

Here's a cool trick for structuring debugging of DOJO applications. This technique originated from Rhys Ulerich, who work in WebSphere Telecom Web Services Server development. Rhys is working on an interactive web-based console on top of WAS 6.1 for the much improved Service Policy Management Console in our upcoming release (targeted around October time frame). This technique allows you to enable debugging from the server side (via the app server facilities) of DOJO logic that executes client-side.

The technique has two elements to it that are embedded into the JSPs that render the console contents. These JSPs also render the appropriate DOJO widgets, JavaScript, and UI contents. First, the following is used to determine the trace logging:

<%@page import="java.util.logging.Level"%>
<%@page import="java.util.logging.Logger"%>
<%!
    //  "this" is the compiled JSP class for either
    //  a) ScriptPreamble.jspf if using jsp:include
    //  b) including JSP page, if using @include
    final Logger logger = Logger.getLogger(this.getClass().getName());
%>

As part of deployment, JSP contents are compiled into corresponding Java classes that are used to output the JSP contents. This can be done as part of deployment or through pre-compilation. This code snippet creates an instance of the Java logger class as part of the JSP generated class. As a byproduct, this will register the logger instance with the WAS trace logging subsystem as part of class loading.

Double checked locking is a useful paradigm for avoiding the cost of unnecessary synchronization and is often used in the context of avoiding synchronization during lazy initialization. The basic idea behind double checked locking is that you check variable condition first, and if the condition is not met, then synchronize, perform the check again, and adjust the condition. The second check inside the synchronized block typically serves to avoid repeating the actions that were used to satisfy the condition in the first time. There are quite a few articles on the web on this topic. However, some are incorrect, provide only partial information, or are quite complicated. This is an older, but enduring topic. So here's an attempt to distill it down.

The basic problem that double checked locking is trying to alleviate are conditions like this:

public class Foo {

  private static Foo instance = null;

  public static Foo getInstance() {
    synchronized(Foo.class) {
      if (instance == null) {
        instance = new Foo();
      }
    }
    return instance;
  }

}

Here, synchronization needs to occur for every fetching of an instance. This same pattern applies to any other lazy execution of static initialization that is undesirable to be repeated. The often cited and incorrect solution to this problem is code that looks as follows. This code implements a double-check locking approach to avoid synchronization of the typical execution path:

The use of iterators and streams in the design of an API/interface can be a powerful way to structure APIs for improved system performance, while maintaining simplicity for code that uses the API. These can be used to implement a design methodology, called "Pull Based" or "Pull" APIs. The basic idea behind a pull methdology is, rather than presenting the application code with an object model or a collection of state to be navigated or processed by the application, the application code asks for the data a piece at a time. Some variants of this design methodology allow the application to specify what kinda of data it is interested in, which can be used to push filtering into lower layers to improve performance.

The StAX (Streaming API for XML) is an example of a pull based API, which realizes significant performance gains. In the Telecom Web Services Server (TWSS) product, a pull based API was used to implement SOAP attachment extensions to the WebSphere ESB product. This approach was modeled after the pull based SAAJ SOAP attachment APIs.

The basic idea behind improving performance is to hide the I/O (network or disk) behind the abstraction of the iterator and stream objects. Application code can begin processing in parallel with reading from the network. This is done through the implementation of the API or underlying platform. Each call of the application code to the iterator will block until the data becomes available. As soon as a chunk of data is available, the application can process in parallel while the next chunk is read. If the application code is performing writing, then this mode of processing will form a pipeline. Output can be written as soon as input has been processed. For network based applications, this can be a useful means of processing large amounts of data with limited memory requirements, by pushing the stream of data into the network.

Using proper Web Service interface design can greatly improve application responsiveness and simplify integration logic. Poor design will not only bog down logic, but actually increase the complexity of both client and server-side implementation by requiring both to handle a larger number of possible error cases. This post attempts to capture three key patterns for designing/improving Web Service interfaces. While this article approaches the problem from the perspective of Web Services, many of these principles apply to Web Service design.

Appropriate Granularity:

The traditional interface design paradigms that folks are used to using in OOP and functional languages are often inappropriate for remote interfaces. They favor having many different methods that can be used to query information or state about an objects internals. This is particularly true for data objects. Since each query results in a remote interface invocation, querying information can quickly add up. A better approach is to use the Data Transfer Object (DTO) pattern that is heavily talked about in the concept of remote EJBs. The DTO is a data object that contains all queriable information in a single data object, which is transferred once. The cost of transferring more data in a single shot is marginal compared to the latency cost of going back and forth. This is particularly true for interfaces that allow you to create/update/query/delete data objects.

Incorporating Web 2.0 principles into application and service design is all the rage these days. A lot of people are still trying to wrap their head around what the whole Web 2.0 movement means. The short version is that Web 2.0 refers to a collection of technologies, architectural principles, and business principles. Some of the hottest items on the technology side seem to be Asynchronous Javascript (AJAX) based interfaces, Representational State Transfer (REST) architecture, Wiki's, blogs, and syndication. On the business side, the notion of combining existing assets in novel ways through Mashups, user driven content, and new models of product development. Still this hodgepodge that is Web 2.0 means many things to different people.

While online startups have adopted this model with great success, traditional businesses are still looking at defining and implementing their Web 2.0 strategy. Things just move a bit slower. The telecom service providers seem to be aggressively joining the fray. The problem is that amidst the shmorgasboard of things that are Web 2.0, it's difficult to find a simple, succinct explanation for what problems Web 2.0 really tries to solve that go beyond just the technology and just user driven content.

Fixed (to) Mobile Convergence (FMC) solution is a hot strategic item in today's telecommunications industry. Fixed Mobile Convergence refers to providing uninterrupted, continuous service while users switch between mobile and fixed line infrastructure access. The ability to offers converged fixed/mobile services is the key to conquering the increasing proliferation of 802.11 enabled mobile devices, hunger for high-bandwidth applications, ever-continuous demand of consumers for fair and efficient pricing, availability of communication services over plain old IP, etc. Basically, it's about enabling service delivery irrespective of location, access capability, and end device.

From a business perspective for the service provider, it's about keeping control of a customer's entire communication experience. The longer the service provider maintains control over that experience, the more revenue opportunity. While this may sound a bit alarming for the customer at first, the customer also stands to gain in terms of convenience through seamless service and more flexible pricing (typically, based on the economics of the access technology). Here are some observations along those lines:

• Emergence of 802.11 enabled devices: 802.11 is really only the tip of the iceberg, since WiMax and other larger area wireless technologies are on their way. This puts pressure on mobile operators and traditional fixed line providers, who now could be bypassed through pure data channels.
  

Work's been keeping me very busy lately. So, I plan on writing about a commonly asked question around the new converged HTTP/SIP capabilities in WebSphere Application server (WAS) V6.1. So first, what is a converged service? A converged service is an application that spans communication over multiple protocols to provide higher level function. In the case of the HTTP & SIP protocols, a converged service joins together session information from both protocols, allowing interactions over one protocol to influence communication over the other (subjects to the constraints of the protocol). WAS provides a Servlet programming model for both HTTP & SIP. Unification of those protocols is achieved though a converged web container solution, whereby sessions for both protocols may live in a single parent "application session" instance under the covers -the application session concept being first introduced as a SIPApplicationSession concept in the JSR116 SIP Servlet programming model.

The basic benefit to converged services? For SIP enabled applications, HTTP provides an ideal control protocol for communication with SIP signaling logic, which may participate in many different sessions, and may be constantly sending and receiving signaling messages asynchronously out the back-end. However, SIP also supports the notion of a basic request and response exchange, so what makes HTTP so ideal? First, you don't have to deal with the unreliability in SIP in a situation where decisive action is needed. But then enter Web Services. Central to Web Services is the notion of a Web Service Definition Language (WSDL) document that describes the structure of the request being issued. While you can always stuff a bunch of XML into an HTTP or SIP request to communicate with the application, WSDL provides the formal structure to allow you to communicate that interface to others. This approach also provides a path to interoperability with other programming stacks.

Most articles around use of AJAX and JSR168 Portlets tend to focus on how AJAX techniques can be used to provide more dynamic visual display capabilities to Portlets. However, AJAX techniques (particularly the use of XMLHttpRequest calls can be used effective to provide inter-Portlet communication in a portable manner. Let me explain what I mean by portable: Full Portlet containers, such as WebSphere Portal Server provide additional APIs beyond the JSR168 Portlet standard to enable inter-Portlet communications. These contains offer a lot of function, but come at the cost of heavier weight infrastructure. Increasingly, support for JSR168 Portlets are appearing in lighter-weight containers. For example, the release of WebSphere Application Server V6.1 last year included support for JSR168 Portlets embedded in web modules (WAR files) in J2EE applications. WAS supports a bare-bones Portlet container, sticking only to the JSR168 specification, and providing no means for inter-Portlet communication. Portlets that are written for WAS 6.1 are considered forward compatible, in that they can be deployed in WebSphere Portal. The converse is typically not true, since WebSphere Portal contains many features that go beyond the JSR. Use of AJAX techniques can provide a design that is both forward compatible between lighter and heavier weight Portlet contains, and should allow for portability between different Portlet containers.