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:
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:
The answers to these questions can definitely be taken in a lot of directions, even once a programming language choice is made.
Here's a common Java-based technology platform that I've seen for rapid, low-cost development. Java's large ecosystem means ready access to a wide range of add-on open source (Apache has plenty) or commercial technologies.
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.
]]>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.
This was and continues to be a shame. Matching of inbound URIs comes up frequently on the server-side application, and there may be middleware processing an inbound request and determining where to dispatch it. In the cases of bridging legacy interfaces to REST-style interactions, this dispatching process is very mechanical, but there needs to be a description that's consumable by a runtime. The original URI templates spec seemed to provide almost enough for a simple approach to specifying this the URI to match, but not quite:
So, applying a few restrictions gives a fairly simple but powerful matching template, which can be automated by infrastructure fairly easily:
http://foo.com;{mybool}, where mybool would be true for the match http://foo.com;mybool.With these restrictions, the basic concept of URI templates can be applied to matching. This is powerful enough to handle the majority of RESTful URI constructions that are commonly used. While the second draft of URI templates took the focus of URI templates in the direction of substitution, there's no reason that these approaches couldn't be combined and strengthened to address the matching problem. This would require some changes to how substitution operators are specified today or a flavor matching operators could be introduced.
]]>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.
]]>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.
Next, the follow is included to enable DOJO widget debugging:
<!-- Enable client-side dojo debug by enabling server-side tracing -->
<!-- for at least Level.FINE on <%= logger.getName() %> -->
<%-- Prepare the djConfig object for DOJO bootstrapping --%>
<script type="text/javascript">
djConfig = { isDebug:
<%= logger.isLoggable(Level.FINE) %>
};
</script>
Based on the selected debugging level, this enables client-side debugging in the browser, using the same tracing subsystem as is typically used in WAS. This gives a familiar way to introduce debugging of this capability without having to introduce an additional mechanism to configure debugging.
]]>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 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:
public class Foo {
private static Foo instance = null;
public static Foo getInstance() {
if (instance != null) {
synchronized(Foo.class) {
if (instance == null) {
instance = new Foo();
}
}
}
return instance;
}
}
This code is broken, because the JVM does not provide atomicity guarantees on non-primitive 32-bit values such as object references, and 64-bit values such as longs or doubles. However, the JVM memory model does provide atomicity for 32-bit primitives, such as ints, floats, or booleans. Double-checked locking will work with these. So, you should be able to write the code above as follows:
public class Foo {
private static boolean initialized = false;
private static Foo instance = null;
public static Foo getInstance() {
if (!initialized) {
synchronized(Foo.class) {
if (!initialized) {
if (instance == null) {
instance = new Foo();
}
initialized = true;
}
}
return instance;
}
}
This approach works on hardware architectures like Intel, Solaris, etc. All these platforms have stronger memory model guarantees than Java's. However, there is still a theoretical concern that some future processor architecture may not provide sufficient read coherency to support this memory model. This is discussed here..
Now, as of JSR133, which you should definitely have if you're running on Java 1.5, you should be able to use the volatile keyword to achieve this more simply. In addition, the adjustment to the Java memory model should fix any of the theoretical doubts of the approach above.
public class Foo {
private static volatile Foo instance = null;
public static Foo getInstance() {
if (instance != null) {
synchronized(Foo.class) {
if (instance == null) {
instance = new Foo();
}
}
}
return instance;
}
}
The volatile keyword causes writes/reads to go directly to main memory, rather than the cache. This avoids the cache coherency problem that prevented the double checked locking from working on multi-processor systems. While this approach fixes the double locking technique to work with instances, it still comes with some overhead: the value of the instance variable can no longer be cached and must be fetched from memory every time. This is similar in cost to a partial synchronization.
Of course, the fastest thing is just to do static eager initialization, which gets run once in a single thread by the class loader when loading the class. However, this approach may not always be possible, particularly in an application server environment where certain resources may need to be bound to at runtime. Of course, you can't go wrong with synchronization. But in many casts, this technique can be used to achieve cost savings for critical code paths when run on the usual platforms.
]]>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.
In addition to hiding I/O, iterators can also be used for generation of data as needed. Rather than corresponding to an actual collection of data, each call to the iterator's next method computes the data to be returned. This data may be based on the state of the iterator itself (for example, a key stream), or may be based on other server state. I/O may also be viewed as generational in nature, where each advancement of the iterator pulls more input. The idea being that only the input that's needed is kept in memory (although read ahead would be needed for performance). This is the approach taken in the JDBC APIs for processing result sets. This concept is closely tied to parallelization of I/O.
The abstraction of the iterator and streams approach allows for staged development. The first version of the API need not implement parallelization or generation. It can be added later, transparent to the application. It may also turn out that the particular use case for the API does not warrant such implementation complexity. Still, a pull based design can serve as a point of future extensibility should the performance gains become worth it.
A decision point may be the size of the chunks of data being processed. For example, the SOAP attachment support extensions that were included with the TWSS product assume a certain range of SOAP attachment sizes that correspond to typical service provider usage around Multimedia Messaging Service (MMS). Such attachment sizes are typically on the order of 150-300k, as they are destined to mobile devices with limited bandwidth, memory, and processing. Thus, the implementation complexity for parallelization wasn't worth it for the first round of the API. However, as service provider use cases evolve and attachment sizes grow, such as in support of full blown MP3s, parallelization can have significant benefits for attachment processing.
So the caveat for this design approach is that it is not a substitute for the power of asynchronous APIs. However, all this can occur without the application being aware of this fancy parallelization using a straight-forward synchronous processing logic. Then to scale in throughput, you can scale up in terms of processing threads, where each thread can handle a different data stream simultaneously. Clearly this approach scales nicely on multi-processor and multi-core systems for heavily multi-threaded apps.
It used to be that a disadvantage to this approach is that type safety was lost. The object returned by the iterator would need to be cast to the appropriate type, and this could only be specified by contract in the API. For some, this could be deemed a liability. Support for generics in Java 1.5 solves this problem by allowing for incorporating typing into the interface -a feature that makes the use of iterators in an API much more attractive.
]]>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.
]]>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.
As an example, consider a piece of data that identifies a customer. The customer has the following attributes:
- ID: The customer identity. This uniquely identifies the customer.
- name: The customer's name.
- balance: The customer's balance.
- enabled: Whether this customer is enabled/disabled.
Consider a set of interactions that allow you to create, update, query, and delete a customer. Often times, a temptation is to design the interface as follows, trying to duplicate the smaller methods for a Java interface (Java syntax used below for convenience in expressing operation signatures):
void createCustomer(String id, String name, String contact, String balance);
void updateName(String id, String name);
void updateBalance(String id, int balance);
void setEnabled(String id, boolean status);
String getName(String id);
int getBalance(String id);
boolean getEnabled(String id);
void deleteCustomer(String id);
Here's how that can be converted to using the DTO pattern and simplifying the interface using WSDL/schema. Consider a schema type for customer that looks as follows:
<xsd:complexType name="Customer">
<xsd:sequence>
<!-- ID is never optional -->
<xsd:element name="id" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<!-- Name is optional -->
<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
<!-- Balance is optional -->
<xsd:element name="balance" type="xsd:int" minOccurs="0" maxOccurs="1"/>
<!-- Enabled is optional -->
<xsd:element name="enabled" type="xsd:string" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complextType>
The ID is always needed to identify the customer, so it is non-optional in data object. We can now rewrite the operation signatures as follows with the implied contracts:
// All optional fields are filled in during creation, unless they
// are meant to be null on the data object
void createCustomer(Customer data);
// The non-optional ID uniquely identifies the customer. If any of the other
// elements are present, then they are updated in the underlying object.
void updateCustomer(Customer data);
// Fetch all customer information
Customer getCustomer(String id);
// Deletes a customer
void deleteCustomer(String id);
This simplifies the number of operations that are needed to interact with a customer and minimizes the number of request response changes. This approach also allows the client to reuse object instances. The output of a get can be fed back into an update with a single field changed. The update is also flexible, providing the equivalent of updating multiple fields simultaneously when appropriate. While this step may seem somewhat obvious to some folks, it is an important predecessor to the next pattern.
Do More at Once:
It's better to batch multiple operations in a single call, rather than performing an invocation for each individual customer object. This amortizes the cost of the remote hop over multiple operations, improving throughput and responsiveness. First, we add an additional useful operation to our running customer example: the ability to validate customer information against what's stored in the underlying service. This operation looks as follows:
boolean validateCustomer(Customer somebody);
Typically these operation signatures would also have exceptions -or in WSDL parlance "faults" -that are raised in the advent of error while executing the operation. Let's assume each of the above methods throw an exception like this:
boolean validateCustomer(Customer somebody) throws MyServiceException;
To enable batching, we allow each operation to take in an array of customer data objects to operate on. But we can't leave our exception/fault scheme as-is. Raising a single fault from the Web Service invocation means that we have an ambiguous situation to resolve: what happens to the items that were updated while traversing the list when we stopped? Were they rolled back or persisted up to that point? And how do we identify where we succeeded? This can be resolved by introducing a new data object:
<xsd:complexType name="FaultStatus">
<!-- A container for our service exception fault -->
<xsd:element name="fault" type="somens:MyServiceException" minOccurs="0" maxOccurs="1"/>
</xsd:complexType>
Now we change our previous methods to return a list of fault status objects instead of raising a single fault exception. We need a container object for our fault so as to preserve the position of the result in the returned list. This pattern looks as follows for each of our method signatures:
FaultStatus[] createCustomers(Customer[] data);
FaultStatus[] updateCustomers(Customer[] data);
Customer[] getCustomers(String[] id) throws MyServiceException;
FaultStatus[] deleteCustomers(String[] id);
Boolean[] validateCustomers(Customer[] somebodies) throws MyServiceException;
Note that getCustomers() and validateCustomers still throw the single exception. This is because they don't update anything and thus do not suffer from the ambiguous situation. This is also what we want from the interface, which is to return the appropriate type.
Reuse Data Object:
Finally, where possible, reuse common data as sub-objects in larger objects. Ultimately this will improve cohesiveness of your interface, making it easier to supply information from one part to another. Schema makes these easy to do by embedding types as elements within larger types. Suppose in our example above that each balance had associated with it an account. Then we would have been better off using the following data model:
<xsd:complexType name="Balance">
<xsd:element name="account" type="xsd:string">
<xsd:element name="amount" type="xsd:int"/>
</xsd:complexType>
<xsd:complexType name="Customer">
<xsd:sequence>
<!-- ID is never optional -->
<xsd:element name="id" type="xsd:string" minOccurs="1" maxOccurs="1"/>
<!-- Name is optional -->
<xsd:element name="name" type="xsd:string" minOccurs="0" maxOccurs="1"/>
<!-- Enabled is optional -->
<xsd:element name="enabled" type="xsd:string" minOccurs="0" maxOccurs="1"/>
<!-- Balance is optional -->
<xsd:element name="balance" type="somens:Balance" minOccurs="0" maxOccurs="1"/>
</xsd:sequence>
</xsd:complextType>
Now consider we had an operation with the following operation signature that updates account balances:
FaultStatus[] updateBalance(Balance[] balances);
We could now call getCustomers() to get a list of customer information. We can then reuse the object instances in each customer's balance as input to the updateBalance() method, whereby we could tweak balances before updating. The client-side logic would then be simple: it would iterate through customers looking for balances to update and append updated balance objects to a list. This list would service as the input to the update balance operation.
Wrapping it up
Use of these three guidelines greatly simplifies Web Service interacts. The patterns in these guidelines can be repeatedly applied during interface design in order to achieve the minimum number of interactions and the best cohesiveness between different operations. A side effect of applying these patterns is that this will also simplify client-side (and even possibly server-side) code. A lot of error cases disappear when it is no longer possible to prove partial updates or provide recovery for each fine grained operation.
]]>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.
Here's my shot at what I think is a simple way to explain the value of a Web 2.0 strategy to a business. The essence of Web 2.0 is about three things:
So that's it. Cutting through all the technology, hype, and jargon, those three words seem to capture what Web 2.0 is all about. And of course, they build on one another. The consumability serves to enable more agile marketing. Once the shift of control is in the hands of the marketing folks, they are free to be creative and create new user experiences. It's the user experience that people pay for.
]]>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:
Each of these points is a potential point for substitution of service. Based on pricing, location, terminal capabilities, a customer may decide to switch from the current service provider -and customers are finding themselves more than ever presented with choice. As such, Fixed Mobile Convergence ends up being a key unification of all the recent disruptions to the telecommunications industry and thus, sits at the nexus.
]]>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.
]]>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.
So back to getting up and running with converged web services. Today's most common paradigm for having Web Services in a J2EE environment is based on JSR109 JAX RPC specification. Some tooling parses the WSDL (WAS provides a tool called WSDL2JAVA) and generates either client-side or server-side stubs for packaging in the application. The service developer then inserts his or her code into the "BindingImpl" piece of the server-side stub. The goal of JSR109 was to isolate the developer from the details of Web Service interactions and provide them with an environment that looks a little more like Java. So, a little extra knowledge is required to enable a JSR109 binding to work with converged HTTP/SIP communications.
The following is a code example that shows you how to get access to SIP facilities and converged information from a JSR109 Web Service stub.
...
import javax.xml.rpc.server.ServiceLifecycle;
import javax.xml.rpc.server.ServletEndpointContext
...
public class MyServiceBindingImpl
implements MyService, // This is base interface that represents the WSDL interface in Java
ServiceLifecycle { // This allows you to access container information
private ServletEndpointContext endptCtx = null;
private SipFactory sipFactory = null;
/**
* This method is called before each invocation by the JAX RPC runtime as part of the
* ServiceLifecycle interface. The API says to cast the context to a
* ServletEndpointContext object inside init. This lets you get at web container facilities.
*/
public void init(Object context) throws ServiceException {
endptCtx = (ServletEndpointContext)context;
ServletContext srvCtx = endptCtx.getServletContext();
sipFactory = (SipFactory)srvCtx.getAttribute(SipServlet.SIP_FACTORY);
}
/**
* Also part of ServiceLifecycle interface.
*/
public void destroy() {
}
/**
* This gets you access to the shared application session parent object of the
* HTTP session and corresponding SIP sessions.
*/
private IBMApplicationSession getIBMApplicationSession() {
IBMSession session = (IBMSession)endptCtx.getHttpSession();
IBMApplicationSession appSession = session.getIBMApplicationSession();
return appSession;
}
/**
* This may seem a little more familiar.
*/
private SipApplicationSesion getSipApplicationSession() {
return (SipApplicationSession)getIBMApplicationSession();
}
public void myOperation(String someArg) {
// Access the SIP factory if needed via the private member. This lets you
// create new SIP messages.
// Get at the SIP application session to see inter-protocol state information
SipApplicationSession appSession = getSipApplicationSession();
// Do good things
}
}
This code example shows how to do two things from the Web Service side: (1) Get at the SipFactory object which is one entry point into the SIP Servlet API function. (2) Access application level information from within the SipApplicationSession. In addition, the SipApplicationSession lets you find session instances from both HTTP & SIP protocols.
However, a caveat: converged services require that the Web Service client maintain some state information in order to refer to the converged session (this makes sense - you have to find the session somehow). There are two ways of doing this: maintaining the HTTP session information between Web Service calls using cookies or URL rewriting, and encoding Web Service URIs with application session IDs. Maintaining HTTP session information can be accomplished by setting the javax.xml.rpc.Stub.SESSION_MAINTAIN_PROPERTY property on the client-side stub. URI encoding requires that the converged service return a the original endpoint URI of the Web Service with a special identifier encoded as a parameter in the URI. The Web Service client then needs to know to set that URI as the subsequent endpoint for its communications.
Some folks dislike this approach because it breaks the stateless model that is traditionally Web Services and increases complexity at the client. One way to get around this is to introduce a correlator within the Web Service interface. Then a fronting Web Service server stub can receive the request, extract the correlator, and use the correlator to determine the appropriate encoded URI to use to find the appropriate converged session. This last approach comes at the cost of increased latency for each invocation of the service. Such an approach may even require a database lookup to find the appropriate information to dispatch the request to the real handler of the service. Regardless of the approach used, there still has to be some tidbit of information that relates the request to the session.
]]>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.
]]>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.
For those not familiar with Portlets, think of a Portlet as providing the graphical content for a portion, or visual unit, of a web page. The Portlet's sole responsibility is to render that unit of display for the page. Page content is assembled through a process called aggregation; each page has a notion of layout (typically expressed either as a JSP or in XML format) and a Servlet-like method on each Portlet is invoked by the container in order to render each piece of the aggregated page. The bare-bones Portlet container provided with WAS 6.1 does not provide aggregation capabilities. This must be done by a fronting JSP or Servlet. More advanced Portlet containers provide other capabilities, such as navigation between pages of content, filtering of content according to user roles, and even personalization of content.
The basic idea behind Portlet approach (as for many other similar systems, including the Drupal system used for this blog is a sort of UI componentization, allowing reuse of visual content and function, and promoting separation in the backing code. Portlets are intended to be mixed and matched to construct page content, either directly by the users or by the administrators of the page. Sometimes, Portlets are provided in groups that are intended to work together to provide more advanced visual display. This approach still allows the user to have control of layout and visual elements via the Portlet container, and still promotes reuse of content and capability in the code.
So, how to enable AJAX techniques with JSR168 Portlets? The best article I've found on the subject is from the a Sun Developer Network article. Here's a summary of the technique described in the article: each Portlet has an associated HTTP Servlet component that handles the AJAX communication. On load of the page, content is aggregated or generated using the usual Portlet techniques. The generated content typically has some visual element, such as a button, or Javascript code that calls the AJAX function which makes an XML HTTP request to the Servlet. The Servlet then typically sets some context information in the HTTP session based on the Javascript request before dispatching the request directly to the JSR168 Portlet code in order to render the dynamic content. The implementation architecture looks like this:
Reproduced from Greg Ziebold and Jai Suri's article
This technique is an excellent way to approach inter-Portlet communication in a Portable manner. It pushes the coupling of the Portlets out to the client, rather than relying on non-standardized Portlet techniques. In addition, it avoids requiring a page refresh when one Portlet updates another. An example of inter-Portlet communication might be when you have one Portlet that serves a filter for the content in another. Perhaps this was done to allow reuse of the filter UI on multiple pages. When the user updates the filter, it can result in an AJAX request that applies the new filter to the other portlet on the page, without requiring a page refresh. In addition, it also preserves portability between containers.
]]>