CCF-to-J2C Architecture Migration

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

descriptor.

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

J2CA connectors.

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

WSDL-described Services.

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:

http://ws.apache.org/wsif

WSDL

J2C

port

address

operation

binding

input msg

input msg binding

output msg

output msg binding

Connection

ConnectionFactory

Interaction

InteractionSpec

Record

Streamable.write

Record

Sreamable.read

hjkjhkh

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

are:

򐂰 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

structure)

򐂰 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

WSDL

Definition

SOAP

java

IMS

JMS

Services

Service

Proxy

Application

Client

Service Specific binding protocols

WSIF

Se

r

vic

e

P

r

o

v

i

d

e

r

s