The Web Services Invocation Framework (WSIF) is an architecture and
programming model that - unlike today's most popular Web services APIs,
JAX-RPC and JAXM - supports RPC and messaging invocation of Web services in a
single programming model.
In Part 1 of this series I introduced WSIF and described its architecture and
programming model. In this article I will discuss more advanced topics of
WSIF programming, such as usage of different providers, JNDI bindings,
asynchronous service invocation, and messaging.
Using the EJB Provider
After creating the basic Web service implementation, I attempted to use the
same WSIF client code (see Listing 2) for EJB transport. Note: All of the
code for this article can be downloaded from
www.sys-con.com/websphere/sourcec.cfm. The only required change for switching
from SOAP/HTTP communications to a straight EJB invocation was a ch... (more)
In Part 1 of this series, we discussed how the use of messaging software can
alleviate some of the problems with integration of J2EE and .NET environments
using Web services. In this article we will discuss implementation of the
proposed architecture on both J2EE and .NET platforms, along with possible
enhancements of the proposed solution.
All of the code referenced in this article is available for download from
www.sys-con.com/websphere/sourcec.cfm.
Implementing the .NET Client
Although support pack MA07 supports all the basic functionality of WebSphere
MQ and is implemented ba... (more)
Today's most popular Web services APIs - JAX-RPC and JAXM - support two very
different programming models for invocation of Web services, one synchronous,
one asynchronous. If users need both models in a single application, they are
forced to use two sets of very different APIs. This article, the first of a
two-part series, describes an architecture and programming model - the Web
Services Invocation Framework (WSIF) - that provides a single set of APIs
that supports both models.
JAX-RPC, which is currently part of J2EE and consequently is a mandatory
implementation for all J2EE... (more)
It is today's reality that most companies are using both J2EE and .NET
environments for their software implementation. Until recently, the prevalent
solution for integration of these two environments has been HTTP-based Web
services.
Although this solution works well in many cases, it suffers from the
following drawbacks:
1. Most implementations today are synchronous and based on the synchronous
nature of the underlying HTTP protocol.
2. Reliable messaging is difficult to implement using HTTP.
3. Load balancing in an HTTP-based environment requires a client-side
load-balancing ... (more)
Over the past several years EJB technology has entered the software
development mainstream. This new level of recognition and greater popularity
brings an increase in design activities in the EJB space, such as best
practices and design patterns.
Most of the EJB design practices created so far are aimed at improving the
overall performance of EJB-based applications. It turns out that the majority
of these practices were taken directly from object-oriented development (OO)
and moved to the realm of EJB design, without consideration for the specifics
of EJBs. This article emphasiz... (more)