Chapter 8. Comparing CCF to J2C Architecture 185
Depending on whether the application server or the application component is
responsible for managing the EIS sign-on, the RA allows the following options:
Container-managed sign-on: The application server provides the security
information to the resource principal using its specific security policy (such as
principal mapping). Then the application server requests the authentication of
the resource principal to the EIS itself or to the RA.
Component-managed sign-on: The application component provides the
security information and performs the EIS sign-on through the RA.
The RA specifies the security requirement of the underlying EIS in its deployment
Note that the CCF only provides a manually programmatic authentication
mechanism, but the J2CA features both a component-managed authentication
and a container-managed authentication model.
Table 8-3 compares security management interfaces for the two architectures.
Table 8-3 QoS transaction management interfaces: CCF versus J2CA
8.3.3 WebSphere Studio Enterprise Services, WSIF implementation
The IBM WebSphere Application Server 4.x runtime environment, together with
the WebSphere Studio 4.1 Unit Test Environment, supports the initial phase of
Versions 5.x of WebSphere Studio and WebSphere Application Server allow for a
full implementation of a number of J2CA-compliant resource adapters. The
runtime environment features a managed environment that offers the QoS that
was discussed in “J2EE Connector Architecture (J2CA)” on page 172.
J2CA resource adapter interactions with the EIS are delivered by the WebSphere
Studio 5.x development environment as enterprise services. These services are
designed to work with the Service Oriented Architecture (SOA), an application
architecture in which the services are defined using a descriptive language and
present a callable interface that participates in business processes.
The interfaces are neutral to any platform, and each Service is independent of
the others, the communication protocols, and the devices. This means that the
services can be accessed from any client (operating system and language). The
SOA is ideal in a Web Services environment, where Services are described by
the Web Services Definition Language (WSDL).
Service provided CCF 1.1 J2CA
Security services LoginInfo SecurityServiceManager
186 CCF-to-J2C Architecture Migration
Figure 8-10 shows how the J2CA architecture facilitates exposing connectors as
Figure 8-10 WSDL structure naturally fitting to the J2CA
To invoke Services, independence from the service binding protocol is required.
The enterprise services are implemented in WebSphere Studio 5.x via the Web
Services Invocation Framework (WSIF), an IBM proprietary framework that has
been donated to the Apache XML project.
The WSIF framework is a WSDL-based API for invoking Web Services,
regardless of how the Services are provided. This feature is achieved thanks to
protocol-specific code. While keeping the Service invocation abstract, the
providers are capable of managing the real message exchanges according to the
specifications of a given protocol.
WSIF ships with providers for local Java method calls for the EJB, JMS, and
J2CA protocols. This means that the J2CA-based Service can be defined as a
WSDL binding and that it can be accessed through WSIF using the same API as
a SOAP Service.
In Figure 8-11 on page 187, an Application Client makes WSIF Services calls.
Note: For a more detailed description of the WSIF framework, refer to the
Apache documentation at:
input msg binding
output msg binding
Chapter 8. Comparing CCF to J2C Architecture 187
Figure 8-11 Application Client access to WSIF calls
Rather than coding the WSIF API, the tools provided by WebSphere Studio 5.x
can be used to generate Service proxy classes directly from the WSDL Service
definition. The Application Client can then access the Service through simple
method calls on the Service proxy.
The generated WebSphere Studio/WSIF artifacts for a Service implementation
WSDL Service definition files
One or both of the following service proxies:
– A Java Service Proxy, generated from the WSDL Service definition
– An EJB Service Proxy, providing access to the EJB that was generated to
deploy the service
Messages (data beans that are the Java representation of the WSDL data
Format Handlers helper classes
The format handlers are Java classes that represent the link between the neutral
WSDL data structure representation and the Service provider specific format
Service Specific binding protocols