JOnAS Platform Documentation JOnAS Platform Documentation

Table of Contents JOnAS Documentation...... 1

Java Open Application Server (JOnAS): a J2EETM Platform...... 4 Introduction...... 4 JOnAS Features...... 7 JOnAS Architecture...... 9 JOnAS Development and Deployment Environment...... 17 Clustering and Performance...... 18 Perspectives...... 20

Getting started with JOnAS...... 22 JOnAS Installation...... 22 Running a First EJB Application...... 23 More Complex Examples...... 25

Configuration Guide...... 30 JOnAS Configuration Rules...... 31 Configuring JOnAS Environment...... 32 Configuring the Communication Protocol and JNDI...... 33 Configuring the Logging System (monolog)...... 36 Configuring JOnAS Services...... 37 Configuring Registry Service...... 39 Configuring EJB Container Service...... 39 Configuring WEB Container Service...... 40 Configuring WebServices Service...... 41 Configuring EAR Service...... 42 Configuring Transaction Service...... 42 Configuring Database Service...... 43 Configuring Discovery Service...... 45 Configuring Security Service...... 46 Configuring JMS Service (not compliant with 2.1 MDBs)...... 46 Configuring Resource Service...... 47 Configuring JMX Service...... 48 Configuring Mail Service...... 48 Configuring DB Service (hsql)...... 51 Configuring Security...... 51 Configuring JDBC DataSources...... 63 Configuring Resource Adapters...... 68 Configuring JMS Resource Adapters...... 74 Common Parameters...... 84

i JOnAS Platform Documentation

Table of Contents J2EE Application Programmer's Guide...... 87 Target Audience and Content...... 87 Principles...... 87 JOnAS class loader hierarchy...... 89

EJB Programmer's Guide: Developing Session Beans...... 93 Target Audience and Content...... 93 Introduction...... 93 The Home Interface...... 94 The Component Interface...... 94 The Enterprise Bean Class...... 95 Tuning Stateless Session Bean Pool...... 97

EJB Programmer's Guide: Developing Entity Beans...... 99 Target Audience and Content...... 99 Introduction...... 99 The Home Interface...... 100 The Component Interface...... 102 The Primary Key Class...... 103 The Enterprise Bean Class...... 106 Writing Database Access Operations (bean−managed persistence)...... 111 Configuring Database Access for Container−managed Persistence...... 113 Tuning Container for Entity Bean Optimizations...... 117 Using CMP2.0 persistence...... 120

EJB Programmer's Guide: Message−driven Beans...... 143 Description of a Message−driven Bean...... 143 Developing a Message−driven Bean...... 143 Administration aspects...... 146 Running a Message−driven Bean...... 147 Transactional aspects...... 149 Example...... 149 Tuning Message−driven Bean Pool...... 152

EJB Programmer's Guide: Transactional Behaviour...... 153 Target Audience and Content...... 153 Declarative Transaction Management...... 153 Bean−managed Transaction...... 155 Distributed Transaction Management...... 155

ii JOnAS Platform Documentation

Table of Contents EJB Programmer's Guide: Enterprise Bean Environment...... 158 Target Audience and Content...... 158 Introduction...... 158 Environment Entries...... 158 Resource References...... 159 Resource Environment References...... 160 EJB References...... 160 Deprecated EJBContext.getEnvironment() method...... 162

EJB Programmer's Guide: Security Management...... 164 Target Audience and Content...... 164 Introduction...... 164 Declarative Security Management...... 164 Programmatic Security Management...... 165

EJB Programmer's Guide: Defining the Deployment Descriptor...... 168 Target Audience and Content...... 168 Principles...... 168 Example of Session Descriptors...... 169 Example of Container−managed Persistence Entity Descriptors (CMP 1.1)...... 171 Tips...... 173

EJB Programmer's Guide: EJB Packaging...... 174 Target Audience and Content...... 174 Principles...... 174

Web Application Programmer's Guide...... 175 Target Audience and Content...... 175 Developing Web Components...... 175 Defining the Web Deployment Descriptor...... 181 WAR Packaging...... 185

J2EE Connector Programmer's Guide...... 186 Target Audience and Content...... 186 Principles...... 186 Defining the JOnAS Connector Deployment Descriptor...... 186 Resource Adapter (RAR) Packaging...... 188 Use and Deployment of a Resource Adapter...... 188 JDBC Resource Adapters...... 190 Appendix: Connector Architecture Principles...... 191

iii JOnAS Platform Documentation

Table of Contents J2EE Client Application Programmer's Guide...... 193 Target Audience and Content...... 193 Launching J2EE Client Applications...... 193 Defining the Client Deployment Descriptor...... 195 Client Packaging...... 197

J2EE Application Assembler's Guide...... 199 Target Audience and Content...... 199 Defining the Ear Deployment Descriptor...... 199 EAR Packaging...... 201

Deployment and Installation Guide...... 203 Target audience...... 203 Deployment and installation process principles...... 203 Example of deploying and installing an EJB using an ejb−jar file...... 204 Deploying and installing a Web application...... 205 Deploying and installing a J2EE application...... 205

Administration Guide...... 207 jonas admin...... 207 JonasAdmin...... 207

JOnAS Commands Reference Guide...... 213 jonas...... 213 jclient...... 216 newbean...... 217 registry...... 219 GenIC...... 219 JmsServer...... 221 RAConfig...... 222 newjb...... 223 newjc...... 224

Creating a New JOnAS Service...... 226 Target Audience and Rationale...... 226 Introducing a new Service...... 226 Advanced Understanding...... 228

JMS User's Guide...... 231 JMS installation and configuration aspects...... 231 Writing JMS operations within an application component...... 232 Some programming rules and restrictions when using JMS within EJB...... 235

iv JOnAS Platform Documentation

Table of Contents JMS User's Guide JMS administration...... 238 Running an EJB performing JMS operations...... 240 A JMS EJB example...... 242

Ant EJB Tasks User Manual...... 247 New JOnAS (Java Open Application Server) element for the current JOnAS version...... 247 GenIC Ant Task...... 249

Login Modules in a Java Client Guide...... 252 Configuring an environment to use login modules with java clients...... 252 Example of a client...... 252

Web Services with JOnAS...... 254 1. Web Services...... 254 2. Exposing a J2EE Component as a Web Service...... 256 3. The client of a Web Service...... 261 4. WsGen...... 264

Working with Management Beans...... 266 Target Audience and Rationale...... 266 About JOnAS MBeans and their use in JonaSAdmin...... 266 Using JOnAS MBeans in a Management Application...... 266 Registering User MBeans...... 267

Domain Management in JOnAS...... 269 Target Audience and Rationale...... 269 Domain Management Goals...... 269 Mechanisms used by Domain Management...... 269 How to start manageable servers in a Domain...... 270

Howto: JOnAS Versions Migration Guide...... 272 JOnAS 4.3.x to JOnAS 4.4.1...... 272 JOnAS 4.1 to JOnAS 4.3.x...... 273 JOnAS 3.3.x to JOnAS 4.1...... 274 JOnAS 3.1 to JOnAS 3.1.4...... 275 JOnAS 3.0 to JOnAS 3.1...... 278 JOnAS 2.6.4 to JOnAS 3.0...... 279 JOnAS 2.6 to JOnAS 2.6.1...... 279 JOnAS 2.5 to JOnAS 2.6...... 280 JOnAS 2.4.4 to JOnAS 2.5...... 281 JOnAS 2.4.3 to JOnAS 2.4.4...... 281

v JOnAS Platform Documentation

Table of Contents Howto: JOnAS Versions Migration Guide JOnAS 2.3 to JOnAS 2.4...... 282

Howto: Installing JOnAS from scratch...... 284 J2SE SDK 1.4 installation...... 284 Ant 1.6 installation...... 284 Tomcat 5.5.x installation...... 285 Jetty 5.1.x installation...... 285 JOnAS installation...... 285 Setup...... 286

Howto: Installing the packaging JOnAS with a web container (JOnAS/Tomcat or JOnAS/Jetty) from scratch...... 287 J2SE SDK 1.4 installation...... 287 ANT 1.6 installation...... 287 JOnAS/Web Container installation...... 288 Setup...... 288 Starting JOnAS and running some examples...... 288

Howto: How to compile JOnAS...... 290 Target Audience and Rationale...... 290 Getting the JOnAS Source...... 290 Recompiling JOnAS from the Source...... 290 Recompiling the package JOnAS/Jetty/Axis from the Source...... 291 Recompiling the package JOnAS/Tomcat/Axis from the Source...... 291

Howto: Clustering with JOnAS...... 293 Architecture...... 293 Products Installation...... 295 Load balancing at web level with mod_jk or Enhydra Director...... 296 Session Replication at web level...... 302 Load Balancing at EJB level...... 304 Clustering databases with C−JDBC...... 305 Preview of a coming version...... 305 Used symbols...... 306 References...... 307

Howto: Usage of AXIS in JOnAS...... 308 Libraries...... 308 1. Unique Axis Webapp...... 308 2. Embedded Axis Webapp...... 309 3. Tests...... 309

vi JOnAS Platform Documentation

Table of Contents Howto: Usage of AXIS in JOnAS Tools:...... 309

Howto: Using WebSphere MQ JMS guide...... 311 Architectural rules...... 311 Setting the JOnAS Environment...... 312 Configuring WebSphere MQ...... 313 Starting the application...... 315 Limitations...... 315

Howto: Web Service Interoperability between JOnAS and Weblogic...... 316 Libraries...... 316 Access a web service deployed on JOnAS from an EJB deployed on Weblogic server...... 316 Access a web service deployed on Weblogic server from an EJB deployed on JOnAS...... 319

Howto: RMI−IIOP interoperability between JOnAS and Weblogic...... 321 Accessing an EJB deployed on JOnAS from an EJB deployed on Weblogic server using RMI−IIOP...... 321 Access an EJB deployed on Weblogic Server by an EJB deployed on JOnAS using RMI−IIOP...... 322

Howto: Interoperability between JOnAS and CORBA...... 323 Accessing an EJB deployed a on JOnAS server by a CORBA client...... 323 Accessing a CORBA service by an EJB deployed on JOnAS server...... 325

Howto: Migrate the New World Cruises application to JOnAS...... 328 JOnAS configuration...... 328 New World Cruise Application...... 328 SUN web service...... 329 JOnAS web service...... 331

Howto: Execute JOnAS as a WIN32 Service...... 335 Instructions...... 335 Files managed by create_win32service...... 336 Modify JOnAS Configuration...... 337 Testing configuration...... 337

Howto: Getting Started with WebServices and JOnAS 3.X...... 338 WebServices and J2EE...... 338 Early Integration of Axis in JOnAS 3.X series...... 338 How to use WebServices...... 338

vii JOnAS Platform Documentation

Table of Contents Howto: Distributed Message Beans in JOnAS 4.x...... 347 Scenario and general architecture...... 347 Common configuration...... 347 Specific configuration...... 348 And now, the beans!...... 349

Howto: install jUDDI server on JOnAS...... 351 I. UDDI Server...... 351 II. jUDDI Overview...... 351 III. How to Find the Latest Version...... 351 IV. Install Steps...... 352 V. Links...... 354

Howto: JOnAS and JORAM: Distributed Message Beans...... 356 A How−To Document for JOnAS version 3.3...... 356 JOnAS and JORAM: Configuration Basics...... 356 JORAM Topics and JOnAS Administration...... 357 The Solution...... 357 The Full Configuration...... 358 The JoramDistributionService...... 361 Maintaining the configuration...... 364 Conclusion...... 365

Howto: JSR 160 support in JOnAS...... 366 Target Audience and Rationale...... 366 What is JSR 160 ?...... 366 Connector servers created by JOnAS...... 366

Howto: Using the MC4J JMX Console...... 368 Connecting to the JMX server...... 368

Howto: JOnAS and JMX, registering and manipulating MBeans...... 369 Introduction...... 369 ServletContextListener...... 369 Configuration...... 373 Library Dependences...... 374 HibernateService Extension...... 374 Configuring RMI for use through a Firewall...... 376

How to configure and use xdoclet for JOnAS...... 378 Downloading and installing xdoclet...... 378 Ejbdoclet Ant target...... 378

viii JOnAS Platform Documentation

Table of Contents How to configure and use xdoclet for JOnAS Xdoclet tags...... 379

Howto: How to employ recovery in JOnAS...... 384 Transaction Recovery Overview...... 384 JOnAS Transaction Recovery...... 385 Implications of a Non−Conforming Resource Manager...... 385 JOnAS−JOTM Transaction Recovery Configuration...... 386 XA DataSource Configuration...... 387 Monitoring Executing Transactions...... 387 JOnAS Administrative Recovery...... 388 JOnAS Administrative Heuristic Recovery...... 391 HowTo setup a C−JDBC Database...... 395 Load Balancing with Enhydra Director...... 397

Migrating from mod_jk2 to mod_jk with embedded Tomcat...... 399

Setting up mod_jk2 with embedded Tomcat...... 403

Setting up mod_jk with embedded Tomcat...... 405

Using Enterprise Media Beans with JOnAS...... 408 What are Enterprise Media Beans (EMB)...... 408 EMB in JOnAS...... 410

How to Develop a J2EE−Compliant Web Service (endpoint + client)...... 428 Introduction...... 428 Server side...... 428 Client Side...... 435

ix JOnAS Documentation

1. White Paper 2. Getting Started ♦ JOnAS Installation ♦ Running a First EJB Application ♦ More Complex Examples 3. Configuration Guide ♦ JOnAS Configuration Rules ♦ Configuring JOnAS Environment ♦ Configuring the Communication Protocol and JNDI ◊ Choosing the Protocol ◊ Security and Transaction Context Propagation ◊ Multi−protocol Deployment (GenIC) ♦ Configuring the Logging System (monolog) ♦ Configuring JOnAS Services ◊ Configuring Registry Service ◊ Configuring EJB Container Service ◊ Configuring WEB Container Service ◊ Configuring WebServices Service ◊ Configuring Ear Service ◊ Configuring Transaction Service ◊ Configuring DataBase Service ◊ Configuring Security Service ◊ Configuring JMS Service ◊ Configuring Resource Service ◊ Configuring JMX Service ◊ Configuring Mail Service ◊ Configuring DB Service (Hsql) ◊ Configuring Discovery Service ♦ Configuring Security ♦ Configuring JDBC DataSources ♦ Configuring JDBC Resource Adapters ♦ Configuring JMS Resource Adapters 4. J2EE Application Programmer's Guide ♦ Principles ♦ JOnAS class loader hierarchy 5. Enterprise Beans Programmer's Guide ♦ Developing Session Beans ♦ Developing Entity Beans ♦ Developing Message−driven Beans ♦ Transactional Behaviour ♦ Enterprise Bean Environment ♦ Security Management

JOnAS Documentation 1 JOnAS Documentation

♦ Defining the Deployment Descriptor ♦ EJB Packaging 6. Web Application Programmer's Guide ♦ Developing Web Components ♦ Defining the Web Deployment Descriptor ♦ WAR Packaging 7. J2EE Connector Programmer's Guide ♦ Principles ♦ Defining the JOnAS Connector Deployment Descriptor ♦ Resource Adapter (RAR) Packaging ♦ Use and Deployment of a Resource Adapter ♦ Appendix: Connector Architecture Principles 8. J2EE Client Application Programmer's Guide ♦ Launching J2EE Client Applications ♦ Defining the Client Deployment Descriptor ♦ Client Packaging 9. J2EE Application Assembler's Guide ♦ Defining the Ear Deployment Descriptor ♦ EAR Packaging 10. Deployment and Installation Guide 11. Administration Guide 12. JOnAS Commands Reference Guide 13. Advanced topics ♦ Creating a New JOnAS Service ♦ Using JMS in Application Components ♦ Ant EJB Tasks User Manual ♦ Using Login Modules in Java Clients ♦ Web Services with JOnAS ♦ Working with Management Beans ♦ Domain Management in JOnAS 14. Howto Documents ♦ JOnAS Versions Migration Guide ♦ Installing JOnAS from Scratch ♦ Installing JOnAS−Tomcat or JOnAS−Jetty from Scratch ♦ How to Compile JOnAS ♦ JOnAS Clustering ♦ How to develop distributed message beans ♦ How to develop distributed message beans with JOnAS 4.1 ♦ How to Use Axis ♦ How to Use WebSphere MQ JMS with JOnAS ♦ Web Service Interoperability between JOnAS and Weblogic ♦ RMI−IIOP Interoperability between JOnAS and Weblogic ♦ Interoperability between JOnAS and CORBA ♦ How to Migrate the New World Cruises Application to JOnAS ♦ Execute JOnAS as WIN32 Service

JOnAS Documentation 2 JOnAS Documentation

♦ WebServices with JOnAS 3.X series ♦ Install jUDDI on JOnAS ♦ JSR 160 Support in JOnAS ♦ Using the MC4J JMX Console ♦ JOnAS and JMX: registering and manipulating MBeans ♦ Using JOnAS through a Firewall ♦ How to configure and use xdoclet for JOnAS ♦ How to configure and use transaction recovery for JOnAS ♦ How to develop a J2EE compliant Web service (endpoint + client) ♦ Using Enterprise Media Beans with JOnAS

Thanks to Bruno Bellamy for the JOnAS logo.

JOnAS Documentation 3 Java Open Application Server (JOnAS): a J2EETM Platform

Last modified at 2004−06−04, JOnAS 4.1

This document provides an overview of the JOnAS platform. The content of this document is the following:

• Introduction ♦ J2EE ♦ ObjectWeb • JOnAS Features ♦ System Requirements ♦ Java Standard Conformance ♦ Key Features ♦ JOnAS Packages • JOnAS Architecture ♦ Communication and Naming service ♦ EJB Container service ♦ WEB Container service ♦ Ear service ♦ Transaction service ♦ Database service ♦ Security service ♦ Messaging service ♦ JCA Resources service ♦ Management service ♦ Mail service ♦ WebServices service • JOnAS Development and Deployment Environment ♦ JOnAS Configuration and Deployment Facilities ♦ JOnAS Development Environments • Clustering and Performance • Perspectives

Introduction

Java Open Application Server (JOnAS): a J2EETM Platform 4 Java Open Application Server (JOnAS): a J2EETM Platform

J2EE

The SunTM J2EE specification, together with its related specifications ( EJBTM, JMSTM,...), defines an architecture and interfaces for developing and deploying distributed Internet JavaTM server applications based on a multi−tier architecture. This specification intends to facilitate and standardize the development, deployment, and assembling of application components; such components will be deployable on J2EE platforms. The resulting applications are typically web−based, transactional, database−oriented, multi−user, secured, scalable, and portable. More precisely, this specification describes two kinds of information:

• The first is the runtime environment, called a J2EE server, which provides the execution environment and the required system services, such as the transaction service, the persistence service, the Java Message Service (JMS), and the security service. • The second is programmer and user information explaining how an application component should be developed, deployed, and used.

Not only will an application component be independent of the platform and operating system (since it is written in Java), it will also be independent of the J2EE platform.

A typical J2EE application is composed of 1) presentation components, also called "web components" (Servlets and JSPsTM), which define the application Web interface, and 2) enterprise components, the "Enterprise JavaBeans" (EJB), which define the application business logic and application data. The J2EE server provides containers for hosting web and enterprise components. The container provides the component life−cycle management and interfaces the components with the services provided by the J2EE server. There are two types of containers; the web container handles Servlet and JSP components, while the EJB container handles the Enterprise JavaBeans components. A J2EE server can also provide an environment for deploying Java clients (accessing EJBs); it is called client container.

Introduction 5 Java Open Application Server (JOnAS): a J2EETM Platform

ObjectWeb

JOnAS is an open source application server, developed within the ObjectWeb consortium. ObjectWeb is an open source initiative which can be compared to Apache or Linux, but in the area of middleware. The aim of ObjectWeb is to develop and promote open source middleware software.

ObjectWeb is an International Consortium hosted by INRIA, officially founded in February 2002 by Bull, France Telecom, and INRIA. All software is available with the LGPL license.

The technical objective of this consortium is to develop a distributed component−based, middleware technology, in line with CORBA, Java, and W3C standards. The intent is to apply the component model, as already used at the application level in J2EE and in the CORBA Component Model, at the middleware level itself. The functional

Introduction 6 Java Open Application Server (JOnAS): a J2EETM Platform

coverage of ObjectWeb projects addresses naming, trading, communication (events, messages), availability and safety (transactions, persistence, replication, fault tolerance), load balancing, and security. Some related topics are also addressed, such as robustness, optimization, code quality, as well as benchmarks, tests, evaluations, demonstrators, and development tools.

Thus, the global ObjectWeb architectural model goes top down from applications (as benchmarks such as Rubis from the JMOB project) running on middleware platforms (such as JOnAS, OpenCCM or ProActive). The platforms are based on technical components such as Message−Oriented Middleware (JORAM which implements JMS), a communication framework (CAROL), a persistence framework (JORM), a database query framework (MEDOR), a transactional monitor (JOTM), an Object Request Broker (Jonathan). A technical component such as C−JDBC allows any platform to benefit from database clusters. JOnAS makes use of all these ObjectWeb components (JORAM, CAROL, Jonathan, JORM, MEDOR, C−JDBC, and soon JOTM), but also uses open source components from other communities, such as Tomcat or Jetty being used as a Web container, or for AXIS being used to provide the "Web Services" environment.

ObjectWeb already has a significant number of members: corporations, universities, individual members (individual membership is free). ObjectWeb members contribute to ObjectWeb orientations and participate in all ObjectWeb working groups, meetings, workshops, and conferences. The community of developers and users working with ObjectWeb components and platforms is constantly growing.

JOnAS Features

JOnAS is a pure Java, open source, application server. Its high modularity allows to it to be used as

• a J2EE server, for deploying and running EAR applications (i.e. applications composed of both web and ejb components), • an EJB container, for deploying and running EJB components (e.g. for applications without web interfaces or when using JSP/Servlet engines that are not integrated as a JOnAS container), • a Web container, for deploying and running JSPs and Servlets (e.g. for applications without EJB components).

System Requirements

JOnAS is available for JDK 1.4. It has been used on many operating systems (Linux, AIX, Windows, Solaris, HP−UX, etc.), and with different Databases (Oracle, PostgreSQL, MySQL, SQL server, Access, DB2, Versant, Informix, Interbase, etc.).

Java Standard Conformance

JOnAS supports the deployment of applications conforming to J2EE 1.4 specification. Its current integration of Tomcat or Jetty as a Web container ensures conformity to Servlet 2.4 and JSP 2.0 specifications. The JOnAS server relies on or implements the following Java APIs: EJB 2.1, JCATM 1.5, JDBCTM 3.0, JTATM 1.0.1, JMSTM 1.1, JMXTM 1.2, JNDITM 1.2.1, JAASTM 1.0, JACCTM 1.0, JavaMailTM 1.3.

JOnAS Features 7 Java Open Application Server (JOnAS): a J2EETM Platform

Key Features

JOnAS provides the following important advanced features:

• Management: JOnAS server management uses JMX and provides a JSP/Struts−based management console. • Services: JOnAS's service−based architecture provides for high modularity and configurability of the server. It allows the developer to apply a component−model approach at the middleware level, and makes the integration of new modules easy (e.g. for open source contributors). It also provides a way to start only the services needed by a particular application, thus saving valuable system resources. JOnAS services are manageable through JMX. • Scalability: JOnAS integrates several optimization mechanisms for increasing server scalability. This includes a pool of stateless session beans, a pool of message−driven beans, a pool of threads, a cache of entity beans, activation/passivation of entity beans, a pool of connections (for JDBC, JMS, J2EE CA), storage access optimizations (shared flag, isModified). • Clustering: JOnAS clustering solutions, both at the WEB and EJB levels, provide load balancing, high availability, and failover support. • Distribution: JOnAS works with several distributed processing environments, due to the integration of the CAROL (Common Architecture for RMI ObjectWeb Layer) ObjectWeb project, which allows simultaneous support of several communication protocols: ♦ RMI using the Sun proprietary protocol JRMP ♦ RMI on IIOP ♦ CMI, the "Cluster aware" distribution protocol of JOnAS ♦ Jeremie, the RMI personality of an Object Request Broker called Jonathan, from Objectweb. Used with Jeremie or JRMP, JOnAS benefits from transparent local RMI call optimization. • Support of "Web Services:" Due to the integration of AXIS, JOnAS allows J2EE components to access "Web services" (i.e., to be "Web Services" clients), and allows J2EE components to be deployed as "Web Services" endpoints. Standard Web Services clients and endpoints deployment, as specified in J2EE 1.4, is supported. • Support of JDO: By integrating the ObjectWeb implementation of JDO, SPEEDO, and its associated J2EE CA Resource Adapter, JOnAS provides the capability of using JDO within J2EE components.

Three critical J2EE aspects were implemented early on in the JOnAS server:

• J2EECA: Enterprise Information Systems (EIS) can be easily accessed from JOnAS applications. By supporting the Java Connector Architecture, JOnAS allows deployment of any J2EE CA−compliant Resource Adapter (connector), which makes the corresponding EIS available from the J2EE application components. For example, Bull GCOS mainframes can be accessed from JOnAS using their associated HooX connectors. Moreover, resource adapters will become the "standard" way to plug JDBC drivers (and JMS implementation, with J2EE 1.4) to J2EE platforms. A JDBC Resource Adapter is available with JOnAS, which provides JDBC PreparedStatement pooling and can be used in place of the JOnAS DBM service. A JORAM JMS Resource adapter is also available. • JMS: JMS implementations can be easily plugged into JOnAS. They run as a JOnAS service in the same JVM (Java Virtual Machine) or in a separate JVM, and JOnAS provides administration facilities that hide the JMS proprietary administration APIs. Currently, three JMS implementations can be used: the JORAM open source JMS implementation from Objectweb, SwiftMQ, and Websphere MQ. J2EE CA Resource Adapters are also available, providing a more standard way to plug JORAM or SwiftMQ to JOnAS.

JOnAS Features 8 Java Open Application Server (JOnAS): a J2EETM Platform

• JTA: The JOnAS platform supports distributed transactions that involve multiple components and transactional resources. The JTA transactions support is provided by a Transaction Monitor that has been developed on an implementation of the CORBA Transaction Service (OTS).

JOnAS Packages

JOnAS is available for download with three different packagings:

• A simple packaging contains the JOnAS application server only, without the associated Web Container implementation. To use it for J2EE Web applications, Tomcat or Jetty must be installed (with an adequate version) and it must be configured to work with JOnAS. • A JOnAS−Tomcat package contains both JOnAS and Tomcat, pre−configured, and with compiled examples. This is a ready−to−run J2EE application server. • A JOnAS−Jetty package contains both JOnAS and Jetty, pre−configured, and with compiled examples. This is a ready−to−run J2EE application server.

These packages also contain AXIS, thus providing pre−configured "Web Services" support.

JOnAS Architecture

JOnAS is designed with services in mind. A service typically provides system resources to containers. Most of the components of the JOnAS application server are pre−defined JOnAS services. However, it is possible and easy for an advanced JOnAS user to define a service and to integrate it into JOnAS. Because J2EE applications do not necessarily need all services, it is possible to define, at JOnAS server configuration time, the set of services that are to be launched at server start.

The JOnAS architecture is illustrated in the following figure, showing WEB and EJB containers relying on JOnAS services (all services are present in this figure). Two thin clients are also shown in this figure, one of which is the JOnAS administration console (called JonasAdmin).

JOnAS Features 9 Java Open Application Server (JOnAS): a J2EETM Platform

Communication and Naming Service

This service (also called "Registry") is used for launching the RMI registry, the CosNaming, the CMI registry, and/or the Jeremie registry, depending on the JOnAS configuration (CAROL configuration, which specifies which communication protocols are to be used). There are different registry launching modes: in the same JVM or not, automatically if not already running. CAROL enables multi−protocol runtime support and deployment, which avoids having to redeploy components when changing the communication protocol.

This service provides the JNDI API to application components and to other services in order to bind and lookup remote objects (e.g. EJB Homes) and resource references (JDBC DataSource, Mail and JMS connection factories, etc.).

JOnAS Architecture 10 Java Open Application Server (JOnAS): a J2EETM Platform

EJB Container Service

This service is in charge of loading the EJB components and their containers. EJB containers consist of a set of Java classes that implement the EJB specification and a set of interposition classes that interface the EJB components with the services provided by the JOnAS application server. Interposition classes are specific to each EJB component and are generated by the deployment tool called GenIC.

JOnAS configuration provides a means for specifying that this service be launched during JOnAS initialization.

Enterprise JavaBeans (EJB) are software components that implement the business logic of an application (while the Servlets and JSPs implement the presentation). There are three types of Enterprise JavaBeans:

• Session beans are objects associated with only one client, short−lived (one method call or a client session), that represent the current state of the client session. They can be transaction−aware, stateful, or stateless. • Entity beans are objects that represent data in a database. They can be shared by several clients and are identified by means of a primary key. The EJB container is responsible for managing the persistence of such objects. The persistence management of such an object is entirely transparent to the client that will use it, and may or may not be transparent to the bean provider who develops it. This depends on if it is one of the following: ♦ An enterprise bean with Container−Managed Persistence. In this case, the bean provider does not develop any data access code; persistence management is delegated to the container. The mapping between the bean and the persistent storage is provided in the deployment descriptor, in an application server−specific way. ♦ An enterprise bean with Bean−Managed Persistence. In this case, the bean provider writes the database access operations in the methods of the enterprise bean that are specified for data creation, load, store, retrieval, and remove operations. • Message−driven Beans are objects that can be considered as message listeners. They execute on receipt of a JMS (Java Message Service) message; they are transaction−aware and stateless. They implement some type of asynchronous EJB method invocation.

JOnAS configuration provides a means for specifying a set of ejb−jar files to be loaded. Ejb−jar files can also be deployed at server runtime using the JOnAS administration tools.

For implementing Container−Managed Persistence of EJB 2.0 and EJB 2.1 (CMP2), JOnAS relies on the ObjectWeb JORM (Java Object Repository Mapping) and MEDOR (Middleware Enabling Distributed Object Requests) frameworks. JORM supports complex mappings of EJBs to database tables, as well as several types of persistency support (relational databases, object databases, LDAP repositories, etc.).

JOnAS also implements the Timer Service features as specified in EJB 2.1.

WEB Container Service

This service is in charge of running a Servlet/JSP Engine in the JVM of the JOnAS server and of loading web applications ("war" files) within this engine. Currently, this service can be configured to use Tomcat or Jetty. Servlet/JSP engines are integrated within JOnAS as "web containers," i.e. such containers provide the web

JOnAS Architecture 11 Java Open Application Server (JOnAS): a J2EETM Platform

components with access to the system resources (of the application server) and to EJB components, in a J2EE−compliant way.

JOnAS configuration provides a means for specifying that this service be launched during JOnAS initialization. Additionally, JOnAS configuration provides a means for specifying a set of war files to be loaded. War files may also be deployed at server runtime using the JOnAS administration tools. User management for Tomcat/Jetty and JOnAS has been unified. The class−loading delegation policy (priority to the Webapp classloader or to the parent classloader) can be configured.

Servlet and JSPTM are technologies for developing dynamic web pages. The Servlet approach allows the development of Java classes (HTTP Servlets) that can be invoked through HTTP requests and that generate HTML pages. Typically, Servlets access the information system using Java APIs (as JDBC or the APIs of EJB components) in order to build the content of the HTML page they will generate in response to the HTTP request. The JSP technology is a complement of the Servlet technology. A JSP is an HTML page containing Java code within particular XML−like tags; this Java code is in charge of generating the dynamic content of the HTML page.

Servlets and JSPs are considered as J2EE application components, responsible for the application presentation logic. Such application components can access resources provided by the J2EE server (such as JDBC datasources, JMS connection factories, EJBs, mail factories). For J2EE components, the actual assignment of these resources is performed at component deployment time and is specified in the deployment descriptor of each component, since the component code uses logical resource names.

Ear Service

This service is used for deploying complete J2EE applications, i.e. applications packaged in EAR files, which themselves contain ejb−jar files and/or war files. This service handles the EAR files and delegates the deployment of the war files to the WEB Container service and the ejb−jar files to the EJB Container service. It handles creating the appropriate class loaders, in order for the J2EE application to execute properly.

For deploying J2EE applications, JOnAS must be configured to launch the EAR service and to specify the set of EAR files to be loaded. EAR files can also be deployed at server runtime using the JOnAS administration tools.

Transaction Service

This service encapsulate a Java Transaction Monitor called JOTM (a project from ObjectWeb). It is a mandatory service which handles distributed transactions. It provides transaction management for EJB components as defined in their deployment descriptors. It handles two−phase commit protocol against any number of Resource Managers (XA Resources). For J2EE, a transactional resource may be a JDBC connection, a JMS session, or a J2EE CA Resource Adapter connection. The transactional context is implicitly propagated with the distributed requests. The Transaction Monitor can be distributed across one or more JOnAS servers; thus a transaction may involve several components located on different JOnAS servers. This service implements the JTA 1.0.1 specification, thus allowing transactions from application components or from application clients to be explicitly started and terminated. Starting transactions from application components is only allowed from Web components, session beans, or message−driven beans (only these two types of beans, which is called "Bean−managed transaction demarcation").

JOnAS Architecture 12 Java Open Application Server (JOnAS): a J2EETM Platform

One of the main advantages of the EJB support for transactions is its declarative aspect, which means that transaction control is no longer hard−coded in the server application, but is configured at deployment time. This is known as "Container−managed transaction demarcation." With "Container−managed transaction demarcation," the transactional behaviour of an enterprise bean is defined at configuration time and is part of the deployment descriptor of the bean. The EJB container is responsible for providing the transaction demarcation for the enterprise beans according to the value of transactional attributes associated with EJB methods, which can be one of the following:

• NotSupported: If the method is called within a transaction, this transaction is suspended during the time of the method execution. • Required: If the method is called within a transaction, the method is executed in the scope of this transaction, else, a new transaction is started for the execution of the method and committed before the method result is sent to the caller. • RequiresNew: The method will always be executed within the scope of a new transaction. The new transaction is started for the execution of the method, and committed before the method result is sent to the caller. If the method is called within a transaction, this transaction is suspended before the new one is started, and resumed when the new transaction has completed. • Mandatory: The method should always be called within the scope of a transaction, else the container will throw the TransactionRequired exception. • Supports: The method is invoked within the caller transaction scope. If the caller does not have an associated transaction, the method is invoked without a

transaction scope. • Never: With this attribute the client is required to call the method without a transaction context, else the Container throws the java.rmi.RemoteException exception.

The ObjectWeb project JOTM (Java Open Transaction Manager), is actually based on the transaction service of earlier JOnAS versions. It will been enhanced to provide advanced transaction features, such as nested transactions and "Web Services" transactions (an implementation of DBTP is available).

Database Service

This service is responsible for handling Datasource objects. A Datasource is a standard JDBC administrative object for handling connections to a database. The Database service creates and loads such datasources on the JOnAS server. Datasources to be created and deployed can be specified at JOnAS configuration time, or they can be created and deployed at server runtime using the JOnAS administration tools. The Database service is also responsible for connection pooling; it manages a pool of database connections to be used by the application components, thus avoiding many physical connection creations, which are time−consuming operations. The database service can now be replaced by the JDBC Resource Adapter, to be deployed by the J2EE CA Resource Service, which additionally provides JDBC PreparedStatement pooling.

Security Service

This service implements the authorization mechanisms for accessing J2EE components, as specified in the J2EE specification.

JOnAS Architecture 13 Java Open Application Server (JOnAS): a J2EETM Platform

• EJB security is based on the concept of roles. The methods can be accessed by a given set of roles. In order to access the methods, the user must be in at least one role of this set. The mapping between roles and methods (permissions) is done in the deployment descriptor using the security−role and method−permission elements. Programmatic security management is also possible using two methods of the EJBContext interface in order to enforce or complement security check in the bean code: getCallerPrincipal() and isCallerInRole (String roleName). The role names used in the EJB code (in the isCallerInRole method) are, in fact, references to actual security roles, which makes the EJB code independent of the security configuration described in the deployment descriptor. The programmer makes these role references available to the bean deployer or application assembler by way of the security−role−ref elements included in the session or entity elements of the deployment descriptor. • WEB security uses the same mechanisms, however permissions are defined for URL patterns instead of EJB methods. Thus, the security configuration is described in the Web deployment descriptor. Programmatically, the caller role is accessible within a web component via the isUserInRole (String roleName) method.

In JOnAS, the mapping between roles and user identification is done in the user identification repository. This user identification repository can be stored either in files, in a JNDI repository (such as LDAP), or in a relational database. This is achieved through a JOnAS implementation of the Realm for each Web container and through the JAAS login modules for Java clients. These Realms use authentication resources provided by JOnAS, which rely either on files, LDAP or JDBC. These realms are in charge of propagating the security context to the EJB container during EJB calls. JAAS login modules are provided for user authentication of Web Container and Java clients. Certificate−based authentication is also available, with CRLLoginModule login module for certificate revocation.

JOnAS also implements the Java Authorization Contract for Containers (JACC 1.0) specification, allowing authorizations to be managed as java security permissions, and providing the ability to plug any security policy provider.

Messaging Service

Asynchronous EJB method invocation is possible on Message−driven Beans components. A Message−driven Bean is an EJB component that can be considered as a JMS (Java Message Service) MessageListener, i.e. which processes JMS messages asynchronously. It is associated with a JMS destination and its onMessage method is activated on the reception of messages sent by a client application to this destination. It is also possible for any EJB component to use the JMS API within the scope of transactions managed by the application server.

For supporting Message−driven Beans and JMS operations coded within application components, the JOnAS application server relies on a JMS implementation. JOnAS makes use of a third−party JMS implementation; currently the JORAM open source software is integrated and delivered with JOnAS, the SwiftMQ product can also be used, and other JMS provider implementations can easily be integrated. JORAM provides several noteworthy features: in particular, reliability (with a persistent mode), distribution (transparently to the JMS client, it can run as several servers, thus allowing load balancing), and the choice of TCP or SOAP as communication protocol for transmitting messages.

JOnAS Architecture 14 Java Open Application Server (JOnAS): a J2EETM Platform

The JMS service is in charge of launching (or establishing connection to) the integrated JMS server, which may or may not run in the same JVM as JOnAS. It also provides connection pooling and thread pooling (for Message−driven Beans). Through this service, JOnAS provides facilities to create JMS−administered objects such as the connection factories and the destinations, either at server launching time or at runtime using the JOnAS administration tools.

Note that the same function of JMS implementation integration may now be achieved through a Resource Adapter, to be deployed by the J2EE CA Resource Service. Such a Resource Adapter (J2EE CA 1.5) is provided for JORAM.

J2EE CA Resource Service

The J2EE Connector Architecture (J2EE CA) allows the connection of different Enterprise Information Systems (EIS) to a J2EE application server. It is based on the Resource Adapter (RA), an architecture component comparable to a software driver, which connects the EIS, the application server, and the enterprise application (J2EE components). The RA is generally provided by an EIS vendor and provides a Java interface (the Common Client Interface or CCI) to the J2EE components for accessing the EIS (this can also be a specific Java interface). The RA also provides standard interfaces for plugging into the application server, allowing them to collaborate to keep all system−level mechanisms (transactions, security, and connection management) transparent from the application components.

JOnAS Architecture 15 Java Open Application Server (JOnAS): a J2EETM Platform

The application performs "business logic" operations on the EIS data using the RA client API (CCI), while transactions, connections (including pooling), and security on the EIS are managed by the application server through the RA (system contract).

The JOnAS Resource service is in charge of deploying J2EE CA−compliant Resource Adapters (connectors), packaged as RAR files, on the JOnAS server. RAR files can also be included in EAR files, in which case the connector will be loaded by the application classloader. Once Resource Adapters are deployed, a connection factory instance is available in the JNDI namespace to be looked up by application components.

A J2EE CA 1.0 Resource Adapter for JDBC is available with JOnAS. It can replace the current JOnAS database service for plugging JDBC drivers and managing connection pools. It also provides JDBC PreparedStatement pooling.

JOnAS Architecture 16 Java Open Application Server (JOnAS): a J2EETM Platform

A J2EE CA 1.5 Resource Adapter for JMS is available with JOnAS. It can replace the current JOnAS Messaging service for plugging JORAM.

Management Service

The Management service is needed to administrate a JOnAS server from the JOnAS administration console. Each server running this service is visible from the administration console. This service is based on JMX. Standard MBeans are defined within the JOnAS application server; they expose the management methods of the instrumented JOnAS server objects such as services, containers, the server itself. These MBeans implements the management model as specified in the J2EE Management Specification. The Management service runs a JMX server. The MBeans of the JOnAS server are registered within this JMX server. The JOnAS administration console is a Struts−based Web application (servlet/JSP) that accesses the JMX server to present the managed features within the administration console. Thus, through a simple Web browser, it is possible to manage one or several JOnAS application servers. The administration console provides a means for configuring all JOnAS services (and making the configuration persistent), for deploying any type of application (EJB−JAR, WAR, EAR) and any type of resource (DataSources, JMS and Mail connection factories, J2EE CA connectors), all without the need to stop or restart the server. The administration console displays information for monitoring the servers and applications, such as used memory, used threads, number of EJB instances, which component currently uses which resources, etc.. When Tomcat is used as Web Container, the Tomcat Management is integrated within the JOnAS console. A Management EJB (MEJB) is also delivered, providing access to the management features, as specified in the J2EE Management Specification.

Mail Service

A J2EE application component can send e−mail messages using JavaMailTM. The Mail service of the JOnAS application server provides the necessary resources to such application components. The Mail service creates mail factories and registers these resources in the JNDI namespace in the same way that the database service or the JMS service creates Datasources or ConnectionFactories and registers these objects in the JNDI namespace. There are two types of mail factories: javax.mail.Session and javax.mail.internet.MimePartDataSource.

WebServices Service

This service is implemented on top of AXIS and is used for the deployment of Web Services.

JOnAS Development and Deployment Environment

JOnAS Configuration and Deployment Facilities

Once JOnAS has been installed in a directory referenced by the JONAS_ROOT environment variable, it is possible to configure servers and to deploy applications into several execution environments. This is achieved using the JONAS_BASE environment variable. JONAS_ROOT and JONAS_BASE can be compared to the CATALINA_HOME and CATALINA_BASE variables of Tomcat. While JONAS_ROOT is dedicated to JOnAS installation, JONAS_BASE is used to specify a particular JOnAS instance configuration. JONAS_BASE designates a directory containing a specific JOnAS configuration, and it identifies subdirectories containing the EJB−JAR, WAR, EAR, and RAR files that can be loaded in this application environment. There is an ANT target in the JOnAS

JOnAS Architecture 17 Java Open Application Server (JOnAS): a J2EETM Platform

build.xml file for creating a new JONAS_BASE directory structure. Thus, from one JOnAS installation, it is possible to switch from one application environment to another by just changing the value of the JONAS_BASE variable. There are two ways to configure a JOnAS application server and load applications: either using the administration console or by editing the configuration files. There are also "autoload" directories for each type of application and resource (EJB−JAR, WAR, EAR, RAR) that allow the JOnAS server to automatically load the applications located in these directories when starting.

JOnAS provides several facilities for deployment:

• For writing the deployment descriptors, plugins for Integrated Development Environments (IDE) provide some generation and editing features (Eclipse and JBuilder plugins are available). The NewBean JOnAS built−in tool generates template deployment descriptors. The Xdoclet tool also generates deployment descriptors for JOnAS. The Apollon ObjectWeb project generates Graphical User Interfaces for editing any XML file; it has been used to generate a deployment descriptor editor GUI. A deployment tool developed by the ObjectWeb JOnAS community (earsetup) will also be available for working with the JSR88−compliant (J2EE 1.4) deployment APIs provided by the ObjectWeb Ishmael project. • Some basic tools for the deployment itself are the JOnAS GenIC command line tool and the corresponding ANT ejbjar task. The IDE plugins integrate the use of these tools for deployment operations. The main feature of the Ishmael project will be the deployment of applications on the JOnAS platform.

JOnAS Development Environments

There are many plugins and tools that facilitate the development of J2EE applications to be deployed on JOnAS. IDE plugins for JBuilder (Kelly) and Eclipse (JOPE and Lomboz) provide the means to develop, deploy, and debug J2EE components on JOnAS. The Xdoclet code−generation engine can generate EJB interfaces and deployment descriptors (standard and JOnAS specific ones), taking as input the EJB implementation class containing specific JavaDoc tags. The JOnAS NewBean tool generates templates of interfaces, implementation class, and deployment descriptors for any kind of EJB. Many development tools may work with JOnAS; refer to the JOnAS tools page for more details.

In addition, JOnAS is delivered with complete J2EE examples, providing a build.xml ANT file with all the necessary targets for compiling, deploying, and installing J2EE applications.

Clustering and Performance

Clustering for an application server generally makes use of three features: Load Balancing (LB), High Availability (HA) and Failover. Such mechanisms can be provided at the Web container level by dispatching requests to several Servlet/JSP engine instances, at the EJB container level by dispatching EJB requests to several EJB container instances, and at the database level by using several databases. A replicated JNDI naming is also necessary.

JOnAS provides Load Balancing, HA, and Failover at the WEB container level using the Apache Tomcat mod_jk plugin and an HTTP in memory session−replication mechanism based on JGroups. The plugin dispatches HTTP requests from the Apache web server to Tomcat instances running as JOnAS web containers. Server fluctuations are automatically taken into account. This plugin supports round−robin and weighted round−robin load−balancing algorithms, with a sticky session option.

JOnAS Development and Deployment Environment 18 Java Open Application Server (JOnAS): a J2EETM Platform

Load balancing and HA are provided at the EJB container level in JOnAS. Operations invoked on EJB Home interfaces (EJB creation and retrieval) are dispatched on the nodes of the cluster. The mechanism is based on a "clustered−aware" replicated JNDI registry using a Clustered remote Method Invocation protocol (CMI). The stubs contain the knowledge of the cluster and implement the load−balancing policy, which may be round−robin and weighted round−robin. In the near future, a load−balancing mechanism based on the nodes load will be available. Failover at the EJB level will be provided by implementing a stateful session bean state replication mechanism.

The JOnAS clustering architecture is illustrated in the following figure.

Apache is used as the front−end HTTP server; Tomcat is used as the JOnAS web container. The JOnAS servers share the same database. The mod_jk plug−in provides Load Balancing / High Availability at the Servlet/JSP level. Failover is provided through the in−memory, session−replication mechanism. Load Balancing / High Availability is provided

JOnAS Development and Deployment Environment 19 Java Open Application Server (JOnAS): a J2EETM Platform

at the EJB level through the CMI protocol associated with the replicated, clustered−aware JNDI registry. Tomcat may or may not run in the same JVM as the EJB container. JOnAS provides some documentation for configuring such an architecture.

The use of the C−JDBC ObjectWeb project offers load balancing and high availability at the database level. The use of C−JDBC is transparent to the application (in our case to JOnAS), since it is viewed as a standard JDBC driver. However, this "driver" implements the cluster mechanisms (reads are load−balanced and writes are broadcasted). The database is distributed and replicated among several nodes, and C−JDBC load balances the queries between these nodes. An evaluation of C−JDBC using the TPC−W benchmark on a 6−node cluster has shown performance scaling linearly up to six nodes.

In addition to clustering solutions, JOnAS provides many mechanisms, intrinsic to the JOnAS server, for being highly scalable and efficient. This includes the following:

• A pool of stateless session bean instances • A pool of entity bean instances, configurable for each entity bean within its deployment descriptor • Activation/passivation of entity beans, passivation can be controlled through the management console • Pools of connections, for JDBC, JMS, J2EE CA connectors • A pool of threads for message−driven beans • Session bean timeout can be specified at deployment • A "shared" flag in the specific deployment descriptor of an entity bean indicates whether the persistent representation of this entity bean is shared by several servers/applications, or whether it is dedicated to the JOnAS server where it is loaded. In the latter case, the optimization performed by JOnAS consists of not reloading the corresponding data between transactions. • The usual EJB 1.1 "isModified" (or "Dirty") mechanism is available for avoiding storage of unmodified data. • An optimization called "Data Prefetching" provides JDBC resultsets re−use by the EJB container (this optimization reduces the number of SQL statements executed by the EJB container).

Some benchmarks and JOnAS Use cases have already proven that JOnAS is highly scalable (e.g., refer to the Rubis results or the OpenUSS Use case). Rubis is a benchmark for e−commerce J2EE applications, which now belongs to the ObjectWeb JMOB (Java Middleware Open Benchmarking) project. OpenUSS is an operational University portal with approximately 20,000 users.

Perspectives

As an open source implementation of an application server, JOnAS is constantly evolving to satisfy user requirements and to follow the related standards. The main JOnAS evolutions currently planned are the following:

• JOnAS administration will be enhanced by completing the concept of management domain, and by introducing cluster management facilities. • Addressing performance issues by developing workbenchs and by producing tuning guides. • Support of "Web Services" will be completed with tools for managing and developing "Web Services"

Sun, Java, and all Java−based trademarks are trademarks or registered trademarks of Sun Microsystems, Inc. in the

Perspectives 20 Java Open Application Server (JOnAS): a J2EETM Platform

U.S. and other countries.

Perspectives 21 Getting started with JOnAS

1. JOnAS installation ♦ Locating JOnAS ♦ Downloading JOnAS ♦ Setting up the JOnAS environment 2. Running a first EJB application ♦ JOnAS examples ♦ Building the sb example ♦ Running the sb example ♦ Understanding why this works 3. More complex examples ♦ Other JOnAS examples ♦ An example with DataBase access ◊ Configuring Database access ◊ Creating the table in the database ◊ Configuring the classpath ◊ Building the eb example ◊ Running the eb example

The purpose of this tutorial is to guide the user through installing JOnAS and running a first example EJB. Guidance is also provided for running a more complex example in which an EJB has access to a database.

Additional information about JOnAS configuration may be found here.

JOnAS Installation

Locating JOnAS

The latest stable binary version of JOnAS is located at the following site :

• Objectweb

The binary version and sources are available at this site. The current (or any previous) version of JOnAS sources can be obtained via CVS.

Downloading JOnAS

The JOnAS download page allows you to choose between the JOnAS latest binary version (standalone or packaged with Tomcat or Jetty) or the latest JOnAS source code. All of these configurations are available as .tgz files or .exe auto−installable files for windows.

Getting started with JOnAS 22 Getting started with JOnAS

Setting up the JOnAS Environment

Select a location for JOnAS installation, for example your_install_dir. Be aware that if a previous version of JOnAS is already installed in this location, the new installation will overwrite previous files and configuration files that have been customized may be lost. In this case, it is recommended that these files be saved before re−starting the installation process. Note that it is also recommended to use a different location through the JONAS_BASE environment variable for customizing configuration files as explained in the Configuration Guide.

JOnAS installation consists of unzipping the downloaded files. To begin the installation process, go to the directory under which JOnAS is to be installed (e.g., your_install_dir) and unzip the downloaded files. You can use gunzip and tar −xvf on unix−based systems, or the winzip utility on Windows systems.

Once the JOnAS product is installed, the following two variables must be set in your environment to complete the installation:

• JONAS_ROOT = your_install_dir/JONAS where your_install_dir is the directory in which JOnAS is installed, • PATH = $JONAS_ROOT/bin/unix on Unix or with %JONAS_ROOT%\bin\nt on Windows.

When using standalone packages (without Tomcat or Jetty), you must run 'ant install' in the JOnAS_ROOT directory to rebuild global libraries based on your environment. This must also be done again if your web environment changes (e.g., switching from CATALINA to JETTY). Note that this step is not necessary for JOnAS−Tomcat and JOnAS−Jetty packages.

Additionally, if RMI/IIOP will be used, global libraries must be rebuilt by running 'ant installiiop' in the JOnAS_ROOT directory. This is valid for all JOnAS packages. Also refer to the Configuration Guide about the communication protocol choice.

JOnAS is now ready to run the first EJB application.

Running a First EJB Application

JOnAS examples

There are several examples in the JOnAS distribution under $JONAS_ROOT/examples/src. The example located in the sb directory should be run first.

This basic example will verify that JOnAS is correctly installed.

In this example, a java client accesses a Stateful Session bean and calls the buy method of the bean several times inside the scope of transactions.

JOnAS Installation 23 Getting started with JOnAS

Building the sb example

Examples should be built using the Ant build tool. Note that some Ant tasks need an additional bcel.jar that can be found on the BCEL site (go to the download area). If you have the Ant build tool installed, you can build the JOnAS examples with the build.xml file found in the $JONAS_ROOT/examples or $JONAS_ROOT/examples/src directories.

Running the sb example

This a distributed example in which two processes are involved:

• the JOnAS server, in which beans will be loaded, and • the java client that creates instances of beans and calls business methods on it.

To run this example:

• Run the JOnAS server: jonas start the following message is displayed on the standard output: The JOnAS Server 'jonas' version−number is ready • Make beans available to clients by loading the jar containing the sb example: jonas admin −a sb.jar the following message is displayed on the standard output: message−header : Op available • Run the java client in another Unix xterm: jclient sb.ClientOp • Or run the java client in a Windows console: jclient sb.ClientOp • The following output should display: Create a bean Start a first transaction First request on the new bean Second request on the bean Commit the transaction Start a second transaction Rollback the transaction Request outside any transaction ClientOp OK. Exiting.

If this output displayed, the first EJB application with JOnAS has run successfully. • Before ending, be sure to stop the JOnAS server: jonas stop • These instructions are also located in the README file in the working directory.

Running a First EJB Application 24 Getting started with JOnAS

Understanding why this works

• To begin with, the CLASSPATH does not need to be set, because, when the JOnAS server is launched, the jonas script calls the JOnAS bootstrap class, which is in charge of loading all the required classes for JOnAS. Moreover, it is recommended that the CLASSPATH contain the least number of elements possible, to avoid potential conflicts. Also, the jclient script is being used to run the client. Note that the bean classes were found in $JONAS_ROOT/examples/classes. If this had not been the case, it would have been necessary to call the jclient script with the −cp "$JONAS_ROOT/ejbjars/sb.jar" option. • The client has succeeded in contacting the JOnAS server because the client has a distributed reference that was previously registered in the naming service. For this, server and client are using JNDI. The carol.properties file (which contains JNDI configuration) is located in the $JONAS_ROOT/conf directory. This carol.properties has the jndi properties set to the default values. With these default values the registry runs on localhost on the default port (1099 for RMI/JRMP). By default, the registry is launched in the same JVM as the JOnAS Server.

NOTE jclient is a script that is used to make it easier the running of a pure java client in a development environment. It is not the J2EE compliant way to run a java client which is to use a J2EE container client. Examples of container client may be found in earsample and jaasclient examples of the JOnAS distribution.

More Complex Examples

Other JOnAS examples

Following are brief descriptions of other examples that are located under $JONAS_ROOT/example/src:

1. The eb example uses Entity beans. The two beans share the same interface (Account): one uses bean−managed persistence (explicit persistence), the other uses container−managed persistence (implicit persistence). This is a good example for understanding what must be done, or not done, for persistence, based on the chosen mode of persistence. It provides both a CMP 1.1 and a CMP 2.0 implementation. 2. The lb example uses Entity bean with local interfaces. A session bean, Manager, locally manages an entity bean, Manac, which represents an account. This is a good example for understanding what must be done for a local client collocated with an entity bean providing local interfaces. 3. The jms directory contains a Stateful Session bean with methods performing JMS operations and a pure JMS client message receptor. A complete description of this example is here in the JMS User's Guide. 4. The mailsb directory contains a SessionMailer and MimePartDSMailer Stateful Session beans with methods providing a way for building and sending mail. 5. mdb/samplemdb contains a Message Driven bean that listens to a topic and a MdbClient, which is a pure JMS client, that sends 10 messages on the corresponding topic. This is a very good example for understanding how to write and use message−driven beans.

Running a First EJB Application 25 Getting started with JOnAS

6. mdb/sampleappli contains the following: two Message−Driven beans, one listening to a topic (StockHandlerBean) the other listening to a queue (OrderBean); an Entity bean with container−managed persistence (StockBean); and a Stateless Session bean for creating the table used in the database. SampleAppliClient sends several messages on the topic. Upon receipt of a message, the StockHandlerBean updates the database via the StockBean and sends a message to the Queue inside a global transaction. All of the EJBs are involved in transactions that may commit or rollback. 7. alarm is an application that watches alarm messages generated asynchronously through JMS. It utilizes the different techniques used in JOnAS:

♦ an Entity Bean for AlarmRecord, persistent in a DataBase, ♦ a Session Bean to allow clients to visualize Alarms received, ♦ a Message Driven Bean to catch Alarms, ♦ JMS to use a topic where Alarms are sent and received, ♦ Tomcat or Jetty (for JSP pages and servlets), ♦ security.

8. earsample contains a complete J2EE application. This sample is a simple stateful Session bean, with synchronization and security. This bean is accessed from a servlet in which the user is authenticated and JOnAS controls access to the methods of the bean. The servlet performs a variety of lookups (resource−ref, resource−env−ref, env−entry, ejb−ref and ejb−local−ref) in the java:comp/env environment to illustrate how the J2EE uniform naming works in the servlets. 9. cmp2 contains an example illustrating most of the concepts of CMP 2.0. 10. jaasclient< contains an example of a JAAS login module that illustrates the different methods for authentication. This applies to a pure Java client. There are different callback handlers that demonstrate how to enter identification at a command line prompt, with a dialog box, or without any prompt (where the client uses its own login/password in the code). 11. j2eemanagement contains an example of how the J2EE Management component (MEJB) can be used to access the manageable object within the JOnAS platform. The MEJB component provides access to the J2EE Management Model as defined in the J2EE Management Specification.

The corresponding directories contain a README that explains how to build and run each example.

An example with DataBase access

The eb example contains two Entity beans that manage Account objects.

The two beans share the same interface (Account); one with bean−managed persistence (BMP, explicit persistence), the other with container−managed persistence (CMP, implicit persistence). The default CMP implementation is CMP 1.1. A CMP 2.0 implementation is also provided and its use is described in the the README.

Before running this example:

• configure Database access,

More Complex Examples 26 Getting started with JOnAS

• configure your classpath environment, • create the table in the database used for this example (BMP and CMP 1.1 only).

Configuring Database access

In order to be able to access your relational database, JOnAS will create and use a DataSource object that must be configured according to the database that will be used.

These DataSource objects are configured via properties files. $JONAS_ROOT/conf contains templates for configuring DataSource objects for Firebird, InstantDB, InterBase, McKoi, MySQL, Oracle or PostgreSQL databases:

• FirebirdSQL.properties • InstantDB1.properties • InterBase1.properties • McKoi1.properties • MySQL.properties • Oracle1.properties • PostgreSQL1.properties

Depending on your database, you can customize one of these files with values appropriate for your installation. Then, the property jonas.service.dbm.datasources in the jonas.properties file must be updated.

For example: jonas.service.dbm.datasources Oracle1 for the Oracle1.properties file.

The section "Configuring Database service" in the Configuration Guide provides more details about DataSource objects and their configuration.

Creating the table in the database

$JONAS_ROOT/examples/src/eb contains an SQL script for Oracle, Account.sql, and another for InstantDB, Account.idb. If your Oracle server is running, or if InstantDB is properly installed and configured, you can create the table used by the example (do not create it if you are using CMP 2.0).

Example for Oracle: sqlplus user/passwd SQL> @Account.sql SQL> quit

Configuring the classpath

The JDBC driver classes must be accessible from the classpath. For that, update the config_env or config_env.bat file. In this file, set one of the following variables: IDB_CLASSES, ORACLE_CLASSES,

More Complex Examples 27 Getting started with JOnAS

POSTGRE_CLASSES or INTERBASE_CLASSES with the appropriate value for your database installation.

You may also add the JDBC driver classes in your CLASSPATH, or copy the classes into JONAS_ROOT/lib/ext.

Building the eb example

The Ant build tool is used to build the JOnAS examples by using the build.xml files located in the $JONAS_ROOT/examples or $JONAS_ROOT/examples/src directories. To do this, use the build.sh shell script on Unix, or the build.bat script on Windows.

Running the eb example

Here, again, two processes are involved:

• the JOnAS server in which beans will be loaded and • the java client that creates instances of beans and calls business methods on it.

To run this example:

• Run the JOnAS server to make beans available to clients: jonas start jonas admin −a eb.jar the following messages are displayed on the standard output: The JOnAS Server 'jonas' version−number is ready and running on rmi

message−header : AccountExpl available message−header : AccountImpl available • Then, run the java clients in another Unix xterm: jclient eb.ClientAccount AccountImplHome jclient eb.ClientAccount AccountExplHome • Or run the java clients in Windows console: jclient eb.ClientAccount AccountImplHome jclient eb.ClientAccount AccountExplHome • If the following output displays: Getting a UserTransaction object from JNDI Connecting to the AccountHome Getting the list of existing accounts in database 101 Antoine de St Exupery 200.0 102 alexandre dumas fils 400.0 103 conan doyle 500.0 104 alfred de musset 100.0 105 phileas lebegue 350.0 106 alphonse de lamartine 650.0 Creating a new Account in database Finding an Account by its number in database

More Complex Examples 28 Getting started with JOnAS

Starting a first transaction, that will be committed Starting a second transaction, that will be rolled back Getting the new list of accounts in database 101 Antoine de St Exupery 200.0 102 alexandre dumas fils 300.0 103 conan doyle 500.0 104 alfred de musset 100.0 105 phileas lebegue 350.0 106 alphonse de lamartine 650.0 109 John Smith 100.0 Removing Account previously created in database ClientAccount terminated

the example eb. has run successfully. • Before ending, be sure to stop the JOnAS server: jonas stop

More Complex Examples 29 Configuration Guide

The content of this Configuration Guide is the following:

1. JOnAS Configuration Rules 2. Configuring JOnAS Environment 3. Configuring the Communication Protocol and JNDI ♦ Choosing the Protocol ♦ Security and Transaction Context Propagation ♦ Multi−protocol Deployment (GenIC) 4. Configuring The Logging System (monolog) 5. Configuring JOnAS services ♦ Configuring Registry service ♦ Configuring EJB Container service ♦ Configuring WEB Container service ♦ Configuring WebServices service ♦ Configuring Ear service ♦ Configuring Transaction service ♦ Configuring Database service ♦ Configuring Security service ♦ Configuring JMS service ♦ Configuring Resource service ♦ Configuring JMX service ♦ Configuring Mail service ♦ Configuring DB service (hsql) ♦ Configuring Discovery service 6. Configuring Security ♦ Using web container Tomcat 5.0.x interceptors for authentication ♦ Using web container Jetty 5.0.x interceptors for authentication ♦ Configuring mapping principal/roles ♦ Configuring LDAP resource in the jonas−realm.xml file ♦ Configuring client authentication based on clientcertificate in the web container 7. Configuring JDBC DataSources ♦ Configuring DataSources ♦ CMP2.0/JORM ♦ JDBC Connection Pool Configuration ♦ Tracing SQL Requests through P6Spy 8. Configuring Resource Adapters ♦ Configuring JDBC Resource Adapters ◊ Configuring Resource Adapters ◊ CMP2.0/JORM ◊ ConnectionManager Configuration ◊ Tracing SQL Requests through P6Spy ◊ Migration from dbm service to the JDBC RA

Configuration Guide 30 Configuration Guide

♦ Configuring JMS Resource Adapters ◊ JORAM Resource Adapter ⋅ Configuration files • a3server.xml • ra.xml, jonas−ra.xml • joramAdmin.xml • joram_raconfig command ⋅ JORAM's Resource Adapter tuning • ManagedConnection Pool • Session/Thread pool in the JORAM RA ⋅ Undeploying and deploying again a JORAM adapter ♦ Common Parameters ◊ ConnectionManager Pool ◊ RAR link ◊ Logging

JOnAS Configuration Rules

As described in the Getting Started chapter, JOnAS is pre−configured and ready to use directly with RMI/JRMP for remote access, if visibility to classes other than those contained in the JOnAS distribution in $JONAS_ROOT/lib is not required. To use JEREMIE or RMI/IIOP for remote access or to work with additional java classes (for example, JDBC driver classes), additional configuration tasks must be performed, such as setting a specific port number for the registry.

JOnAS distribution contains a number of configuration files in $JONAS_ROOT/conf directory. These files can be edited to change the default configuration. However, it is recommended that the configuration files needed by a specific application running on JOnAS be placed in a separate location. This is done by using an additional environment variable called JONAS_BASE.

JONAS_BASE

The JONAS_BASE environment variable has been introduced in JOnAS version 3.1. Starting with this version, the previous configuration rule is replaced with a very basic one:

JOnAS configuration files are read from the $JONAS_BASE/conf directory. If JONAS_BASE is not defined, it is automatically initialized to $JONAS_ROOT.

There are two ways to use JONAS_BASE:

1. Perform the following actions: ♦ Create a new directory and initialize JONAS_BASE with the path to this directory. ♦ Create the following sub−directories in $JONAS_BASE: ◊ conf ◊ ejbjars

JOnAS Configuration Rules 31 Configuration Guide

◊ apps ◊ webapps ◊ rars ◊ logs ♦ Copy the configuration files located in $JONAS_ROOT/conf into $JONAS_BASE/conf. Then, modify the configuration files according to the requirements of your application, as explained in the following sections. 2. Perform the following actions: ♦ Initialize $JONAS_BASE with a path. ♦ In $JONAS_ROOT directory, enter: ant create_jonasbase. This will copy all the required files and create all the directories.

Note that the build.xml files provided with the JOnAS examples support JONAS_BASE. If this environment variable is defined prior to building and installing the examples, the generated archives are installed under the appropriate sub−directory of $JONAS_BASE. For example, the ejb−jar files corresponding to the sample examples of $JONAS_ROOT/examples/src/ are installed in $JONAS_BASE/ejbjars.

Configuring JOnAS Environment

The JOnAS configuration file

The JOnAS server is configured via a configuration file named jonas.properties. It contains a list of key/value pairs presented in the java properties file format.

Default configuration is provided in $JONAS_ROOT/conf/jonas.properties. This file holds all possible properties with their default values. This configuration file is mandatory. The JOnAS server looks for this file at start time in the $JONAS_BASE/conf directory ($JONAS_ROOT/conf if $JONAS_BASE is not defined).

Most of the properties are related to the JOnAS services that can be launched in the JOnAS server. These properties are described in detail in Configuring JOnAS services. The property jonas.orb.port is not related to any service. It identifies the port number on which the remote objects receive calls. Its default value is 0, which means that an anonymous port is chosen. When the JOnAS server is behind a firewall, this property can be set to a specific port number.

Note that starting with the JOnAS 3.1. version, the jonas.name property no longer exists. The name of a server can be specified on the jonas command line using a specific option (−n name). If the name is not specified, the default value is jonas.

When several JOnAS servers must run simultaneously, it is beneficial to set a different name for each JOnAS server in order to administrate these servers via the JOnAS administration tools.

Also note that it is possible to define configuration properties on the command line: (java −D...).

Use the jonas check command to review the JOnAS configuration state.

Configuring JOnAS Environment 32 Configuration Guide

Configuration scripts

The JOnAS distribution contains two configuration scripts:

• $JONAS_ROOT/bin/unix/setenv on Unix and %JONAS_ROOT%\bin\nt\setenv.bat on Windows

This configuration script sets useful environment variables for JAVA setup ($JAVA and $JAVAC). It adds $JONAS_BASE/conf to the $CLASSPATH if $JONAS_BASE is set, otherwise it adds $JONAS_ROOT/conf. This script is called by almost all other scripts (jclient, jonas,newbean,registry,GenIC). • $JONAS_ROOT/bin/unix/config_env on Unix and %JONAS_ROOT%\bin\nt\config_env.bat on Windows

This script is used to add some required .jar files to the $CLASSPATH. This script is called by the jonas script.

Therefore, when requiring the visibility of specific .jar files, the best practice is to update the config_env file. For example, to see some of the JDBC driver classes, one or more of the variables IDB_CLASSES, ORACLE_CLASSES, POSTGRE_CLASSES,INTERBASE_CLASSES must be updated.

Another way to place an additional .jar in the classpath of your JOnAS server is to insert it at the end of the config_env file:

CLASSPATH=$SPS$CLASSPATH

Note that an additional environment variable called XTRA_CLASSPATH can be defined to load specific classes at JOnAS server start−up. Refer to Bootstrap class loader.

Configuring the Communication Protocol and JNDI

Choosing the Protocol

Typically, access to JNDI is bound to a jndi.properties file that must be accessible from the classpath. This is somewhat different within JOnAS. Starting with JOnAS 3.1.2, multi−protocol support is provided through the integration of the CAROL component. This currently provides support for RMI/JRMP, RMI/IIOP, JEREMIE, and CMI (clustered protocol) by changing the configuration. Other protocols may be supported in the future. In versions prior to JOnAS 3.1.2, it was necessary to rebuild JOnAS for switching (e.g., from RMI/JRMP to JEREMIE), and to change the value of the OBJECTWEB_ORB environment variable; OBJECTWEB_ORB is no longer used. This configuration is now provided within the carol.properties file (that includes what was provided in the jndi.properties file). This file is supplied with the JOnAS distribution in the $JONAS_ROOT/conf directory.

Supported communication protocols are the following:

Configuring JOnAS Environment 33 Configuration Guide

• RMI/JRMP is the JRE implementation of RMI on the JRMP protocol. This is the default communication protocol. • JEREMIE is an implementation of RMI provided by the Jonathan Objectweb project. It provides local call (RMI calls within a same JVM) optimization. JEREMIE has a specific configuration file jonathan.xml delivered in $JONAS_ROOT/conf. Typically, no modifications are necessary; just make sure it is copied under $JONAS_BASE/conf if $JONAS_BASE is defined. • RMI/IIOP is the JacORB implementation of RMI over the IIOP protocol. The configuration file of JacORB is the $JONAS_BASE/conf/jacorb.properties file. Since version 4.3.1, JOnAS no longer uses the JRE ORB implementation; it uses the JacORB implementation. The default iiop model now used is the POA model. Thus, GenIC should be relaunched on all previously generated beans. • CMI (Cluster Method Invocation) is the JOnAS communication protocol used for clustered configurations. Note that this protocol is based on JRMP.

The contents of the carol.properties file is:

# jonas rmi activation (jrmp, iiop, jeremie, or cmi) carol.protocols=jrmp #carol.protocols=cmi #carol.protocols=iiop #carol.protocols=jeremie # RMI JRMP URL carol.jrmp.url=rmi://localhost:1099

# RMI JEREMIE URL carol.jeremie.url=jrmi://localhost:12340

# RMI IIOP URL carol.iiop.url=iiop://localhost:2000

# CMI URL carol.cmi.url=cmi://localhost:2001

# general rules for jndi carol.jndi.java.naming.factory.url.pkgs=org.objectweb.jonas.naming

CAROL can be customized by editing the $JONAS_BASE/conf/carol.properties file to 1) choose the protocol through the carol.protocols property, 2) change localhost to the hostname where registry will be run, 3) change the standard port number. If the standard port number is changed, registry must be run with this port number as the argument, registry , when the registry is not launched inside the JOnAS server. Note that Jeremie is now deprecated and could be removed in a future version (jonas 4.7 ?)

You can configure JOnAS to use several protocols simultaneously. To do this, just specify a comma−separated list of protocols in the carol.protocols property of the carol.properties file. For example:

# jonas rmi activation (choose from jrmp, cmi, jeremie, iiop) carol.protocols=jrmp,jeremie

Configuring JOnAS Environment 34 Configuration Guide

Note: Before version 4.1, JOnAS could not support jeremie and iiop at the same time. Due to an incompatibility between Jeremie and rmi/iiop, there was no configuration option providing a choice between these two protocols when building a JOnAS server. By default, JOnAS only allowed a choice between rmi/jrmp, Jeremie or cmi. To use rmi/iiop, it was necessary to run an "ant installiiop" command under the $JONAS_ROOT directory. This resulted in a choice between rmi/jrmp, Jeremie, rmi/iiop or cmi.

This restriction does not exist starting with 4.1 release. The command "ant installiiop" is no longer needed. The choice can be made between rmi/jrmp, Jeremie, rmi/iiop or cmi.

Security and Transaction Context Propagation

For implementing EJB security and transactions, JOnAS typically relies on the communication layer for propagating the security and transaction contexts across the method calls. By default, the communication protocol is configured for context propagation. However, this configuration can be changed by disabling the context propagation for security and/or transaction; this is done primarily to increase performance. The context propagation can be configured in the jonas.properties file by setting the jonas.security.propagation and jonas.transaction.propagation properties to true or false:

# Enable the Security context propagation jonas.security.propagation true

# Enable the Transaction context propagation jonas.transaction.propagation true

Note that the secpropag attribute of the JOnAS ejbjar ANT task and the −secpropag option of GenIC are no longer used. They were used in JOnAS versions prior to 3.1.2 to specify that the security context should be propagated.

Multi−protocol Deployment (GenIC)

The JOnAS deployment tool (GenIC) must be notified for which protocols stubs (for remote invocation) are to be generated. Choosing several protocols will eliminate the need to redeploy the EJBs when switching from one protocol to another. The default is that GenIC generates stubs for rmi/jrmp and Jeremie. To change this configuration, call GenIC with the −protocols option specifying a comma−separated list of protocols (chosen within jeremie, jrmp, iiop, cmi), e.g.:

GenIC −protocols jrmp,jeremie,iiop

This list of protocols can also be specified for the JOnAS ejbjar ANT task:

Configuring the Communication Protocol and JNDI 35 Configuration Guide

additionalargs="${genicargs}">

Since 4.3.1 version, the default iiop model used is the POA model. Thus, GenIC should be relaunched on all previously generated beans.

Configuring the Logging System (monolog)

Starting with JOnAS 2.5, the logging system is based on Monolog, the new standard API for Objectweb projects. Configuring trace messages inside Jonas can be done in two ways:

• Changing the trace.properties file to configure the traces statically, before the JOnAS Server is run • Using the jonas admin command or the JonasAdmin administration tool to configure the traces dynamically, while the JOnAS Server is running

Note the SQL requests sent to a Database can be easily traced using the JOnAS Logging system and the integrated P6Spy tool. The configuration steps are described in the "Configuring JDBC Datasources" section. trace.properties syntax

A standard file is provided in $JONAS_ROOT/conf/trace.properties. Use the CLASSPATH to retrieve this file.

The the monolog documentation provides more details about how to configure logging. Monolog is built over a standard log API (currently, log4j). Loggers can be defined, each one being backed on a handler. A handler represents an output, is identified by its name, has a type, and has some additional properties. Two handlers have been defined in the trace.properties file:

• tty is basic standard output on a console, with no headers. • logf is a handler for printing messages on a file.

Each handler can define the header it will use, the type of logging (console, file, rolling file), and the file name.

Note that if the tag "automatic" is specified as the output filename, JOnAS will replace this tag with a file pointing to $JONAS_BASE/logs/−.log. The logf handler, which is bundled with JOnAS, uses this "automatic" tag.

Loggers are identified by names that are structured as a tree. The root of the tree is named root.

Each logger is a topical logger, i.e. is associated with a topic. Topic names are usually based on the package name. Each logger can define the handler it will use and the trace level among the following four values:

• ERROR errors. Should always be printed. • WARN warning. Should be printed.

Configuring the Logging System (monolog) 36 Configuration Guide

• INFO informative messages, not typically used in Jonas (for example: test results). • DEBUG debug messages. Should be printed only for debugging.

If nothing has been defined for a logger, it will use the properties defined for its parent.

JOnAS code is written using the monolog API and it can use the tty handler.

Example of setting DEBUG level for the logger used in the jonas_ejb module: logger.org.objectweb.jonas_ejb.level DEBUG

Example for setting the output of JOnAS traces to both the console and a file /tmp/jonas/log: handler.logf.output /tmp/jonas.log logger.org.objectweb.jonas.handler.0 tty logger.org.objectweb.jonas.handler.1 logf

Example for setting the output of JOnAS traces to a file in the $JONAS_BASE/logs/ directory: handler.logf.output automatic logger.org.objectweb.jonas.handler.0 logf

Configuring JOnAS Services

JOnAS may be viewed as a number of manageable built−in services started at server launching time. JOnAS is also able to launch external services, which can be defined as explained in the JOnAS service chapter.

The following is a list of the JOnAS built−in services:

• registry: this service is used for binding remote objects and resources that will later be accessed via JNDI. It is automatically launched before all the other services when starting JOnAS. • ejb: the EJB Container service is the service that provides support for EJB application components. • web: the WEB Container service is the service that provides support for web components (as Servlets and JSP). At this time JOnAS provides an implementation of this service for Tomcat and Jetty. • ws: the WebServices service is the service that provides support for WebServices (WSDL publication). • ear: the EAR service is the service that provides support for J2EE applications. • jmx: this service is needed in order to administrate the JOnAS servers and the JOnAS services via a JMX−based administration console. JOnAS is using MX4J. • security: this service is needed for enforcing security at runtime. • jtm: the Transaction manager service is used for support of distributed transactions. This is the only mandatory service for JOnAS. • dbm: the Database service is needed by application components that require access to one or several relational databases.

Configuring JOnAS Services 37 Configuration Guide

• resource: this service is needed for access to Resource Adapters conformant to the J2EE Connector Architecture Specification. • jms: this service was needed by application components that used the Java Message Service standard API for messaging, and was mandatory for using message−driven beans until JOnAS release 4.1. Since this release, a JMS provider can be integrated through the deployment of a resource adapter. • mail: the Mail service is required by applications that need to send e−mail messages. • discovery: the Discovery service allows support for administration of management domains. • db: this service is used for launching a Java database implementation. For instance, one implementation is done for HSQLDB java database.

These services can be managed using the JonasAdmin administration console, which is a Servlet−based application using the JMX technology. Note that JonasAdmin can only manage available services (currently, it is not possible to launch a service after the server start−up).

The services available in a JOnAS server are those specified in the JOnAS configuration file. The jonas.services property in the jonas.properties file must contain a list of the required service names. Currently, these services will be started in the order in which they appear in the list. Therefore, the following constraints should be considered:

• jmx must precede all other services in the list (except registry) in order to allow the management of these services. • jtm must precede the following services: dbm, resource, and jms. • security must be after dbm, as it uses datasources. • the services used by the application components must be listed before the container service used to deploy these components. For example, if the application contains EJBs that need database access, dbm must precede ejb in the list of required services.

Example:

jonas.services registry,jmx,jtm,dbm,security,resource,jms,mail,ejb,ws,web,ear

The registry can be omitted from the list because this service is automatically launched if it is not already activated by another previously started server. This is also true for jmx, since, beginning with JOnAS 3.1, this service is automatically launched after the registry. The dbm, resource, and jms services are listed after the jtm. The application components deployed on this server can use Java Messaging and Java Mail because jms and mail are listed before ejb.

Configuration parameters for services are located in the jonas.properties file, adhering to a strict naming convention: a service XX will be configured via a set of properties: jonas.service.XX.foo something jonas.service.XX.bar else

Configuring JOnAS Services 38 Configuration Guide

Configuring Registry Service

This service is used for accessing the RMI registry, Jeremie registry, CMI registry, or the CosNaming (iiop), depending on the configuration of communication protocols specified in carol.properties, refer to the section "Configuring the Communication Protocol and JNDI."

There are several Registry launching modes based on the value of the JOnAS property jonas.service.registry.mode. The possible values of the jonas.service.registry.mode property are:

• collocated: the Registry is launched in the same JVM as the JOnAS Server, • remote: the Registry must be launched before the JOnAS Server in a separate JVM, • automatic: the Registry is launched in the same JVM as JOnAS Server, if not already started. This is the default value.

The port number on which the Registry is launched is defined in the carol.properties file.

Configuring EJB Container Service

This is the primary JOnAS service, providing EJB containers for EJB components.

An EJB container can be created from an ejb−jar file using one of the following possibilities:

• The corresponding ejb−jar file name is listed in the jonas.service.ejb.descriptors property in the jonas.properties file. If the file name does not contain an absolute path name, it should be located in the $JONAS_BASE/ejbjars/ directory. The container is created when the JOnAS server starts. Example:

jonas.service.ejb.descriptors Bank.jar

In this example the Container service will create a container from the ejb−jar file named Bank.jar. This file will be searched for in the $JONAS_BASE/ejbjars/ directory. • Another way to automatically create an EJB container at server start−up time is to place the ejb−jar files in an autoload directory. The name of this directory is specified using the jonas.service.ejb.autoloaddir property in the jonas.properties file. • EJB containers may be dynamically created from ejb−jar files using the JonasAdmin tool.

JOnAS also allows for loading unpacked EJB components. The name of the xml file containing the EJB's deployment descriptor must be listed in the jonas.service.ejb.descriptors property. Note that the JOnAS server must have access to the component's classes, which may be achieved using the XTRA_CLASSPATH environment variable (see Bootstrap class loader).

Configuring Registry Service 39 Configuration Guide

Automatic Downloading of Stubs from Clients :

JOnAS can be configured to allow dynamic Stubs downloads with the property jonas.service.ejb.codebase.use. Possible values are true/false. Important : This functionnality works only in local mode (server + client must be in the same filesystem) Note that clients must have a SecurityManager set to download Stubs (if you use jclient see jclient script options).

When using Client Container : Example : java −Djava.security.manager −Djava.security.policy=/url/to/java.policy −jar /path/to/client.jar app−client.jar

Configuring WEB Container Service

This service provides WEB containers for the WEB components used in the J2EE applications. JOnAS provides two implementations of this service: one for Jetty 5.0.x, one for Tomcat 5.0.x. It is necessary to run this service to use the JonasAdmin tool.

If you are not using a JOnAS/WebContainer package, if the environment variable $JETTY_HOME or $CATALINA_HOME is not set, the web container service cannot be loaded at JOnAS startup and a warning is displayed.

A WEB container is created from a war file. If the file name does not contain an absolute path name, it must be located in the $JONAS_BASE/webapps/ directory.

JOnAS can create WEB containers when the JOnAS server starts, by providing the corresponding file names via the jonas.service.web.descriptors property in the jonas.properties file. Example:

jonas.service.web.descriptors Bank.war

In this example the WEB Container service will create a container from the war file named Bank.war. It will search for this file in the $JONAS_BASE/webapps/ directory.

Using webapp directories instead of packaging a new war file each time can improve the development process. You can replace the classes with the new compiled classes and reload the servlets in your browser, and immediately see the changes. This is also true for the JSPs. Note that these reload features can be disabled in the configuration of the web container (Jetty or Tomcat) for the production time. Example of using the jonasAdmin/ webapp directory instead of jonasAdmin.war

• Go to the JONAS_BASE/webapps/autoload directory • Create a directory (for example, jonasAdmin) : JONAS_BASE/webapps/autoload/jonasAdmin • Move the jonasAdmin.war file to this directory • Unpack the war file to the current directory, then remove the war file

Configuring WEB Container Service 40 Configuration Guide

• At the next JOnAS startup, the webapp directory will be used instead of the of the war file. Change the jsp and see the changes at the same time.

WEB containers can be also dynamically created from war files using the JonasAdmin tool.

Configuring WebServices Service

A. Choose a Web Service Engine

At this time, only 1 implementation for WebServices is available : the Axis implementation. But in the future, a Glue implementation can be made easily. jonas.properties :

#...

# the fully qualifier name of the service class jonas.service.ws.class org.objectweb.jonas.ws.AxisWSServiceImpl

#...

B. Choose one or more WSDL Handler(s)

WSDL Handlers are used to locate and publish all your WSDL documents. You can use several WSDL Handlers, the only thing to do is to define them in the jonas.properties.

Example : if you want to publish a WSDL into the local FileSystem, use the FileWSDLHandler jonas.properties :

#...

# a list of comma separated WSDL Handlers jonas.service.ws.wsdlhandlers file1

#... With this configuration, JOnAS will try to read a property file named file1.properties (located along with jonas.properties). Here is its content : #... # FileWSDLHandler class jonas.service.wsdl.class org.objectweb.jonas.ws.handler.FileWSDLHandler # Directory where WSDLs will be copied jonas.service.publish.file.directory /tmp # Encoding of the file (In

Configuring WebServices Service 41 Configuration Guide

respect with the platform JOnAS is running on) # If not set default to UTF−8 jonas.service.publish.file.encoding UTF−8 C. Endpoint URL Prefix

The endpoint URL prefix property (jonas.service.ws.url−prefix) is used when you want to enforce the URL to be used for your deployed endpoints. This is clearly interesting when there is a cluster of JOnAS instances and an HTTP frontend (Apache HTTP for load balancing). You want all your web services endpoint to use the http://www.mywebserver.com URL instead of the usual http://localhost:9000 (that has a meaning only at local level).

Configuring EAR Service

The EAR service allows deployment of complete J2EE applications (including both ejb−jar and war files packed in an ear file). This service is based on the WEB container service and the EJB container service. The WEB container service is used to deploy the wars included in the J2EE application; the EJB container service is used to deploy the EJB containers for the ejb−jars included in the J2EE application.

This service may be configured by setting the jonas.service.ear.descriptors property in jonas.properties file. This property provides a list of ears that must be deployed when JOnAS is launched.

The JonasAdmin tool can be used to dynamically deploy the J2EE application components from an ear file.

When using relative paths for ear file names, the files should be located in the $JONAS_BASE/apps/ directory. Example:

jonas.service.ear.descriptors Bank.ear

In this example the EAR service will deploy the ear file named Bank.ear. It will search for this file in the $JONAS_BASE/apps/ directory.

Configuring Transaction Service

The Transaction service is used by the Container service in order to provide transaction management for EJB components as defined in the deployment descriptor. This is a mandatory service. The Transaction service uses a Transaction manager that may be local or may be launched in another JVM (a remote Transaction manager). Typically, when there are several JOnAS servers working together, one Transaction service must be considered as the master and the others as slaves. The slaves must be configured as if they were working with a remote Transaction manager. The following is an example of the configuration for two servers: one named TM in which a standalone Transaction service will be run, one named EJB that will be used to deploy an EJB container:

jonas.name TM jonas.services jtm jonas.service.jtm.remote false

Configuring WebServices Service 42 Configuration Guide

and

jonas.name EJB jonas.services jmx,security,jtm,dbm,ejb jonas.service.jtm.remote true jonas.service.ejb.descriptors foo.jar

Another possible configuration option is the value of the transaction time−out, in seconds, via the jonas.service.jtm.timeout property. The following is the default configuration:

jonas.service.jtm.timeout 60

Configuring Database Service

The description of the new JDBC Resource Adapters as a replacement for the Database service is located in Configuring JDBC Resource Adapters.

To allow access to one or more relational databases (e.g. Oracle, InstantDB, PostgreSQL, ...), JOnAS will create and use DataSource objects. Such a DataSource object must be configured according to the database that will be used for the persistence of a bean. More details about DataSource objects and their configuration are provided in the "Configuring JDBC DataSources" section.

The following subsections briefly explain how to configure a DataSource object for your database, to be able to run the Entity Bean example delivered with your specific platform.

Note that the SQL requests sent to the Database can be easily traced using the JOnAS Logging system and the integrated P6Spy tool. The configuration steps are described in the "Configuring JDBC Datasources" section.

Configuring Oracle for the supplied example

A template Oracle1.properties file is supplied in the installation directory. This file is used to define a DataSource object, named Oracle1. This template must be updated with values appropriate to your installation. The fields are the following:

JNDI name of the DataSource: datasource.name The name used in the example is jdbc_1. The JDBC database URL: for the Oracle JDBC "Thin" driver it is jdbc:oracle:thin:@hostname:sql*net_port_number:ORACLE_SID datasource.url If using an Oracle OCI JDBC driver, the URL is jdbc:oracle:oci7: or jdbc:oracle:oci8:

Configuring Database Service 43 Configuration Guide

Name of the class implementing the Oracle JDBC driver: datasource.classname oracle.jdbc.driver.OracleDriver Adapter (JORM), mandatory for CMP2.0 only (more details in Configuring JDBC datasource.mapper DataSources): rdb.oracle8 for Oracle 8 and prior versions datasource.username Database user name datasource.password Database user password Database isolation level for transactions. Default is to let the database default value. datasource.isolationLevel Note that this setting is useful only when the container has a database lock−policy or has the shared flag set to true.

For the EJB platform to create the corresponding DataSource object, its name (Oracle1, not the JNDI name) must be in the jonas.properties file, on the jonas.service.dbm.datasources line:

jonas.service.dbm.datasources Oracle1

There may be several DataSource objects defined for an EJB server, in which case there will be several dataSourceName.properties files and a list of the DataSource names on the jonas.service.dbm.datasources line of the jonas.properties file:

jonas.service.dbm.datasources Oracle1, Oracle2, InstantDB1

To create the table used in the example with the SQL script provided in examples/src/eb/Account.sql, the Oracle server must be running with a JDBC driver installed (Oracle JDBC drivers may be downloaded at their Web site). For example:

sqlplus user/passwd SQL> @Account.sql SQL> quit

The JDBC driver classes must be accessible from the classpath. To do this, update the config_env file; ($JONAS_ROOT/bin/unix/config_env on Unix, or %JONAS_ROOT%\bin\nt\config_env.bat on Windows).

Configuring InstantDB for the supplied example

A template InstantDB1.properties file is supplied in the installation directory. This file is used to define a Datasource object named InstantDB1. This template must be updated with values appropriate to your installation. The fields are the following:

JNDI name of the DataSource: datasource.name The name used in the example is jdbc_1.

Configuring Database Service 44 Configuration Guide

The JDBC database URL: for InstantDB it is datasource.url jdbc:idb=db1.prp. Name of the class implementing the JDBC driver: datasource.classname org.enhydra.instantdb.jdbc.idbDriver

To have the EJB platform create the corresponding DataSource object, its name (InstantDB1, not the JNDI name) must be in the jonas.properties file, on the jonas.service.dbm.datasources line.

jonas.service.dbm.datasources InstantDB1

InstantDB must have been properly installed and configured, using a version higher than 3.14. (examples have been tested with 3.25).

The JDBC driver classes must be accessible from the classpath. To do this, update the config_env file; ($JONAS_ROOT/bin/unix/config_env on Unix, or %JONAS_ROOT%\bin\nt\config_env.bat on Windows).

Create the Account database using the utility provided with InstantDB:

cd examples/src/eb . $JONAS_ROOT/bin/unix/config_env java org.enhydra.instantdb.ScriptTool Account.idb

Configuring other databases

The same type of process can be used for other databases. A template of datasource for PostgreSQL and for InterBase is supplied with JOnAS. Although many other databases are currently used by the JOnAS users (e.g. Informix, Sybase, SQL Server), not all JDBC drivers have been tested against JOnAS.

Configuring Discovery Service

The discovery service was added to JOnAS services in order to support domain management.

In order to enable domain management, all the servers in the domain must start the discovery service by adding disvovery in the services list (joanas.services property).

By default, a server running the discovery service is a slave, but discovery service can be configured to make a server play the role of master. All the slave servers in the domain can be administered by a management application deployed on a master server. However, a management application can be deployed on a slave in order to administer it individually.

The discovery service is based on a communication infrastructure (curretly IP Multicast) allowing message broadcasting in order to publish the connector−server addresses and state changes of the servers in the domain. The

Configuring Database Service 45 Configuration Guide

master servers listen to these discovery messages. Moreover, they are able to broadcast messages asking the servers in the domain to indentify themselves. See JSR 160 support in JOnAS for more details about JMX Remote connectors.

Configuration Settings for All Servers

The default configuration of the discovery service provides the IP Multicast configuration. The following two properties must have identical values for all the servers in the domain: jonas.service.discovery.multicast.address = 224.224.224.224 jonas.service.discovery.multicast.port = 9080

Configuration Settings for Master Servers

To start a server as a master you must uncomment the following line: jonas.service.discovery.master = true

The configuration of a master server must also define an additional port number by setting the following property: jonas.service.discovery.source = 9888

Master or Slave ?

In a management domain, at least one server must be started as master. But, any slave server can be dynamically promoted to be a master. This is allowed by a management operation exposed by the MBean associated to the discovery service (startDiscoveryMaster operation). Note that the discovery service management was integrated to the JonasAdmin application.

Configuring Security Service

There is one property in the jonas.properties file for configuring the security service: the jonas.security.propagation property should be set to true (which is the default value), to allow the security context propagation across method calls. Refer also to the "Security and Transaction Context Propagation" section. All other security configuration related to JOnAS is done in the file jonas−realm.xml and security configuration related to web containers, certificate, etc., is done in the appropriate files. Refer to the subsection "Configuring Security" for a discussion of security configuration.

Configuring JMS Service (not compliant with 2.1 MDBs)

Until JOnAS release 4.1, the only way to provide the JMS facilities was by setting a JMS service when configuring JOnAS. Now in the default setting, the JMS service is disabled in the jonas.properties config file. Note that this JMS service does not allow deployment of 2.1 MDBs and will become deprecated.

Configuring Discovery Service 46 Configuration Guide

The new way to integrate a JMS platform is by deploying a J2EE 1.4−compliant resource adapter. This process is described in the Configuring JMS resource adapters section.

JOnAS integrates a third−party JMS implementation (JORAM) which is the default JMS service. Other JMS providers, such as SwiftMQ and WebSphere MQ, may easily be integrated as JMS services.

The JMS service is used to contact (or launch) the corresponding MOM (Message Oriented Middleware) or JMS server. The JMS−administered objects used by the EJB components, such as the connection factories and the destinations, should be created prior to the EJB execution, using the proprietary JMS implementation administration facilities. JOnAS provides "wrappers" on such JMS administration APIs, allowing simple administration operations to be achieved automatically by the EJB server itself. jms service is an optional service that must be started before the ejb container service.

Following are the properties that can be set in jonas.properties file for jms service:

• jonas.service.jms.collocated for setting the JMS server launching mode. If set to true, it is launched in the same JVM as the JOnAS Server (this is the default value). If set to false, it is launched in a separate JVM, in which case the jonas.service.jms.url must be set with the connection url to the JMS server. • jonas.service.ejb.mdbthreadpoolsize is used for setting the default thread pool used Message Driven Beans (10 is the default value). • jonas.service.jms.queues and jonas.service.jms.topics are used for setting lists of administered objects queues or topics at launching time. • jonas.service.jms.mom is used to indicate which class must be used to perform administrative operations. This class is the wrapper to the actual JMS provider implementation. The default class is org.objectweb.jonas_jms.JmsAdminForJoram, which is required for Joram. For the SwiftMQ product, obtain a com.swiftmq.appserver.jonas.JmsAdminForSwiftMQ class from the SwiftMQ site. For WebSphere MQ, the class to use is org.objectweb.jonas_jms.JmsAdminForWSMQ.

Some additional information about JMS configuration (in particular, several JORAM advanced configuration aspects) is provided in the "JMS Administration" and "Running an EJB performing JMS operations" sections of the Using JMS in application components chapter.

Information related to using WebSphere MQ is provided in the Using WebSphere MQ JMS howto.

Configuring Resource Service

The Resource service is an optional service that must be started as soon as EJB components require access to an external Enterprise Information Systems. The standard way to do this is to use a third party software component called Resource Adapter.

The role of the Resource service is to deploy the Resource Adapters in the JOnAS server, i.e configure it in the operational environment and register in JNDI name space a connection factory instance that can be looked up by the

Configuring Resource Service 47 Configuration Guide

EJB components.

The Resource service can be configured in one of the following ways:

• The corresponding RAR file name is listed in the jonas.service.resource.resources property in jonas.properties file. If the file name does not contain an absolute path name, then it should be located in the $JONAS_BASE/rars/ directory. Example:

jonas.service.resource.resources MyEIS

This file will be searched for in the $JONAS_BASE/rars/ directory. This property is a comma−separated list of resource adapter file names ('.rar' suffix is optional). • Another way to automatically deploy resource adapter files at the server start−up is to place the RAR files in an autoload directory. The name of this directory is specified using the jonas.service.resource.autoloaddir property in jonas.properties file. This directory is relative to the $JONAS_BASE/rars/ directory.

A jonas specific resource adapter configuration xml file must be included in each resource adapter. This file replicates the values of all configuration properties declared in the deployment descriptor for the resource adapter. Refer to Defining the JOnAS Connector Deployment Descriptor for additional information.

Configuring JMX Service

The JMX service must be started in order to administrate or instrument the JOnAS server via JonasAdmin. This service is mandatory and will be started even if it is not present in the list of services. It is currently based on MX4J JMX implementations, and does not require any specific configuration.

Configuring Mail Service

The Mail service is an optional service that may be used to send email. TM TM It is based on JavaMail and on JavaBeans Activation Framework (JAF) API.

A mail factory is required in order to send or receive mail. JOnAS provides two types of mail factories: javax.mail.Session and javax.mail.internet.MimePartDataSource. MimePartDataSource factories allow mail to be sent with a subject and the recipients already set.

Mail factory objects must be configured accordingly to their type. The subsections that follow briefly describe how to configure Session and MimePartDataSource mail factory objects, in order to run the SessionMailer SessionBean and the MimePartDSMailer SessionBean delivered with the platform.

Configuring JMX Service 48 Configuration Guide

Configuring Session mail factory

The template MailSession1.properties file supplied in the installation directory defines a mail factory of Session type. The JNDI name of the mail factory object is mailSession_1. This template must be updated with values appropriate to your installation. See the section "Configuring a mail factory" below for the list of available properties.

Configuring MimePartDataSource mail factory

The template MailMimePartDS1.properties file supplied in the installation directory defines a mail factory of MimePartDSMailer type. The JNDI name of the mail factory object is mailMimePartDS_1. This template must be updated with values appropriate to your installation. The section "Configuring a mail factory" contains a list of the available properties.

The following subsection provides information about configuring JOnAS in order to create the required mail factory objects.

Configuring JOnAS

Mail factory objects created by JOnAS must be given a name. In the mailsb example, two factories called MailSession1 and MailMimePartDS1 are defined. Each factory must have a configuration file whose name is the name of the factory with the .properties extension (MailSession1.properties for the MailSession1 factory). Additionally, the jonas.properties file must define the jonas.service.mail.factories property. For this example, it is:

jonas.service.mail.factories MailSession1,MailMimePartDS1

Configuring a mail factory

The fields are the following:

Required properties mail.factory.name JNDI name of the mail factory The type of the factory. This property can be javax.mail.Session mail.factory.type or javax.mail.internet.MimePartDataSource.

Optional properties

Authentication properties

Configuring Mail Service 49 Configuration Guide

mail.authentication.username Set the username for the authentication. mail.authentication.password Set the password for the authentication. javax.mail.Session.properties (refer to JavaMail documentation for more information) mail.authentication.username Set the username for the authentication. mail.authentication.password Set the password for the authentication. mail.debug The initial debug mode. Default is false. The return email address of the current user, used by the mail.from InternetAddress method getLocalAddress. The MimeMessage class uses the InternetAddress method mail.mime.address.strict parseHeader to parse headers in messages. This property controls the strict flag passed to the parseHeader method. The default is true. The default host name of the mail server for both Stores and Transports. mail.host Used if the mail.protocol.host property is not set. Specifies the default message access protocol. The Session method mail.store.protocol getStore() returns a Store object that implements this protocol. By default the first Store provider in the configuration files is returned. Specifies the default message access protocol. The Session method getTransport() returns a Transport object that implements this mail.transport.protocol protocol. By default, the first Transport provider in the configuration files is returned. The default user name to use when connecting to the mail server. Used mail.user if the mail.protocol.user property is not set. Specifies the fully− qualified class name of the provider for the specified protocol. Used in cases where more than one provider for a mail..class given protocol exists; this property can be used to specify which provider to use by default. The provider must still be listed in a configuration file. The host name of the mail server for the specified protocol. Overrides mail..host the mail.host property. The port number of the mail server for the specified protocol. If not mail..port specified, the protocol's default port number is used. The user name to use when connecting to mail servers using the mail..user specified protocol. Overrides the mail.user property.

MimePartDataSource properties (Only used if mail.factory.type is javax.mail.internet.MimePartDataSource) mail.to Set the list of primary recipients ("to") of the message. mail.cc Set the list of Carbon Copy recipients ("cc") of the message. mail.bcc Set the list of Blind Carbon Copy recipients ("bcc") of the message. mail.subject Set the subject of the message.

Configuring Mail Service 50 Configuration Guide

Configuring DB Service (hsql)

The DB service is an optional service that can be used to start a java database server in the same JVM as JOnAS. The listening port and the database name can be set as follows: jonas.service.db.port 9001 jonas.service.db.dbname db_jonas

There is a file HSQL1.properties in $JONAS_ROOT/conf that can be used with these default values. The users are declared in the following way: jonas.service.db.user login:password ie: jonas.service.db.user1 jonas:jonas A user with name jonas and password jonas has access to this database. This login and this password (jonas/jonas) are used in the HSQL1.properties file.

Configuring Security

Configure JAAS security for certificate authentication

The Security service is used by the Container service to provide security for EJB components. The Container service provides security in two forms: declarative security and programmatic security. The Security service exploits security roles and method permissions located in the EJB deployment descriptor.

Note that:

• JOnAS relies on Tomcat or Jetty for the identification of the web clients. The java clients use the JAAS login modules for the identification. JOnAS performs the user authentication. JOnAS provides three types of Realm which are defined in the file $JONAS_ROOT/conf/jonas−realm.xml: ♦ Memory realm: users, groups, and roles are written in the file in the section . ♦ Datasource realm: users, groups, and roles information is stored in a database; the configuration for accessing the corresponding datasource is described in the section of the $JONAS_ROOT/conf/jonas−realm.xml file. The configuration requires the name of the datasource, the tables used, and the names of the columns. ♦ LDAP realm: users, groups, and roles information is stored in a LDAP directory. This is described in the section of the $JONAS_ROOT/conf/jonas−realm.xml file. There are some optional parameters. If they are not specified, some of the parameters are set to a default value. ie: if the providerUrl element is not set, the default value is ldap://localhost:389. Edit the jonas−realm_1_0.dtd DTD file to see the default values. For Tomcat, use the realm org.objectweb.jonas.security.realm.web.catalina55.JACC For Jetty, use the realm org.objectweb.jonas.security.realm.web.jetty50.Standard These realms require as argument the name of the resource to be used for the authentication. This is the name

Configuring DB Service (hsql) 51 Configuration Guide

that is in the jonas−realm.xml file. • There is no mapping for the security between JOnAS and the target operational environment. More specifically, the roles defined for JOnAS cannot be mapped to roles of the target operational environment (e.g., groups on Unix).

There is one property in the jonas.properties file for configuring the security service: the jonas.security.propagation property should be set to true (which is the default value), to allow the security context propagation across method calls. Refer also to the "Security and Transaction Context Propagation" section.

Using web container Tomcat 5.0.x interceptors for authentication

With Tomcat 5.0.x, in the $JONAS_ROOT/conf/server.xml file, or $JONAS_BASE/conf/server.xml file, or $CATALINA_HOME/conf/server.xml file, or $CATALINA_BASE/conf/server.xml replace the following line:

By the line:

A memory, Datasource, or LDAP resource can be used for the authentication, with the correct name of the specified resource as resourceName, that is: memrlm_1, memrlm_2, dsrlm_1, ldaprlm_1, etc.

Using web container Jetty 5.0.x interceptors for authentication

To use Jetty interceptors in a web application, provide a web−jetty.xml file under the WEB−INF directory in the .war file, in which it is specified that the security interceptor org.objectweb.jonas.security.realm.web.jetty50.Standard for JOnAS be used instead of the default one. Such as, for the earsample example:

Example Basic Authentication Area Example Basic Authentication Area memrlm_1

Configuring Security 52 Configuration Guide

Several web−jetty.xml examples are located in the earsample example and alarm demo.

Configuring mapping principal/roles

JOnAS relies on the jonas−realm.xml file for access control to the methods of EJB components. Example of a secured bean with the role jonas.

jonas

jonas Bean * ......

The following subsections describe how to configure the different resources for performing authentication if it is necessary to add a user that has the specified role (jonas) and is authorized to call methods, etc.

Configuring Memory resource in jonas−realm.xml file

To add the role 'jonas', place this example role in the section:

Then, add a user with the specified role. Add a user with the 'jonas' role in the section:

The section permits grouping roles. Example : A developer makes two applications, one which need the role role1 and the second application which need the role role2. Instead of declaring two users, user1 with role1 and user2 with role2, a group can be declared. This

Configuring Security 53 Configuration Guide

group will have two roles, role1 and role2.

Then a user named 'john' can be added with the group 'myApplications'. This user must be add in the section ... of section ... of the jonas−realm.xml file.

This user will have two roles, role1 and role2 as these roles are in the group called 'myApplications'. Another user 'joe' can be declared with the same group.

Of course, joe user can be in another group, for example group 'otherApplications'.

If joe must be able to authenticate on jonasAdmin web application, he need the role 'jonas'

So, a user can have many groups and many roles defined. Now, if the developer add a third application which need the role 'role3', the developer just have to add this role in the group named 'myApplications' and all the users from the group 'myApplications' will have this new role.

Add the memory resource in the jonas−realm.xml file: Note : [...] means that it can be existing memory realms as several memoryrealm can be declared in the section One memory−realm can be used for Tomcat, another for Jetty, or different realms can be assigned for specific contexts (in server.xml for Tomcat or web−jetty.xml, jetty.xml for Jetty).

[...]

Configuring Security 54 Configuration Guide

[...]

Note that it's better to use jonasAdmin web application to add/delete user, group, role than editing the jonas−realm.xml by the hand. It can avoid some errors of configuration.

Configuring Datasource resource in the jonas−realm.xml file

First, build the tables in which the users and roles will be stored. Example of tables : realm_users : Add a user jonas_user with the password jonas_password

user_name user_pass

......

jonas_user jonas_password

......

Note that the table can contain more than two columns. realm_roles : Add the role jonas to the user jonas_user

user_name role_name

......

jonas_user jonas

...... Now, declare the resource in the jonas−realm.xml file. The dsName element describes the JNDI name of the datasource to use. Thus, a Datasource configuration with the right JNDI name for the dbm service must be set in the jonas.properties file. The datasource resource to add in the jonas−realm.xml file is:

[...]

Configuring Security 55 Configuration Guide

[...]

Configuring LDAP resource in the jonas−realm.xml file

The user is added in the LDAP server. In this case, all the users are on the ou=people,dc=jonas,dc=objectweb,dc=org DN. For example, the unique name will be: DN uid=jonas_user,ou=people,dc=jonas,dc=objectweb,dc=org for the user 'jonas_user'. The role jonas will be added on the ou=groups,dc=jonas,dc=objectweb,dc=org DN. In this case: DN cn=jaas,ou=groups,dc=jonas,dc=objectweb,dc=org The user is added to the role by adding a field uniquemember to the role. uniquemember = uid=jonas,ou=people,dc=jonas,dc=objectweb,dc=org LDIF format for the user:

# jonas_user, people, jonas, objectweb, org dn: uid=jonas_user,ou=people,dc=jonas,dc=objectweb,dc=org objectClass: inetOrgPerson uid: jonas_user sn: jonas_user cn: JOnAS user userPassword:: jonas_password

LDIF format for the role:

# jonas, groups, jonas, objectweb, org dn: cn=jonas,ou=groups,dc=jonas,dc=objectweb,dc=org objectClass: groupOfUniqueNames uniqueMember: uid=jonas_user,ou=people,dc=jonas,dc=objectweb,dc=org cn: jonas

Now the jonas−realm.xml file can be customized by adding a LDAP resource. There are two methods for the authentication: the bind or the compare method.

• The bind method: In order to check the access rights, the resource attempts to login to the LDAP server with the given username and password. • The compare method: The resource retrieves the password of the user from the LDAP server and compares this password to the password given by the user. Note that this method requires the admin roles in the configuration in order to read the user passwords.

By default, the bind method is used.

Configuring Security 56 Configuration Guide

All the elements of the configuration for the ldap resource can be found on the jonas−realm_1_0.dtd DTD file.

For this sample, it is assumed that the LDAP server is on the same computer and is on the default port (389). It takes all the default values of the DTD. The datasource resource to add in the jonas−realm.xml file is:

[...] [...]

Configuring client authentication based on client certificate in the web container

1. Introduction

In order to set up the client authentication based on client certificate in a Web container, do the following:

• Configure the Realm the Web container will have to use. • Configure an SSL listener on the Web container. • Configure the Web application to make it ask a client certificate. • Configure the JAAS LoginModules. • Populate the Realm access list.

It is mandatory to possess a X.509 certificate for your Web container on each external interface (IP address) that accepts secure connections. This one can be digitally signed by a Certification Authority or can be autosigned.

2. Configure the Realm the Web container will have to use

If you use Tomcat

If the JOnAS−Tomcat package is installed, skip this paragraph.

With Tomcat 5.0.x, in the $JONAS_ROOT/conf/server.xml file, or $JONAS_BASE/conf/server.xml file, or $CATALINA_HOME/conf/server.xml file, or $CATALINA_BASE/conf/server.xml replace the current Realm by the following :

The class specified uses the JAAS model to authenticate the users. Thus, to choose the resource in which to look for authentication data, configure JAAS.

Configuring Security 57 Configuration Guide

If you use Jetty

Edit the web−jetty.xml file under WEB−INF directory in the .war file to declare a Realm name and a Realm:

... !−− Set the same realm name as the one specified in in in the web.xml file of your web application −−> Example Authentication Area JAAS on Jetty ...

The class specified uses the JAAS model to authenticate the users. Thus, to choose the resource in which to look for authentication data, configure JAAS.

3. Configure an SSL listener on the Web container

For Tomcat

Uncomment the following section in the server.xml file:

Important : set the clientAuth parameter to false, otherwise all Web applications will request a client certificate if they need SSL. The client authentication will be configured later in the web.xml file in the specific .war files.

For more information, refer to http://jakarta.apache.org/tomcat/tomcat−5.0−doc/ssl−howto.html.

Configuring Security 58 Configuration Guide

For Jetty

In the global deployment descriptor of Jetty (the jetty.xml file), that is in the $JETTY_HOME/conf or $JONAS_BASE/conf directory (depending on whether using Jetty is being used in standalone or not), set:

... 9043 /conf/keystore changeit jettykeypassword true ...

The Jetty certificate is stored in a repository called the keystore. This is the certificate that will present Jetty when a connection is about to be established.

For more information, refer to http://jetty.mortbay.org/jetty/doc/SslListener.html.

4. Configure your Web application to make it request a client certificate

Add the following lines to the web.xml file of the .war file of the Web application:

CLIENT−CERT Example Authentication Area

Important:

• For both Tomcat and Jetty, ensure that the restricted Web application area is configured in the web.xml file in the .war file with a security−constraint declaration. • For both Tomcat and Jetty, ensure that the Web application is always accessed with SSL, unless the Web container will not get a certificate and will not be able to authenticate the user. • For both Tomcat and Jetty, when authentication is enabled on client certificate, the user's Web browser receives the list of the trusted (by your Web application) Certification Authorities. A connection will be established with the client only if it has a certificate issued by a trusted Certification Authorities, otherwise its certificate will be rejected.

Configuring Security 59 Configuration Guide

♦ In Jetty, the certificates of all the trusted Certification Authorities must be imported inside the keystore specified in the SSL listener. ♦ In Tomcat, the certificates of all the trusted Certification Authorities must be imported in the $JAVA_HOME/jre/lib/security/cacerts keystore file (customize the SSL listener to modify this location). • For Jetty, if the parameter NeedClientAuth in the jetty.xml file is set to true, all Web applications accessed with SSL will ask the user to present a certificate. Use different SSL listeners on different ports to have both Web applications that require client certificate and those that do not. • For Jetty, remember to set the same realm−name as the one in the web−jetty.xml file.

For Jetty, refer to http://jetty.mortbay.org/jetty/doc/ClientCert.htmlfor more information.

5. Configure the JAAS LoginModules

This authentication process is built on the JAAS technology. This means that authentication is performed in a pluggable way and the desired authentication technology is specified at runtime. Therefore, you must choose the LoginModules to use in your Web container to authenticate the users.

Choose the LoginModules org.objectweb.jonas.security.auth.spi.JResourceLoginModule

This is the main LoginModule. It is highly recommended that this be used in every authentication, as it verifies the user authentication information in the specified resource. It requires only one parameter :

• resourceName: the name of the entry in the "jonas−realm.xml " file being used; this entry represents how and where the authentication information is stored. • certCallback: Specify this optional parameter if you want this login module to ask for a certificate callback. By default it is set to false. It should be set to true when using JAAS realms with certificates. org.objectweb.jonas.security.auth.spi.CRLLoginModule

This LoginModule contains authentication based on certificates. However, when enabled, it will also permit non−certificate based accesses. It verifies that the certificate presented by the user has not been revoked by the Certification Authority that signed it. To use it, the directory in which to store the revocation lists (CRLs) files or a LDAP repository must exist.

It can take the following parameters:

• CRLsResourceName: this parameter specifies how the CRLs are stored:

Configuring Security 60 Configuration Guide

♦ "Directory": if the CRL files are stored in a directory on the machine; another parameter pointing to that directory must be specified:

◊ CRLsDirectoryName: the directory containing the CRL files (the extension for these files must be .crl). ♦ "LDAP" : if your CRL files are stored in a LDAP repository; this functionality is experimental; two additional parameters must be specified:

◊ address: the address of the server that hosts the LDAP repository ◊ port: the port used by the LDAP repository; CRLs are retrieved from an LDAP directory using the LDAP schema defined in RFC 2587.

Specify the configuration parameters

The JAAS configuration sits on a file in which the login module to use for authentication is described. This file is located in $JONAS_BASE/conf and named jaas.config. To change its location and name, edit the $JONAS_BASE/bin/jonas.sh script and modify the following line:

−Djava.security.auth.login.config=$JONAS_BASE/conf/jaas.config

The contents of the JAAS configuration file follows that structure:

Application_1 { LoginModuleClassA Flag Options; LoginModuleClassB Flag Options; LoginModuleClassC Flag Options; };

Application_2 { LoginModuleClassB Flag Options; LoginModuleClassC Flag Options; };

Other { LoginModuleClassC Flag Options; LoginModuleClassA Flag Options; };

Sample of a configuration file with CRL directory: tomcat { org.objectweb.jonas.security.auth.spi.CRLLoginModule required CRLsResourceName="Directory" CRLsDirectoryName="path_to/CRLs";

Configuring Security 61 Configuration Guide

org.objectweb.jonas.security.auth.spi.JResourceLoginModule required resourceName="memrlm_1"; };

There can be multiple entries in this file, specifying different configurations that JOnAS can use. There are two requirements: the entry dedicated to Tomcat must be named tomcat, and the entry for Jetty, jetty. Note that everything in this file is case−sensitive.

There is a flag associated with all the LoginModules to configure their behaviour in case of success or fail:

• required − The LoginModule is required to succeed. If it succeeds or fails, authentication still proceeds through the LoginModule list. • requisite − The LoginModule is required to succeed. If it succeeds, authentication continues through the LoginModule list. If it fails, control immediately returns to the application (authentication does not proceed through the LoginModule list). • sufficient − The LoginModule is not required to succeed. If it does succeed, control immediately returns to the application (authentication does not proceed through the LoginModule list). If it fails, authentication continues through the LoginModule list. • optimal − The LoginModule is not required to succeed. If it succeeds or fails, authentication still proceeds through the LoginModule list.

6. Populate the Realm access list

Now, users will not have to enter a login/password. They will just present their certificates and authentication is performed transparently by the browser (after the user has imported his certificate into it). Therefore, the identity presented to the server is not a login, but a Distinguished Name: that is the name identifying the person to whom the certificate belongs.

This name looks like the following:

CN=Someone Unknown, OU=ObjectWeb, O=JOnAS, C=ORG

E : Email Address CN : Common Name OU : Organizational Unit O : Organization L : Locality ST : State or Province Name C : Country Name

The Subject in a certificate contains the main attributes and may include additional ones, such as Title, Street Address, Postal Code, Phone Number.

Configuring Security 62 Configuration Guide

Previously in the jonas−realm.xml, a memory realm might contain:

To enter a certificate−based user access, now the user's DN preceded by the String: ##DN## must be entered, as shown in the following example:

Configuring JDBC DataSources

This section describes how to configure the Datasources for connecting the application to databases.

Configuring DataSources

For both container−managed or bean−managed persistence, JOnAS makes use of relational storage systems through the JDBC interface. JDBC connections are obtained from an object, the DataSource, provided at the application server level. The DataSource interface is defined in the JDBC 2.0 standard extensions. A DataSource object identifies a database and a means to access it via JDBC (a JDBC driver). An application server may request access to several databases and thus provide the corresponding DataSource objects. Available DataSource objects can be added on the platform; they must be defined in the jonas.properties file. This section explains how DataSource objects can be defined and configured in the JOnAS server.

To support distributed transactions, JOnAS requires the use of a JDBC2−XA−compliant driver. Such drivers that implement the XADataSource interface are not always available for all relational databases. JOnAS provides a generic driver−wrapper that emulates the XADataSource interface on a regular JDBC driver. It is important to note that this driver−wrapper does not ensure a real two−phase commit for distributed database transactions.

JOnAS's generic driver−wrapper provides an implementation of the DataSource interface that allows DataSource objects to be defined using a JDBC1−compliant driver for some relational database management server products, such as Oracle, PostGres, or InstantDB.

Neither the EJB specification nor the J2EE specification describe how to define DataSource objects so that they are available to a J2EE platform. Therefore, this document, which describes how to define and configure DataSource objects, is specific to JOnAS. However, the way to use these DataSource objects in the Application Component methods is standard, that is, by using the resource manager connection factory references (refer to the example in the section "Writing database access operations" of the Developing Entity Bean Guide).

A DataSource object should be defined in a file called .properties (for example Oracle1.properties for an Oracle DataSource and InstantDB1.properties for an InstantDB DataSource, as delivered with the platform).

Configuring JDBC DataSources 63 Configuration Guide

In the jonas.properties file, to define a DataSource "Oracle1." add the name "Oracle1" (name of the properties file) to the line jonas.service.dbm.datasources, as follows: jonas.service.dbm.datasources Oracle1,InstantDB1,PostgreSQL

The property file defining a DataSource should contain the following information: datasource.name JNDI name of the DataSource datasource.url The JDBC database URL : jdbc::... datasource.classname Name of the class implementing the JDBC driver datasource.username Database user name datasource.password Database user password Database isolation level for transactions. Possible values are none, serializable, read_committed, datasource.isolationLevel read_uncommitted, repeatable_read. The default depends on the database you use.

A DataSource object for Oracle (for example, Oracle1), named jdbc_1 in JNDI, and using the Oracle thin JDBC driver, would be described in a file called Oracle1.properties, as in the following example: datasource.name jdbc_1 datasource.url jdbc:oracle:thin:@malte:1521:ORA1 datasource.classname oracle.jdbc.driver.OracleDriver datasource.username scott datasource.password tiger

In this example, "malte" is the hostname of the server running the Oracle DBMS, 1521 is the SQL*Net V2 port number on this server, and ORA1 is the ORACLE_SID.

This example makes use of the Oracle "Thin" JDBC driver. If your application server is running on the same host as the Oracle DBMS, you can use the Oracle OCI JDBC driver; depending on the Oracle release, the URL to use for this would be jdbc:oracle:oci7, or jdbc:oracle:oci8. Oracle JDBC drivers may be downloaded at the Oracle Web site.

To create an InstantDB DataSource object (for example, InstantDB1) named jdbc_2 in JNDI, describe it as follows (in a file InstantDB1.properties): datasource.name jdbc_2 datasource.url jdbc:idb=db1.prp datasource.classname jdbc.idbDriver datasource.username useless datasource.password useless

To create a PostGreSQL DataSource object named jdbc_3 in JNDI, describe it as follows (in a file PostGreSQL.properties):

Configuring JDBC DataSources 64 Configuration Guide

datasource.name jdbc_3 datasource.url jdbc:postgresql://your_host/your_db datasource.classname org.postgresql.Driver datasource.username useless datasource.password useless

Properties having the "useless" value are not used for this type of persistence storage.

The database user and password can be placed in the DataSource description (.properties file) and have the Application Components use the getConnection() method, or not placed in the DataSource description and have the Application Components use the getConnection(String username, String password) method. In the resource reference of the associated datasource in the standard deployment descriptor, the element should have the corresponding value, i.e. Container or Application.

CMP2.0/JORM

For implementing the EJB 2.0 persistence (CMP2.0), JOnAS relies on the JORM framework. JORM must adapt its object−relational mapping to the underlying database and makes use of adapters called "mappers" for this purpose. Thus, for each type of database (and more precisely for each JDBC driver), the corresponding mapper must be specified in the DataSource. This is the purpose of the datasource.mapper property.

property name description possible values

• rdb: generic mapper (JDBC standard driver ...) • rdb.cloudscape: mapper for Cloudscape • rdb.db2: mapper for DB2 • rdb.firebird: mapper for Firebird • rdb.hsql: mapper for HSQL • rdb.mckoi: mapper for McKoi Db datasource.mapper JORM database mapper • rdb.mysql: mapper for MySQL • rdb.oracle8: mapper for Oracle 8 and lesser versions • rdb.oracle: mapper for Oracle 9 • rdb.postgres: mapper for PostgreSQL • rdb.sapdb: mapper for Sap DB • rdb.sqlserver: mapper for MS Sql Server • rdb.sybase: mapper for Sybase

JDBC Connection Pool Configuration

Each Datasource is implemented as a connection manager and manages a pool of JDBC connections. The pool can be configured via some additional properties described in the following table. Refer to the Oracle1.properties file to see an example of settings. All these settings have default values and are not required. All these attributes can be reconfigured when jonas is running, with the jonas console (JonasAdmin).

Configuring JDBC DataSources 65 Configuration Guide

default property name description value

JDBC connection checking level:

jdbc.connchecklevel • 0 : no check 1 • 1 : check connection still open • 2 : call the test statement before reusing a connection from the pool

jdbc.connteststmt test statement in case jdbc.connchecklevel = 2. select 1

nb of minutes a connection can be kept in the pool. 1440 mn jdbc.connmaxage After this time, the connection will be closed, if minconpool limit has not been (= 1 day) reached.

Maximum time (in mn) a connection can be left busy. If the caller has not issued 1440 mn jdbc.maxopentime a close() during this time, the connection will be closed automatically. (= 1 day)

Minimum number of connections in the pool. jdbc.minconpool Setting a positive value here ensures that the pool size will not go below this 0 limit during the datasource lifetime.

Maximum number of connections in the pool. jdbc.maxconpool no limit. Limiting the max pool size avoids errors from the database.

Sampling period for JDBC monitoring. jdbc.samplingperiod 60 sec nb of seconds between 2 measures.

Maximum time (in seconds) to wait for a connection in case of shortage. jdbc.maxwaittime 10 sec This is valid only if maxconpool has been set.

Maximum of concurrent waiters for a JDBC Connection. jdbc.maxwaiters 1000 This is valid only if maxconpool has been set.

When a user requests a jdbc connection, the dbm connection manager first checks to see if a connection is already open for its transaction. If not, it tries to get a free connection from the free list. If there are no more connections available, the dbm connection manager creates a new jdbc connection (if jdbc.maxconpool is not reached). If it cannot create new connections, the user must wait (if jdbc.maxwaiters is not reached) until a connection is released. After a limited time (jdbc.maxwaittime), the getConnection returns an exception. When the user calls close() on its connection, it is put back in the free list. Many statistics are computed (every jdbc.samplingperiod seconds) and can be viewed by JonasAdmin. This is useful for tuning these parameters and for seeing the server load at any time.

When a connection has been open for too long a time (jdbc.connmaxage), the pool will try to release it from the freelist. However, the dbm connection manager always tries to keep open at least the number of connections specified in jdbc.minconpool.

Configuring JDBC DataSources 66 Configuration Guide

When the user has forgotten to close a jdbc connection, the system can automatically close it, after jdbc.maxopentime minutes. Note that if the user tries to use this connection later, thinking it is still open, it will return an exception (socket closed).

When a connection is reused from the freelist, it is possible to verify that it is still valid. This is configured in jdbc.connchecklevel. The maximum level is to try a dummy statement on the connection before returning it to the caller. This statement is configured in jdbc.connteststmt.

Tracing SQL Requests through P6Spy

The P6Spy tool is integrated within JOnAS to provide a means for easily tracing the SQL requests that are sent to the database.

To enable this tracing feature, perform the following configuration steps:

• set the datasource.classname property of your datasource properties file to com.p6spy.engine.spy.P6SpyDriver • set the realdriver property in the spy.properties file (located within $JONAS_BASE/conf) to the jdbc driver of your actual database • verify that logger.org.objectweb.jonas.jdbc.sql.level is set to DEBUG in $JONAS_BASE/conf/trace.properties.

Example:

Datasource properties file content:

datasource.name jdbc_3 datasource.url jdbc:postgresql://your_host:port/your_db datasource.classname com.p6spy.engine.spy.P6SpyDriver datasource.username jonas datasource.password jonas datasource.mapper rdb.postgres

Within JONAS_BASE/conf/spy.properties file:

realdriver=org.postgresql.Driver

Within JONAS_BASE/conf/trace.properties:

logger.org.objectweb.jonas.jdbc.sql.level DEBUG

Configuring JDBC DataSources 67 Configuration Guide

Configuring Resource Adapters

Configuring JDBC Resource Adapters

Instead of using the JOnAS "Database Service" for configuring DataSources, it is also possible to use the JOnAS "Resource Service" and JDBC connectors that are compliant to the J2EE Connector Architecture specification. The resulting functionality is the same, and the benefit is the management of pools of JDBC PrepareStatements. This section describes how the JDBC Resource Adapters should be configured to connect the application to databases.

Configuring Resource Adapters

For both container−managed or bean−managed persistence, the JDBC Resource Adapter(RA) makes use of relational storage systems through the JDBC interface. JDBC connections are obtained from a JDBC RA. The JDBC RA implements the J2EE Connector Specification using the DataSource interface as defined in the JDBC 2.0 standard extensions. An RA is configured to identify a database and a means to access it via a JDBC driver. Multiple JDBC RAs can be deployed either via the jonas.properties file or included in the autoload directory of the resource service. For complete information about RAs in JOnAS, refer to J2EE Connector Programmer's Guide. The following section explains how JDBC RARs can be defined and configured in the JOnAS server.

To support distributed transactions, the JDBC RA requires the use of at least a JDBC2−XA−compliant driver. Such drivers implementing the XADataSource interface are not always available for all relational databases. The JDBC RA provides a generic driver−wrapper that emulates the XADataSource interface on a regular JDBC driver. It is important to note that this driver−wrapper does not ensure a real two−phase commit for distributed database transactions.

The generic JDBC RAs of JOnAS provide implementations of the DriverManager, DataSource, PooledConnection, and XAConnection interfaces (see JDBC 3.0). They are located in the $JONAS_ROOT/rars/autoload directory and thus are deployed automatically. They consist of base (or generic) RAs facilitating the build of the user JDBC RAs. Depending on the relational database management server and the available interface in the used JDBC−compliant driver, the user JDBC RA is linked (through the RAR link feature) to a generic RA (e.g. the DriverManager's one). In this case, the user RA contains only a jonas−ra.xml file with some specific parameters, such as the connection url, the user/password, or the JDBC−Driver class.

Resource adapter provided with description jndi name JOnAS

Generic resource adapter that implements the rars/autoload/JOnAS_jdbcDS.rar JOnASJDBC_DS DataSource interface

Generic resource adapter that implements the rars/autoload/JOnAS_jdbcDM.rar JOnASJDBC_DM DriverManager interface

Generic resource adapter that implements the rars/autoload/JOnAS_jdbcCP.rar JOnASJDBC_CP PooledConnection interface

Configuring Resource Adapters 68 Configuration Guide

Generic resource adapter that implements the rars/autoload/JOnAS_jdbcXA.rar JOnASJDBC_XA XAConnection interface

The remainder of this section, which describes how to define and configure JDBC RAs, is specific to JOnAS. However, the way to use these JDBC RAs in the Application Component methods is standard, i.e. via the resource manager connection factory references (refer to the example in the section "Writing Database Access Operations" of the Developing Entity Bean Guide).

An RAR file must be configured and deployed (e.g., Oracle1.rar for an Oracle RAR and MySQL1.rar for a MySQL RAR, as delivered with the platform).

To define a Resource "Oracle1" in the jonas.properties file, add its name "Oracle1" (name of the RAR file) to the line jonas.service.resource.services or just include it in the autoload directory. For more information about deploying an RAR, refer to J2EE Connector Programmer's Guide. jonas.service.resource.services Oracle1,MySQL1,PostgreSQL1

The jonas−ra.xml file that defines a DataSource should contain the following information: jndiname JNDI name of the RAR URL The JDBC database URL: jdbc::... dsClass Name of the class implementing the JDBC driver user Database user name password Database user password

An RAR for Oracle configured as jdbc_1 in JNDI and using the Oracle thin DriverManger JDBC driver, should be described in a file called Oracle1_DM.rar, with the following properties configured in the jonas−ra.xml file:

jdbc_1 JOnASJDBC_DM . . user scott password tiger

Configuring Resource Adapters 69 Configuration Guide

loginTimeout URL jdbc:oracle:thin:@malte:1521:ORA1 dsClass oracle.jdbc.driver.OracleDriver mapperName rdb.oracle

In this example, "malte" is the hostname of the server running the Oracle DBMS, 1521 is the SQL*Net V2 port number on this server, and ORA1 is the ORACLE_SID.

This example makes use of the Oracle "Thin" JDBC driver. For an application server running on the same host as the Oracle DBMS, you can use the Oracle OCI JDBC driver; in this case, the URL to use is jdbc:oracle:oci7: or jdbc:oracle:oci8:, depending on the Oracle release. Oracle JDBC drivers can be downloaded from the Oracle Web site.

To create a MySQL RAR configured as jdbc_2 in JNDI, it should be described in a file called MySQL2_DM.rar, with the following properties configured in the jonas−ra.xml file:

jdbc_2 JOnASJDBC_DM . . user password loginTimeout URL jdbc:mysql://malte/db_jonas

Configuring Resource Adapters 70 Configuration Guide

dsClass org.gjt.mm.mysql.Driver mapperName rdb.mysql

To create a PostGreSQL RAR configured as jdbc_3 in JNDI, it should be described in a file called PostGreSQL3_DM.rar, with the following properties configured in the jonas−ra.xml file:

jdbc_3 JOnASJDBC_DM . . user jonas password jonas loginTimeout URL jdbc:postgresql:/malte:5432/db_jonas dsClass org.postgresql.Driver mapperName rdb.mpostgres

The database user and password can be handled in one of two ways: 1) put it in the jonas−ra.xml file in the RAR file and have the Application Components use the getConnection() method, or 2) not have it in the RAR file and have the Application Component use the getConnection(String username, String password) method.

Configuring Resource Adapters 71 Configuration Guide

CMP2.0/JORM

For implementing the EJB 2.0 persistence (CMP2.0), JOnAS relies on the JORM framework. JORM must adapt its object−relational mapping to the underlying database, and makes use of adapters called "mappers" for this purpose. Thus, for each type of database (and more precisely for each JDBC driver), the corresponding mapper must be specified in the jonas−ra.xml file of the deployed RAR. The mapperName element is provided for this purpose.

property name description possible values

• rdb: generic mapper (JDBC standard driver ...) • rdb.postgres: mapper for PostgreSQL • rdb.oracle8: mapper for Oracle 8 and lesser versions • rdb.oracle: mapper for Oracle 9 mapperName JORM database mapper • rdb.mckoi: mapper for McKoi Db • rdb.mysql: mapper for MySQL • rdb.sqlserver: mapper for MS SQL Server • Refer to JORM documentation for a complete updated list.

ConnectionManager Configuration

Each RAR uses a connection manager that can be configured through the jonas−ra.xml file. The pool parameters are described in the ConnectionManager Pool chapter. The following table describes the JDBC parameters. These settings all have default values and they are not required. jdbc−conn−params elements

property name description default value JDBC connection checking level :

• * 0 : no check jdbc−check−level 0 (no check) • * 1 : check connection still open • * 2 : call the test statement before reusing a connection from the pool jdbc−test−statement jdbc−test−statement is not used when jdbc−check−level is equal to 0 or 1 select 1

Tracing SQL Requests through P6Spy

The P6Spy tool is integrated into JOnAS and it provides an easy way to trace the SQL requests sent to the database.

To enable this tracing feature, perform the following configuration steps:

• Update the appropriate RAR file's jonas−ra.xml file by setting the dsClass property to com.p6spy.engine.spy.P6SpyDriver.

Configuring Resource Adapters 72 Configuration Guide

• Set the realdriver property in the spy.properties file (located in $JONAS_BASE/conf) to the jdbc driver of your actual database. • Verify that logger.org.objectweb.jonas.jdbc.sql.level is set to DEBUG in $JONAS_BASE/conf/trace.properties.

Example: jonas−ra.xml file content:

jdbc_3 JOnASJDBC_DM true org.objectweb.jonas.jdbc.DMPostgres 0 0 100 0 10 0 user jonas password jonas loginTimeout URL jdbc:postgresql://your_host:port/your_db dsClass com.p6spy.engine.spy.P6SpyDriver mapperName

Configuring Resource Adapters 73 Configuration Guide

rdb.postgres logTopic org.objectweb.jonas.jdbc.DMPostgres

In $JONAS_BASE/conf/spy.properties file:

realdriver=org.postgresql.Driver

In $JONAS_BASE/conf/trace.properties:

logger.org.objectweb.jonas.jdbc.sql.level DEBUG

Migration from dbm service to the JDBC RA

The migration of a Database.properties file to a similar Resource Adapter can be accomplished through the execution of the following RAConfig tool command. Refer to RAConfig description for a complete description.

RAConfig −dm −p MySQL $JONAS_ROOT/rars/autoload/JOnAS_jdbcDM MySQL

This command will create a MySQL.rar file based on the MySQL.properties file, as specified by the −p parameter. It will also include the to the JOnAS_jdbcDM.rar, as specified by the −dm parameter.

The jonas−ra.xml created by the previous command can be updated further, if desired. Once the additional properties have been configured, update the MySQL.rar file using the following command:

RAConfig −u jonas−ra.xml MySQL

Configuring JMS Resource Adapters

Instead of using the JOnAS "JMS Service" for configuring a JMS platform, it is possible to use the JOnAS "Resource Service" and JMS adapters that are compliant to the J2EE Connector Architecture specification. The provided functionalities are the same, with the extra benefit of allowing the deployment of 2.1 MDBs.

JMS connections are obtained from a JMS RA, which is configured to identify and access a JMS server. Multiple JMS RAs can be deployed, either via the jonas.properties file, or via the JonasAdmin tool, or included in the autoload directory of the resource service. For complete information about RAs in JOnAS, refer to J2EE Connector Programmer's Guide.

This section describes how JMS Resource Adapters should be configured to provide messaging functionalities to JOnAS components and applications.

Configuring Resource Adapters 74 Configuration Guide

JORAM Resource Adapter

The JORAM resource adapter archive (joram_for_jonas_ra.rar) is provided with the JOnAS distribution. It is located in the $JONAS_ROOT/rars/autoload directory and thus is deployed automatically.

Note that jms must not appear in the list of services of the jonas.properties file because the JORAM's rar and the jms service are exclusive. jonas.services registry,jmx,jtm,dbm,security,resource,ejb,web,ear

The JORAM RA may be seen as the central authority to go through for connecting and using a JORAM platform. The RA is provided with a default deployment configuration which:

• Starts a collocated JORAM server in non−persistent mode, with id 0 and name s0, on host localhost and using port 16010; for doing so it relies on both an a3server.xml file located in the $JONAS_BASE/conf directory and the jonas−ra.xml file located within the RA. • Creates managed JMS ConnectionFactory instances and binds them with the names CF, QCF, and TCF. • Creates administered objects for this server (JMS destinations and non−managed factories) as described by the joramAdmin.xml, located in the $JONAS_BASE/conf directory; those objects are bound with the names sampleQueue, sampleTopic, JCF, JQCF, and JTCF.

This default behaviour is strictly equivalent to the default JMS service's behaviour.

The default configuration may, of course, be modified.

Configuration files

The JORAM into JOnAS is composed of 3 different parts: server, RA, and administration. Each part contains its own configuration files:

• a3server.xml is the JORAM platform configuration file, i.e. the server part. The file is located in the $JONAS_BASE/conf directory. • ra.xml and jonas−ra.xml are the resource adapter configuration files. They are embedded in the resource adapter (META−INF directory). • joramAdmin.xml contains the administration tasks to perform by the JORAM server such as the JMS objects to create. It is located in the $JONAS_BASE/conf directory

JORAM server configuration : a3server.xml

The a3server.xml ($JONAS_BASE/conf/a3server.xml) file describes the JORAM platform, i.e. the network domain, the used transport protocol, and the reachable JORAM servers. It is used by a starting JORAM server By default, only one collocated JORAM server is defined (s0) based on the tcp/ip protocol. A distributed configuration example is provided in the how−to document and others examples are available in JORAM's user guide.

Configuring JMS Resource Adapters 75 Configuration Guide

The default file provided with JOnAS is the following:

The above configuration describes a JORAM platform made up of one unique JORAM server (id 0, name s0), running on localhost, listening on port 16010. Those values are taken into account by the JORAM server when starting. However, they should match the values set in the deployment descriptor of the RA, otherwise the adapter either will not connect to the JORAM server, or it will build improper connection factories. The joram_raconfig allows modification to these parameters in all the configuration files.

If used in non−collocated mode, the $JONAS_BASE/conf/a3server.xml file is not used.

Resource Adapter configuration: ra.xml, jonas−ra.xml

The ra.xml file is the standard deployment descriptor for the JORAM adapter and the jonas−ra.xml file is the JOnAS−specific deployment descriptor for the JORAM adapter. These files set the central configuration of the adapter, define and set managed connection factories for outbound communication, and define a listener for inbound communication. jonas−ra.xml contains specific parameters such as pool parameters or jndi names, but also may redefine the parameters of some ra.xml files and override their values. Globally, a good way to proceed is to keep the original ra.xml file with the default values and to customize the configuration only in the jonas−ra.xml file.

Changing the configuration of the RA requires extracting and editing the deployment descriptor and updating the archive file. There are several possible ways to do this:

• With the RAConfig utility (refer to RAConfig description for a complete description).

To extract jonas−ra.xml, do the following:

RAConfig −path . joram_for_jonas_ra.rar

Then, to update the archive, do the following:

RAConfig −u jonas−ra.xml joram_for_jonas_ra.rar • Through the jonasAdmin console (refer to Administration guide for a complete description).

In the jonasAdmin's tree, the Resource Adapter Module node (under the deployment node) contains a configure tab that allows editing of both the ra.xml file and the jonas−ra.xml file of the undeployed RA. • Through the joram_raconfig utility (refer to joram_raconfig description for a complete description).

Configuring JMS Resource Adapters 76 Configuration Guide

This tool allows easy modification to the network parameters of the JORAM server in all the configuration files.

The following properties are related to the central configuration of the adapter:

property name description possible values

• True: when deploying, the adapter starts a collocated JORAM server. Running mode of the JORAM server to which the adapter CollocatedServer • False: when deploying, the gives access. adapter connects to a remote JORAM server. • Nothing (default True value is then set).

• Any String describing an absolute path (ex: /myHome/myJonasRoot/conf). Directory where the a3servers.xml and PlatformConfigDir • Empty String, files will be joramAdmin.xml files are located. searched in $JONAS_BASE/conf. • Nothing (default empty string is then set).

• True: starts a persistent JORAM server. Persistence mode of the collocated JORAM server (not • False: starts a PersistentPlatform taken into account if the JORAM server is set as non−persistent JORAM non−collocated). server. • Nothing (default False value is then set).

• Identifier corresponding to the server to start Identifier of the JORAM server to start (not taken into described in the ServerId account if the JORAM server is set as non−collocated). a3servers.xml file (ex: 1). • Nothing (default 0 value is then set). ServerName Name of the JORAM server to start (not taken into account if the JORAM server is set as non−collocated). • Name corresponding to the server to start described in the a3servers.xml file

Configuring JMS Resource Adapters 77 Configuration Guide

(ex: s1). • Nothing (default s0 name is then set).

Name of the file describing the administration tasks to be • Name of the file (ex: performed by the JORAM server, i.e. JMS destinations to myAdminFile.xml). AdminFileXML create, users to create, ... If the file does not exist, or is not • Nothing (default found, no administration task is performed. joramAdmin.xml name is then set).

Name of the host where the JORAM server runs, used for • Any host name (ex: HostName accessing a remote JORAM server (non−collocated myHost). mode), and for building appropriate connection factories. • Nothing (default localhost name is then set).

Port the JORAM server is listening on, used for accessing • Any port value (ex: ServerPort a remote JORAM server (non−collocated mode), and for 16030). building appropriate connection factories. • Nothing (default 16010 value is then set).

The jonas−connection−definition tags wrap properties related to the managed connection factories:

property description possible values name jndi−name Name used for binding the constructed connection factory. • Any name (ex: myQueueConnectionFactory).

• Any name (ex: myName). UserName Default user name that will be used for opening JMS connections. • Nothing (default anonymous name will be set).

• Any name (ex: myPass). Default user password that will be used for opening JMS UserPassword • Nothing (default connections. anonymous password will be set). Collocated Specifies if the connections that will be created from the factory should be TCP or local−optimized connections (the collocated • True (for building mode can only be set if the JORAM server is collocated; such local−optimized factories will only be usable from within JOnAS). connections). • False (for building TCP connections).

Configuring JMS Resource Adapters 78 Configuration Guide

• Nothing (default TCP mode will be set).

The jonas−activationspec tag wraps a property related to inbound messaging:

property name description possible values jndi−name Binding name of a JORAM object to be used by 2.1 MDBs. • Any name (ex: joramActivationSpec).

The common parameters are described in the Common parameters chapter.

Administration tasks: joramAdmin.xml joramAdmin.xml file (former joram−admin.cfg file) describes the configuration relating to the application. It describes the administration objects in the JORAM server such as the JMS objects, the users, or the non−managed factories. In others words, it defines the JORAM objects to be (optionally) created when deploying the adapter.

The new file format enables new capabilities since the former version (joram−admin.cfg) file, such as the ability to specify a different name for the JMS destination and its JNDI name, or the ability to define dead message queues, cluster queues, scheduler queues, and so on.

If the two files are present in the configuration (joram−admin.cfg, joramAdmin.xml), the two are loaded and object conflicts must be resolved otherwise a failure will occur. Note that joram−admin.cfg is now deprecated.

A dynamic reloading can be performed through the class org.objectweb.joram.client.jms.admin.AdminModule.executeXMLAdmin() method.

The default file provided with JOnAS creates a queue bound with the name sampleQueue, a topic bound with the name sampleTopic, sets the anonymous user, and creates and binds non−managed connection factories named JCF, JQCF and JTCF.

To be noted:

• All administration tasks are performed locally, meaning on the JORAM server to which the adapter is connected. • If a queue, a topic or a user already exists on the JORAM server (for example, because the server is in persistent mode and has re−started after a crash, or because the adapter has been deployed, undeployed and is re−deployed giving access to a remote JORAM server), it will be retrieved instead of being re−created.

• The new format is XML and a simple example is given below:

Configuring JMS Resource Adapters 79 Configuration Guide

• For requesting the creation of a new object, simply add the element in the file. For example, to add a queue 'MyQueue', add the following XML element:

• When the JORAM is not collocated, the AdminModule must be defined as follows:

• Possible parameters for a queue definition:

Configuring JMS Resource Adapters 80 Configuration Guide

• Possible parameters for a topic definition:

• Example of a dead message queue definition:

• Example of a scheduler queue definition:

Configuring JMS Resource Adapters 81 Configuration Guide

• Example of a clustered queues destination:

• Others samples are provided with the JORAM source code.

Configuring JMS Resource Adapters 82 Configuration Guide

joram_raconfig command

The joram_raconfig tool aims to facilitate changes to the parameters (host, port, server id) in the JORAM configuration files. JORAM relies on several configuration files: a3server.xml, joramAdmin.xml, jonas−ra.xml. With joram_raconfig, all these configuration files are updated and thus the consistency is ensured.

• Usage :

joram_raconfig [−p ] [−h ] [−s ] with port : listening port of the JORAM server host : IP address of the JORAM server serverid : server id of the JORAM server

JORAM's Resource Adapter tuning

ManagedConnection Pool

A pool of ManagedConnection is defined for each factory (connection definition) specified in the ra.xml file. See the pool parameters in the ConnectionManager Pool chapter.

Session/Thread pool in the JORAM RA

The JORAM RA manages a pool of session/thread for each connection and, by default, the maximum number of parallel sessions is set to 10.

When linked with an MDB, this maximum number of entries in the pool corresponds to the maximum number of messages that can be processed in parallel per MDB. A session is released to the pool just after the message processing (onMessage()). When the maximum is reached, the inquiries for a session creation are blocked until a session becomes available in the pool.

The maxNumberOfWorks property can be set in the MDB JOnAS−specific deployment descriptor. For example, the code below can be added to limit the number of parallel session to 100 (default value is 10).

maxNumberOfWorks 10

Undeploying and deploying again a JORAM adapter

Undeploying a JORAM adapter either stops the collocated JORAM server or disconnects from a remote JORAM server. It is then possible to deploy the same adapter again. If set for running a collocated server, it will re−start it. If the running mode is persistent, then the server will be retrieved in its pre−undeployment state (with the existing destinations, users, and possibly messages). If set for connecting to a remote server, the adapter will reconnect and access the destinations it previously created.

Configuring JMS Resource Adapters 83 Configuration Guide

In the collocated persistent case, if the intent is to start a brand new JORAM server, its persistence directory should be removed. This directory is located in JOnAS' running directory and has the same name as the JORAM server (for example, s0/ for server "s0").

Common Parameters

ConnectionManager Pool Configuration

The resource service of JOnAS creates a connection manager for each connection definition described in the deployed RAR file. Each connection manager instance owns its managed connection pool.

Only one connection definition can be defined in a JCA 1.0−compliant RAR, while JCA 1.5 allows several connection definitions to be defined for a single RAR file.

The pool parameters may be defined in the jonas−ra.xml file (embedded in the resource adapter archive) either at the root level (jonas−connector element) or at the connection definition level (see the XML schema). The values defined at the connection−definition level override the values defined at the root level.

< elements

default property name description value pool−init Initial number of connections 0 pool−min Minimum number of connections 0 −1 pool−max Maximum number of connections (unlimited) 0 pool−max−age Number of seconds to keep the connection in the pool (unlimited) pstmt−max Maximum number of PreparedStatements cached per connection, −1 to disable 10 Maximum open time in minutes for a connection in the pool. The timed out pool−max−opentime 0 (infinite) active connection is automatically closed. Maximum number of waiters (threads) allowed to wait for a Connection. When pool−max−waiters 0 the threshold is reached, an exception 'no more connections' is thrown. Maximum number of seconds to wait for a connection when the pool is full. 10 pool−max−waittime When timeout occurs, an exception 'no more connections' is thrown. If 0 is set, (seconds) the default value is used. 30 pool−sampling−period Pool statistics sampling period in seconds (seconds)

Example:

• jonas−ra.xml file content with a pool definition at the jonas−connector level

Common Parameters 84 Configuration Guide

0 0 100 0 0 0 0 0 30 ... • jonas−ra.xml file content with a pool definition at the connection−definition level

... ... ... ... 0 0 100 0 0 0 0 0 30 ...

RAR link

The jonas−ra.xml may contain the optional rarlink element. It allows a base resource adapter definition to be used, overriding only a subset of the specific parameters. Typically, it enables a JDBC resource adapter to be defined, relying on the generic resource adapter provided with JOnAS. In this case, the new RA package may only contain the META−INF/jonas−ra.xml file. rarlink element

property name description default value

Common Parameters 85 Configuration Guide

rarlink Jndi name of the base RA none

Example:

• jonas−ra.xml file content with a rar link to the generic JDBC RAR 'JOnASJDBC_DM'

JOnASJDBC_DM ...

RAR logging

The jonas−ra.xml may contain the optional parameters log−enabled and log−topic in order to define the logging properties for the resource adapter. The first one, log−enabled, specifies whether the logging must be turned on for the resource adapter software. If yes, by default the topic that is used is 'org.objectweb.jonas.jca', and this value may be overriden by the second parameter, log−topic. logging elements

property name description default value log−enabled Turn on/off the logging for the resource adapter false log−topic Logging topic used for the resource adapter logging org.objectweb.jonas.jca

Example:

• jonas−ra.xml file content with logging parameters'

true mypackage ...

Common Parameters 86 J2EE Application Programmer's Guide

Target Audience and Content

The target audience for this guide is the application component provider, i.e. the person in charge of developing the software components on the server side (the business tier).

The content of this guide is the following:

1. Target Audience and Content 2. Principles ♦ Enterprise Bean Creation ♦ Web Components Creation ♦ J2EE Application Assembler ♦ Application Deployer and Administrator 3. JOnAS class loader hierarchy ♦ Understanding class loader hierarchy ♦ Commons class loader ♦ Application class loader ♦ Tools class loader ♦ Tomcat class loader ♦ JOnAS class loaders ♦ Conclusion

Principles

JOnAS supports two types of J2EE application components: Enterprise Beans and Web components. In addition to providing guides for construction of application components, guides are supplied for application assembly, deployment, and administration.

Enterprise Bean Creation

The individual in charge of developing Enterprise Beans should consult the Enterprise Beans Programmer's Guide for instructions on how to perform the following tasks:

1. Write the source code for the beans. 2. Specify the deployment descriptor. 3. Bundle the compiled classes and the deployment descriptor into an EJB JAR file.

This JOnAS documentation provides guides for developing the three types of enterprise bean:

• Session beans • Entity beans

J2EE Application Programmer's Guide 87 J2EE Application Programmer's Guide

• Message driven beans

Deployment descriptor specification is presented in the Defining the Deployment Descriptor chapter.

More specific issues related to transaction behavior, the Enterprise Bean environment, or security service, are presented in the corresponding chapters: Transactional Behaviour, Enterprise Bean Environment, Security Management.

Principles and tools for providing EJB JAR files are presented in the chapters EJB Packaging and Deployment and Installation Guide.

Web Components Creation

Web designers in charge of JSP pages and software developers providing servlets can consult the Web Application Programmer's Guide.

The Developing Web Components guide explains how to construct Web components, as well as how to access Enterprise Beans from within the Web Components.

Deployment descriptor specification is presented in the Defining the Web Deployment Descriptor chapter.

Web components can be used as Web application components or as J2EE application components. In both cases, a WAR file will be created, but the content of this file is different in the two situations. In the first case, the WAR contains the Web components and the Enterprise Beans. In the second case, the WAR does not contain the Enterprise Beans. The EJB JAR file containing the Enterprise Beans is packed together with the WAR file containing the Web components, into an EAR file. Principles and tools for providing WAR files are presented in WAR Packaging and the Deployment and Installation Guide.

J2EE Application Assembler

The application assembler in charge of assembling the application components already bundled in EJB JAR files and WAR files into a J2EE EAR file, can obtain useful information from the J2EE Application Assembler's Guide chapter.

Application Deployer and Administrator

JOnAS provides tools for the deployment and administration of Enterprise Beans (EJB JARs), Web applications (WARs), and J2EE applications (EARs).

The Deployment and Installation Guide covers issues related to the deployment of application components.

The Administration Guide presents information about how to manage the JOnAS server and the JOnAS services that allow deployment of the different types of application components: EJB Container service, Web Container service, and EAR service.

Principles 88 J2EE Application Programmer's Guide

JOnAS class loader hierarchy

This section describes a new and important key feature of the J2EE integration: the class loader hierarchy in JOnAS.

Understanding class loader hierarchy

An application is deployed by its own class loader. This means, for example, that if a WAR and an EJB JAR are deployed separately, the classes contained in the two archives are loaded with two separate classloaders with no hierarchy between them. Thus, the EJBs from within the JAR will not be visible to the Web components in the WAR. This is not acceptable in cases where the Web components of an application need to reference and use some of the EJBs (this concerns local references in the same JVM).

For this reason, prior to EAR files, when a Web application had to be deployed using EJBs, the EJB JAR had to be located in the WEB−INF/lib directory of the Web application.

Currently, with the J2EE integration and the use of the EAR packaging, class visibility problems no longer exist and the EJB JAR is no longer required in the WEB−INF/lib directory.

The following sections describe the JOnAS class loader hierarchy and explain the mechanism used to locate the referenced classes.

Commons class loader

The commons class loader is a JOnAS−specific class loader that will load all classes required to start the JOnAS server. This class loader has the system class loader as parent class loader. The commons class loader adds all the common libraries required to start the JOnAS server (J2EE apps, commons logging, objectweb components, etc.); it also loads the classes located in XTRA_CLASSPATH.

The JARs loaded by the commons class loader are located under the JONAS_ROOT/lib/commons and JONAS_BASE/lib/commons directories. You can extend this class loader by adding your own JARs inside these directories. If you are using a Jetty packaging, JONAS_ROOT/lib/jetty will be loaded too.

Note that the lib/ext extension mechanism is now deprecated. You should place additional JARs directly in the classloader directory (commons, apps, tools) under JONAS_ROOT and/or JONAS_BASE. You should now use the JONAS_BASE/lib/commons if you want to extend the commons ClassLoader, JONAS_BASE/lib/apps for apps ClassLoader and JONAS_BASE/lib/tools for tools ClassLoader. Notice that the JONAS_BASE extension directories are always loaded after JONAS_ROOT directories, so if the same class is in JONAS_ROOT/lib/commons and in JONAS_BASE/lib/commons, the one located in JONAS_ROOT/lib/commons will be used.

To have a library available for each component running inside JOnAS, add the required JAR files in the JONAS_ROOT/lib/commons directory or in the JONAS_BASE/lib/commons. All jars in subordinate directories will also be loaded. If a specific jar is needed only for a web application (i.e., need to use a version of a jar file which is different than a

JOnAS class loader hierarchy 89 J2EE Application Programmer's Guide

version loaded by JOnAS), change the compliance of the web application classloader to the java 2 delegation model. Refer to the following: WEB class loader. It is also possible to use the extension mechanism, which is described in the section dependencies of the J2EE specification (section 8.1.1.28)

Application class loader

The application class loader is a JOnAS−specific class loader that will load all application classes required by the user applications. This implies that this loader will load all single RAR files. Thus, all applications have the visibility of the resource adapters classes. This class loader has the commons class loader as parent class loader.

The JARs loaded by the application class loader are located under the JONAS_ROOT/lib/apps directory, under JONAS_ROOT/lib/catalina/common/lib directory (CATALINA_HOME/common/lib if you are not using the Tomcat package) and under JONAS_BASE/lib/apps directory. You can extend this class loader by adding your own JARs inside these directories.

Tools class loader

The tools class loader is a JOnAS−specific class loader that will load all classes for which applications do not require visibility. (User applications will not have the ability to load the classes packaged in the tools class loader). For example, it includes the jakarta velocity and digester components. This class loader has the commons class loader as parent class loader.

The JARs loaded by the tools class loader are located under the JONAS_ROOT/lib/tools directory and under the JONAS_BASE/lib/tools directory. You can extend this class loader by adding your own JARs inside these directories.

Tomcat class loader

The tomcat class loader is a class loader that will load all classes of the tomcat server. (CATALINA_HOME/server/lib directory). The classes of the common directory of tomcat (CATALINA_HOME/common/lib directory) are loaded by the application classloader and not by this tomcat classloader. Applications have the visibility of the classes and not the server classes. To have the visibility of the server classes, the context must have the privileged attribute set to true. This class loader has the application class loader as parent class loader.

The JARs loaded by the tomcat class loader are located under the JONAS_ROOT/catalina/server/lib directory (if using Tomcat packaging, unless these libs are located under CATALINA_HOME/server/lib). You can extend this class loader by adding your own JARs inside this directory.

JOnAS class loaders

The JOnAS class loader hierarchy that allows the deployment of EAR applications without placing the EJB JAR in the WEB−INF/lib directory consists of the following:

JOnAS class loader hierarchy 90 J2EE Application Programmer's Guide

EAR class loader

The EAR class loader is responsible for loading the EAR application. There is only one EAR class loader per EAR application. This class loader is the child of the application class loader, thus making JOnAS classes visible to it.

EJB class loader

The EJB class loader is responsible for loading all the EJB JARs of the EAR application, thus all the EJBs of the same EAR application are loaded with the same EJB classloader. This class loader is the child of the EAR class loader.

WEB class loader

The WEB class loader is responsible for loading the Web components. There is one WEB class loader per WAR file, and this class loader is the child of the EJB class loader. Using this class loader hierarchy (the EJB class loader is the parent of the WEB class loader) eliminates the problem of visibility between classes when a WEB component tries to reference EJBs; the classes loaded with the EJB class loader are definitely visible to the classes loaded by its child class loader (WEB class loader).

The compliance of the class loader of the web application to the java 2 delegation model can be changed by using the jonas−web.xml file. This is described in the section "Defining the Web Deployment Descriptor."

If the java2−delegation−model element is set to false, the class loader of the web application looks for the class in its own repository before asking its parent class loader.

Conclusion

The resulting JOnAS class loader hierarchy is as follows:

JOnAS class loader hierarchy 91 J2EE Application Programmer's Guide

JOnAS class loader hierarchy 92 EJB Programmer's Guide: Developing Session Beans

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side and, more specifically, the Session Beans.

The content of this guide is the following:

1. Target Audience and Content 2. Introduction 3. The Home Interface 4. The Component Interface 5. The Enterprise Bean Class 6. Tuning Stateless Session Bean Pool

Introduction

A Session Bean is composed of the following parts, which are developed by the Enterprise Bean Provider:

• The Component Interface is the client view of the bean. It contains all the "business methods" of the bean. • The Home Interface contains all the methods for the bean life cycle (creation, suppression) used by the client application. • The bean implementation class implements the business methods and all the methods (described in the EJB specification), allowing the bean to be managed in the container. • The deployment descriptor contains the bean properties that can be edited at assembly or deployment time.

Note that, according to the EJB 2.0 specification, the couple "Component Interface and Home Interface" may be either local or remote. Local Interfaces (Home and Component) are to be used by a client running in the same JVM as the EJB component. Create and finder methods of a local or remote home interface return local or remote component interfaces respectively. An EJB component can have both remote and local interfaces, even if typically only one type of interface is provided.

The description of these elements is provided in the following sections.

Note: in this documentation, the term "Bean" always means "Enterprise Bean."

A session bean object is a short−lived object that executes on behalf of a single client.There are stateless and stateful session beans. Stateless beans do not maintain state across method calls. Any instance of stateless beans can be used by any client at any time. Stateful session beans maintain state within and between transactions. Each stateful session bean object is associated with a specific client. A stateful session bean with container−managed transaction demarcation can optionally implement the SessionSynchronization interface. In this case, the bean objects will be informed of transaction boundaries. A rollback could result in a session bean object's state being inconsistent; in this

EJB Programmer's Guide: Developing Session Beans 93 EJB Programmer's Guide: Developing Session Beans

case, implementing the SessionSynchronization interface may enable the bean object to update its state according to the transaction completion status.

The Home Interface

A Session bean's home interface defines one or more create(...) methods. Each create method must be named create and must match one of the ejbCreate methods defined in the enterprise Bean class. The return type of a create method must be the enterprise Bean's remote interface type. The home interface of a stateless session bean must have one create method that takes no arguments.

All the exceptions defined in the throws clause of an ejbCreate method must be defined in the throws clause of the matching create method of the home interface.

A remote home interface extends the javax.ejb.EJBHome interface, while a local home interface extends the javax.ejb.EJBLocalHome interface.

Example:

The following examples use a Session Bean named Op.

public interface OpHome extends EJBHome { Op create(String user) throws CreateException, RemoteException; }

A local home interface could be defined as follows (LocalOp being the local component interface of the bean):

public interface LocalOpHome extends EJBLocalHome { LocalOp create(String user) throws CreateException; }

The Component Interface

The Component Interface is the client's view of an instance of the session bean. This interface contains the business methods of the enterprise bean. The interface must extend the javax.ejb.EJBObject interface if it is remote, or the javax.ejb.EJBLocalObject if it is local. The methods defined in a remote component interface must follow the rules for Java RMI (this means that their arguments and return value must be valid types for java RMI, and their throws clause must include the java.rmi.RemoteException). For each method defined in the component interface, there must be a matching method in the enterprise Bean's class (same name, same arguments number and types, same return type, and same exception list, except for RemoteException).

The Home Interface 94 EJB Programmer's Guide: Developing Session Beans

Example:

public interface Op extends EJBObject { public void buy (int Shares) throws RemoteException; public int read () throws RemoteException; }

The same type of component interface could be defined as a local interface (even if it is not considered good design to define the same interface as both local and remote):

public interface LocalOp extends EJBLocalObject { public void buy (int Shares); public int read (); }

The Enterprise Bean Class

This class implements the Bean's business methods of the component interface and the methods of the SessionBean interface, which are those dedicated to the EJB environment. The class must be defined as public and may not be abstract. The Session Bean interface methods that the EJB provider must develop are the following:

• public void setSessionContext(SessionContext ic);

This method is used by the container to pass a reference to the SessionContext to the bean instance. The container invokes this method on an instance after the instance has been created. Generally, this method stores this reference in an instance variable. • public void ejbRemove();

This method is invoked by the container when the instance is in the process of being removed by the container. Since most session Beans do not have any resource state to clean up, the implementation of this method is typically left empty. • public void ejbPassivate();

This method is invoked by the container when it wants to passivate the instance. After this method completes, the instance must be in a state that allows the container to use the Java Serialization protocol to externalize and store the instance's state. • public voidejbActivate();

This method is invoked by the container when the instance has just been reactivated. The instance should acquire any resource that it has released earlier in the ejbPassivate() method.

A stateful session Bean with container−managed transaction demarcation can optionally implement the javax.ejb.SessionSynchronization interface. This interface can provide the Bean with transaction synchronization notifications. The Session Synchronization interface methods that the EJB provider must develop are

The Component Interface 95 EJB Programmer's Guide: Developing Session Beans

the following:

• public void afterBegin();

This method notifies a session Bean instance that a new transaction has started. At this point the instance is already in the transaction and can do any work it requires within the scope of the transaction. • public void afterCompletion(boolean committed);

This method notifies a session Bean instance that a transaction commit protocol has completed and tells the instance whether the transaction has been committed or rolled back. • public void beforeCompletion();

This method notifies a session Bean instance that a transaction is about to be committed.

Example: package sb; import java.rmi.RemoteException; import javax.ejb.EJBException; import javax.ejb.EJBObject; import javax.ejb.SessionBean; import javax.ejb.SessionContext; import javax.ejb.SessionSynchronization; import javax.naming.InitialContext; import javax.naming.NamingException;

// This is an example of Session Bean, stateful, and synchronized. public class OpBean implements SessionBean, SessionSynchronization {

protected int total = 0; // actual state of the bean protected int newtotal = 0; // value inside Tx, not yet committed. protected String clientUser = null; protected SessionContext sessionContext = null;

public void ejbCreate(String user) { total = 0; newtotal = total; clientUser = user; }

public void ejbActivate() { // Nothing to do for this simple example }

public void ejbPassivate() { // Nothing to do for this simple example }

public void ejbRemove() {

The Enterprise Bean Class 96 EJB Programmer's Guide: Developing Session Beans

// Nothing to do for this simple example }

public void setSessionContext(SessionContext sessionContext) { this.sessionContext = sessionContext; }

public void afterBegin() { newtotal = total; }

public void beforeCompletion() { // Nothing to do for this simple example

// We can access the bean environment everywhere in the bean, // for example here! try { InitialContext ictx = new InitialContext(); String value = (String) ictx.lookup("java:comp/env/prop1"); // value should be the one defined in ejb−jar.xml } catch (NamingException e) { throw new EJBException(e); } }

public void afterCompletion(boolean committed) { if (committed) { total = newtotal; } else { newtotal = total; } }

public void buy(int s) { newtotal = newtotal + s; return; }

public int read() { return newtotal; } }

Tuning Stateless Session Bean Pool

JOnAS handles a pool for each stateless session bean. The pool can be configured in the JOnAS−specific deployment descriptor with the following tags:

Tuning Stateless Session Bean Pool 97 EJB Programmer's Guide: Developing Session Beans

min−pool−size

This optional integer value represents the minimum instances that will be created in the pool when the bean is loaded. This will improve bean instance creation time, at least for the first beans. The default value is 0. max−cache−size

This optional integer value represents the maximum of instances in memory. The purpose of this value is to keep JOnAS scalable. The policy is the following: At bean creation time, an instance is taken from the pool of free instances. If the pool is empty, a new instance is always created. When the instance must be released (at the end of a business method), it is pushed into the pool, except if the current number of instances created exceeds the max−cache−size, in which case this instance is dropped. The default value is no limit. example

SessSLR EJB/SessHome 20 10

Tuning Stateless Session Bean Pool 98 EJB Programmer's Guide: Developing Entity Beans

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side, and more specifically the Entity Beans.

The content of this guide is the following:

1. Target Audience and content 2. Introduction 3. The Home Interface 4. The Component Interface 5. The Primary Key Class 6. The Enterprise Bean Class 7. Writing Database Access Operations (bean−managed persistence) 8. Configuring Database Access for Container−managed Persistence 9. Tuning Container for Entity Bean Optimizations 10. Using CMP2.0 Persistence ♦ Standard CMP2.0 Aspects ◊ Entity Bean Implementation Class ◊ Standard Deployment Descriptor ♦ JOnAS EJBQL extension ◊ LIMIT clause ♦ JOnAS Database Mappers ♦ JOnAS Database Mapping (Specific Deployment Descriptor) ◊ Specifying and Initializing the Database ◊ CMP fields Mapping ◊ CMR fields Mapping to primary−key−fields (simple pk) ◊ CMR fields Mapping to composite primary−keys

Introduction

An Entity Bean is comprised of the following elements, which are developed by the Enterprise Bean Provider:

• The Component Interface is the client view of the bean. It contains all the "business methods" of the bean. • The Home Interface contains all the methods for the bean life cycle (creation, suppression) and for instance retrieval (finding one or several bean objects) used by the client application. It can also contain methods called "home methods," supplied by the bean provider, for business logic which is not specific to a bean instance. • The Primary Key class (for entity beans only) contains a subset of the bean's fields that identifies a particular instance of an entity bean. This class is optional since the bean programmer can alternatively choose a standard class (for example, java.lang.String) • The bean implementation class implements the business methods and all the methods (described in the EJB

EJB Programmer's Guide: Developing Entity Beans 99 EJB Programmer's Guide: Developing Entity Beans

specification) allowing the bean to be managed in the container. • The deployment descriptor, containing the bean properties that can be edited at assembly or deployment time.

Note that, according to the EJB 2.0 specification, the couple "Component Interface and Home Interface" can be either local or remote. Local Interfaces (Home and Component) are to be used by a client running in the same JVM as the EJB component. Create and finder methods of a local (or remote) home interface return local (or remote) component interfaces. An EJB component may have both remote and local interfaces, even if normally only one type of interface is provided. If an entity bean is the target of a container−managed relationship (refer to EJB 2.0 persistence), then it must have local interfaces.

The description of these elements is provided in the following sections.

Note that in this documentation, the term "Bean" always means "Enterprise Bean."

An entity bean represents persistent data. It is an object view of an entity stored in a relational database. The persistence of an entity bean can be handled in two ways:

• Container−Managed Persistence: the persistence is implicitly managed by the container, no code for data access is supplied by the bean provider. The bean's state will be stored in a relational database according to a mapping description delivered within the deployment descriptor (CMP 1.1) or according to an implicit mapping (CMP 2.0). • Bean−Managed Persistence: the bean provider writes the database access operations (JDBC code) in the methods of the enterprise bean that are specified for data creation, load, store, retrieval, and remove operations (ejbCreate, ejbLoad, ejbStore, ejbFind..., ejbRemove).

Currently, the platform handles persistence in relational storage systems through the JDBC interface. For both container−managed and bean−managed persistence, JDBC connections are obtained from an object provided at the EJB server level, the DataSource. The DataSource interface is defined in the JDBC 2.0 standard extensions. A DataSource object identifies a database and a means to access it via JDBC (a JDBC driver). An EJB server may propose access to several databases and thus provides the corresponding DataSource objects. DataSources are described in more detail in the section "Configuring JDBC DataSources."

The Home Interface

In addition to "home business methods," the Home interface is used by any client application to create, remove, and retrieve instances of the entity bean. The bean provider only needs to provide the desired interface; the container will automatically provide the implementation. The interface must extend the javax.ejb.EJBHome interface if it is remote, or the javax.ejb.EJBLocalHome interface if it is local. The methods of a remote home interface must follow the rules for java RMI. The signatures of the "create" and "find..." methods should match the signatures of the "ejbCreate" and "ejbFind..." methods that will be provided later in the enterprise bean implementation class (same number and types of arguments, but different return types). create methods:

The Home Interface 100 EJB Programmer's Guide: Developing Entity Beans

• The return type is the enterprise bean's component interface. • The exceptions defined in the throws clause must include the exceptions defined for the ejbCreate and ejbPostCreate methods, and must include javax.ejb.CreateException and java.rmi.RemoteException (the latter, only for a remote interface). remove methods:

• The interfaces for these methods must not be defined, they are inherited from EJBHome or EJBLocalHome. • The method is void remove taking as argument the primary key object or the handle (for a remote interface). • The exceptions defined in the throws clause should be javax.ejb.RemoveException and java.rmi.RemoteException for a remote interface. • The exceptions defined in the throws clause should be javax.ejb.RemoveException and java.ejb.EJBException for a local interface. finder methods:

Finder methods are used to search for an EJB object or a collection of EJB objects. The arguments of the method are used by the entity bean implementation to locate the requested entity objects. For bean−managed persistence, the bean provider is responsible for developing the corresponding ejbFinder methods in the bean implementation. For container−managed persistence, the bean provider does not write these methods; they are generated at deployment time by the platform tools; the description of the method is provided in the deployment descriptor, as defined in the section "Configuring database access for container−managed persistence." In the Home interface, the finder methods must adhere to the following rules:

• They must be named "find" (e.g. findLargeAccounts). • The return type must be the enterprise bean's component interface, or a collection thereof. • The exceptions defined in the throws clause must include the exceptions defined for the matching ejbFind method, and must include javax.ejb.FinderException and java.rmi.RemoteException (the latter, only for a remote interface).

At least one of these methods is mandatory: findByPrimaryKey, which takes as argument a primary key value and returns the corresponding EJB object. home methods:

• Home methods are methods that the bean provider supplies for business logic that is not specific to an entity bean instance. • The throws clause of every home method on the remote home interface includes the java.rmi.RemoteException. • Home methods implementation is provided by the bean developer in the bean implementation class as public static methods named ejbHome(...), where is the name of the method in the home interface.

The Home Interface 101 EJB Programmer's Guide: Developing Entity Beans

Example

The Account bean example, provided with the platform examples, is used to illustrate these concepts. The state of an entity bean instance is stored in a relational database, where the following table should exist, if CMP 1.1 is used: create table ACCOUNT (ACCNO integer primary key, CUSTOMER varchar(30), BALANCE number(15,4)); public interface AccountHome extends EJBHome {

public Account create(int accno, String customer, double balance) throws RemoteException, CreateException;

public Account findByPrimaryKey(Integer pk) throws RemoteException, FinderException;

public Account findByNumber(int accno) throws RemoteException, FinderException;

public Enumeration findLargeAccounts(double val) throws RemoteException, FinderException; }

The Component Interface

Business methods:

The Component Interface is the client's view of an instance of the entity bean. It is what is returned to the client by the Home interface after creating or finding an entity bean instance. This interface contains the business methods of the enterprise bean. The interface must extend the javax.ejb.EJBObject interface if it is remote, or the javax.ejb.EJBLocalObject if it is local. The methods of a remote component interface must follow the rules for java RMI. For each method defined in this component interface, there must be a matching method of the bean implementation class (same arguments number and types, same return type, same exceptions except for RemoteException).

Example public interface Account extends EJBObject { public double getBalance() throws RemoteException; public void setBalance(double d) throws RemoteException; public String getCustomer() throws RemoteException; public void setCustomer(String c) throws RemoteException; public int getNumber() throws RemoteException; }

The Home Interface 102 EJB Programmer's Guide: Developing Entity Beans

The Primary Key Class

The Primary Key class is necessary for entity beans only. It encapsulates the fields representing the primary key of an entity bean in a single object. If the primary key in the database table is composed of a single column with a basic data type, the simplest way to define the primary key in the bean is to use a standard java class (for example, java.lang.Integer or java.lang.String). This must have the same type as a field in the bean class. It is not possible to define it as a primitive field (for example, int, float or boolean). Then, it is only necessary to specify the type of the primary key in the deployment descriptor:

java.lang.Integer

And, for container−managed persistence, the field which represents the primary key:

accno

The alternative way is to define its own Primary Key class, described as follows:

The class must be serializable and must provide suitable implementation of the hashcode() and equals(Object) methods.

For container−managed persistence, the following rules must be followed:

• The fields of the primary key class must be declared as public. • The primary key class must have a public default constructor. • The names of the fields in the primary key class must be a subset of the names of the container−managed fields of the enterprise bean.

Example public class AccountBeanPK implements java.io.Serializable {

public int accno;

public AccountBeanPK(int accno) { this.accno = accno; }

public AccountBeanPK() { }

public int hashcode() { return accno; }

public boolean equals(Object other) {

...

}

The Primary Key Class 103 EJB Programmer's Guide: Developing Entity Beans

}

Special case: Automatic generation of primary keys field

There are two ways to manage the automatic primary key with JOnAS. The first method is closer to what is described in the EJB specification, i.e. an automatic PK is a hidden field, the type of which is not known even by the application. The second method is to declare a usual PK CMP field of type java.lang.Integer as automatic. The two cases are described below.

1) Standard automatic primary keys (from JOnAS 4.0.0)

In this case, an automatic PK is a hidden field, the type of which is not known even by the application. All that is necessary is to stipulate in the standard deployment descriptor that this EJB has an automatic PK, by specifying java.lang.Object as primkey−class. The primary key will be completely hidden to the application (no CMP field, no getter/setter method). This is valid for both CMP 2.x and CMP1 entity beans. The container will create an internal CMP field and generate its value when the entity bean is created.

Example:

Standard deployment descriptor:

... AddressEJB com.titan.address.AddressHomeLocal com.titan.address.AddressLocal com.titan.address.AddressBean Container java.lang.Object False 2.x Cmp2_Address street city state zip

Address Bean Class extract:

// Primary key is not explicitly initialized during ejbCreate method // No cmp field corresponds to the primary key public Integer ejbCreateAddress(String street, String city, String state, String zip ) throws javax.ejb.CreateException { setStreet(street); setCity(city); setState(state); setZip(zip); return null; }

The Primary Key Class 104 EJB Programmer's Guide: Developing Entity Beans

If nothing else is specified, and the JOnAS default CMP 2 database mapping is used, the JOnAS container will generate a database column with name JPK_ to handle this PK. However, it is possible to specify in the JOnAS−specific Deployment Descriptor the name of the column that will be used to store the PK value in the table, using the specific element, as follows (this is necessary for CMP2 legacy and for CMP1):

JOnAS−specific deployment descriptor:

AddressEJB jdbc_1 FieldPkAuto

2) CMP field as automatic primary key (was already in JOnAS 3.3.x)

The idea is to declare a usual PK CMP field of type java.lang.Integer as automatic, then it no longer appears in create methods and its value is automatically generated by the container at EJB instance creation time. But it is still a cmp field, with getter/setter methods, accessible from the application. Example:

In the standard DD, there is a usual primary key definition,

... java.lang.Integer id id and in the JOnAS−specific Deployment Descriptor, it should be specified that this PK is automatic,

...

true

Note: The automatic primary key is given a unique ID by an algorithm that is based on the system time; therefore, IDs may be not sequential.

Important restriction: This algorithm will not work if used inside a cluster with the same entity bean that is being managed in several jonas servers.

The Primary Key Class 105 EJB Programmer's Guide: Developing Entity Beans

The Enterprise Bean Class

The EJB implementation class implements the bean's business methods of the component interface and the methods dedicated to the EJB environment, the interface of which is explicitly defined in the EJB specification. The class must implement the javax.ejb.EntityBean interface, must be defined as public, cannot be abstract for CMP 1.1, and must be abstract for CMP 2.0 (in this case, the abstract methods are the get and set accessor methods of the bean cmp and cmr fields). Following is a list of the EJB environment dedicated methods that the EJB provider must develop.

The first set of methods are those corresponding to the create and find methods of the Home interface:

• public PrimaryKeyClass ejbCreate(...);

This method is invoked by the container when a client invokes the corresponding create operation on the enterprise Bean's home interface. The method should initialize instance's variables from the input arguments. The returned object should be the primary key of the created instance. For bean−managed persistence, the bean provider should develop here the JDBC code to create the corresponding data in the database. For container−managed persistence, the container will perform the database insert after the ejbCreate method completes and the return value should be null. • public void ejbPostCreate(...);

There is a matching ejbPostCreate method (same input parameters) for each ejbCreate method. The container invokes this method after the execution of the matching ejbCreate(...) method. During the ejbPostCreate method, the object identity is available. • public ejbFind (...); // bean−managed persistence only

The container invokes this method on a bean instance that is not associated with any particular object identity (some kind of class method ...) when the client invokes the corresponding method on the Home interface. The implementation uses the arguments to locate the requested object(s) in the database and returns a primary key (or a collection thereof). Currently, collections will be represented as java.util.Enumeration objects or java.util.Collection. The mandatory FindByPrimaryKey method takes as argument a primary key type value and returns a primary key object (it verifies that the corresponding entity exists in the database). For container−managed persistence, the bean provider does not have to write these finder methods; they are generated at deployment time by the EJB platform tools. The information needed by the EJB platform for automatically generating these finder methods should be provided by the bean programmer. The EJB 1.1 specification does not specify the format of this finder method description; for JOnAS, the CMP 1.1 finder methods description should be provided in the JOnAS−specific deployment descriptor of the Entity Bean (as an SQL query). Refer to the section "Configuring database access for container−managed persistence." The EJB 2.0 specification defines a standard way to describe these finder methods, i.e. in the standard deployment descriptor, as an EJB−QL query. Also refer to the section "Configuring database access for container−managed persistence." Then, the methods of the javax.ejb.EntityBean interface must be implemented:

♦ public void setEntityContext(EntityContext ic);

The Enterprise Bean Class 106 EJB Programmer's Guide: Developing Entity Beans

Used by the container to pass a reference to the EntityContext to the bean instance. The container invokes this method on an instance after the instance has been created. Generally, this method is used to store this reference in an instance variable. ♦ public void unSetEntityContext();

Unset the associated entity context. The container calls this method before removing the instance. This is the last method the container invokes on the instance. ♦ public void ejbActivate();

The container invokes this method when the instance is taken out of the pool of available instances to become associated with a specific EJB object. This method transitions the instance to the ready state. ♦ public void ejbPassivate();

The container invokes this method on an instance before the instance becomes dissociated with a specific EJB object. After this method completes, the container will place the instance into the pool of available instances. ♦ public void ejbRemove();

This method is invoked by the container when a client invokes a remove operation on the enterprise bean. For entity beans with bean−managed persistence, this method should contain the JDBC code to remove the corresponding data in the database. For container−managed persistence, this method is called before the container removes the entity representation in the database. ♦ public void ejbLoad();

The container invokes this method to instruct the instance to synchronize its state by loading it from the underlying database. For bean−managed persistence, the EJB provider should code at this location the JDBC statements for reading the data in the database. For container−managed persistence, loading the data from the database will be done automatically by the container just before ejbLoad is called, and the ejbLoad method should only contain some "after loading calculation statements." ♦ public void ejbStore();

The container invokes this method to instruct the instance to synchronize its state by storing it to the underlying database. For bean−managed persistence, the EJB provider should code at this location the JDBC statements for writing the data in the database. For entity beans with container−managed persistence, this method should only contain some "pre−store statements," since the container will extract the container−managed fields and write them to the database just after the ejbStore method call.

Example

The following examples are for container−managed persistence with EJB 1.1 and EJB 2.0. For bean−managed persistence, refer to the examples delivered with your specific platform.

CMP 1.1

The Enterprise Bean Class 107 EJB Programmer's Guide: Developing Entity Beans

package eb; import java.rmi.RemoteException; import javax.ejb.EntityBean; import javax.ejb.EntityContext; import javax.ejb.ObjectNotFoundException; import javax.ejb.RemoveException; import javax.ejb.EJBException; public class AccountImplBean implements EntityBean {

// Keep the reference on the EntityContext protected EntityContext entityContext;

// Object state public Integer accno; public String customer; public double balance;

public Integer ejbCreate(int val_accno, String val_customer, double val_balance) {

// Init object state accno = new Integer(val_accno); customer = val_customer; balance = val_balance; return null; }

public void ejbPostCreate(int val_accno, String val_customer, double val_balance) { // Nothing to be done for this simple example. }

public void ejbActivate() { // Nothing to be done for this simple example. }

public void ejbLoad() { // Nothing to be done for this simple example, in implicit persistence. }

public void ejbPassivate() { // Nothing to be done for this simple example. }

public void ejbRemove() { // Nothing to be done for this simple example, in implicit persistence. }

public void ejbStore() { // Nothing to be done for this simple example, in implicit persistence. }

public void setEntityContext(EntityContext ctx) {

The Enterprise Bean Class 108 EJB Programmer's Guide: Developing Entity Beans

// Keep the entity context in object entityContext = ctx; }

public void unsetEntityContext() { entityContext = null; }

public double getBalance() { return balance; }

public void setBalance(double d) { balance = balance + d; }

public String getCustomer() { return customer; }

public void setCustomer(String c) { customer = c; }

public int getNumber() { return accno.intValue(); } }

CMP 2.0 import java.rmi.RemoteException; import javax.ejb.EntityBean; import javax.ejb.EntityContext; import javax.ejb.ObjectNotFoundException; import javax.ejb.RemoveException; import javax.ejb.CreateException; import javax.ejb.EJBException; public abstract class AccountImpl2Bean implements EntityBean {

// Keep the reference on the EntityContext protected EntityContext entityContext;

/*======Abstract set and get accessors for cmp fields ======*/

public abstract String getCustomer(); public abstract void setCustomer(String customer);

public abstract double getBalance(); public abstract void setBalance(double balance);

public abstract int getAccno();

The Enterprise Bean Class 109 EJB Programmer's Guide: Developing Entity Beans

public abstract void setAccno(int accno);

/*======ejbCreate methods ======*/

public Integer ejbCreate(int val_accno, String val_customer, double val_balance) throws CreateException {

// Init object state setAccno(val_accno); setCustomer(val_customer); setBalance(val_balance); return null; }

public void ejbPostCreate(int val_accno, String val_customer, double val_balance) { // Nothing to be done for this simple example. }

/*======javax.ejb.EntityBean implementation ======*/

public void ejbActivate() { // Nothing to be done for this simple example. }

public void ejbLoad() { // Nothing to be done for this simple example, in implicit persistence. }

public void ejbPassivate() { // Nothing to be done for this simple example. }

public void ejbRemove() throws RemoveException { // Nothing to be done for this simple example, in implicit persistence. }

public void ejbStore() { // Nothing to be done for this simple example, in implicit persistence. }

public void setEntityContext(EntityContext ctx) {

// Keep the entity context in object entityContext = ctx; }

public void unsetEntityContext() { entityContext = null; }

/** * Business method to get the Account number

The Enterprise Bean Class 110 EJB Programmer's Guide: Developing Entity Beans

*/ public int getNumber() { return getAccno(); }

}

Writing Database Access Operations (bean−managed persistence)

For bean−managed persistence, data access operations are developed by the bean provider using the JDBC interface. However, getting database connections must be obtained through the javax.sql.DataSource interface on a datasource object provided by the EJB platform. This is mandatory since the EJB platform is responsible for managing the connection pool and for transaction management. Thus, to get a JDBC connection, in each method performing database operations, the bean provider must:

• call the getConnection(...) method of the DataSource object, to obtain a connection to perform the JDBC operations in the current transactional context (if there are JDBC operations), • call the close() method on this connection after the database access operations, so that the connection can be returned to the connection pool (and be dissociated from the potential current transaction).

A method that performs database access must always contain the getConnection and close statements, as follows: public void doSomethingInDB (...) { conn = dataSource.getConnection(); ... // Database access operations conn.close(); }

A DataSource object associates a JDBC driver with a database (as an ODBC datasource). It is created and registered in JNDI by the EJB server at launch time (refer also to the section "JDBC DataSources configuration").

A DataSource object is a resource manager connection factory for java.sql.Connection objects, which implements connections to a database management system. The enterprise bean code refers to resource factories using logical names called "Resource manager connection factory references." The resource manager connection factory references are special entries in the enterprise bean environment. The bean provider must use resource manager connection factory references to obtain the datasource object as follow:

• Declare the resource reference in the standard deployment descriptor using a resource−ref element. • Lookup the datasource in the enterprise bean environment using the JNDI interface (refer to the section "Enterprise Bean's Environment").

The deployer binds the resource manager connection factory references to the actual resource factories that are configured in the server. This binding is done in the JOnAS−specific deployment descriptor using the jonas−resource element.

Writing Database Access Operations (bean−managed persistence) 111 EJB Programmer's Guide: Developing Entity Beans

Example

The declaration of the resource reference in the standard deployment descriptor looks like the following:

jdbc/AccountExplDs javax.sql.DataSource Container

The element indicates which of the two resource manager authentication approaches is used:

• Container: the deployer sets up the sign−on information. • Bean: the bean programmer should use the getConnection method with user and password parameters.

The JOnAS−specific deployment descriptor must map the environment JNDI name of the resource to the actual JNDI name of the resource object managed by the EJB server. This is done in the element.

AccountExpl AccountExplHome jdbc/AccountExplDs jdbc_1

The ejbStore method of the same Account example with bean−managed persistence is shown in the following example. It performs JDBC operations to update the database record representing the state of the entity bean instance. The JDBC connection is obtained from the datasource associated with the bean. This datasource has been instantiated by the EJB server and is available for the bean through its resource reference name, which is defined in the standard deployment descriptor.

In the bean, a reference to a datasource object of the EJB server is initialized: it = new InitialContext(); ds = (DataSource)it.lookup("java:comp/env/jdbc/AccountExplDs");

Then, this datasource object is used in the implementation of the methods performing JDBC operations, such as ejbStore, as illustrated in the following: public void ejbStore Connection conn = null; PreparedStatement stmt = null; try { // get a connection conn = ds.getConnection(); // store Object state in DB

Writing Database Access Operations (bean−managed persistence) 112 EJB Programmer's Guide: Developing Entity Beans

stmt = conn.prepareStatement("update account set customer=?,balance=? where accno=?"); stmt.setString(1, customer); stmt.setDouble(2, balance); Integer pk = (Integer)entityContext.getPrimaryKey(); stmt.setInt(3, pk.accno); stmt.executeUpdate(); } catch (SQLException e) { throw new javax.ejb.EJBException("Failed to store bean to database", e); } finally { try { if (stmt != null) stmt.close(); // close statement if (conn != null) conn.close(); // release connection } catch (Exception ignore) {} } }

Note that the close statement instruction may be important if the server is intensively accessed by many clients performing entity bean access. If the statement is not closed in the finally block, since stmt is in the scope of the method, it will be deleted at the end of the method (and the close will be implicitly done). However, it may be some time before the Java garbage collector deletes the statement object. Therefore, if the number of clients performing entity bean access is important, the DBMS may raise a "too many opened cursors" exception (a JDBC statement corresponds to a DBMS cursor). Since connection pooling is performed by the platform, closing the connection will not result in a physical connection close, therefore opened cursors will not be closed. Thus, it is preferable to explicitly close the statement in the method.

It is a good programming practice to put the JDBC connection and JDBC statement close operations in a finally bloc of the try statement.

Configuring Database Access for Container−managed Persistence

The standard way to indicate to an EJB platform that an entity bean has container−managed persistence is to fill the tag of the deployment descriptor with the value "container," and to fill the tag of the deployment descriptor with the list of container−managed fields (the fields that the container will have in charge to make persistent). The CMP version (1.x or 2.x) should also be specified in the tag. In the textual format of the deployment descriptor, this is represented by the following lines:

container 1.x fieldOne fieldTwo

With container−managed persistence the programmer need not develop the code for accessing the data in the relational database; this code is included in the container itself (generated by the platform tools). However, for the EJB platform to know how to access the database and which data to read and write in the database, two types of

Configuring Database Access for Container−managed Persistence 113 EJB Programmer's Guide: Developing Entity Beans

information must be provided with the bean:

• First, the container must know which database to access and how to access it. To do this, the only required information is the name of the DataSource that will be used to get the JDBC connection. For container−managed persistence, only one DataSource per bean should be used. • Then, it is necessary to know the mapping of the bean fields to the underlying database (which table, which column). For CMP 1.1 or CMP 2.0, this mapping is specified by the deployer in the JOnAS−specific deployment descriptor. Note that for CMP 2.0, this mapping may be entirely generated by JOnAS.

The EJB specification does not specify how this information should be provided to the EJB platform by the bean deployer. Therefore, what is described in the remainder of this section is specific to JOnAS.

For CMP 1.1, the bean deployer is responsible for defining the mapping of the bean fields to the database table columns. The name of the DataSource can be set at deployment time, since it depends on the EJB platform configuration. This database configuration information is defined in the JOnAS−specific deployment descriptor via the jdbc−mapping element. The following example defines the mapping for a CMP 1.1 entity bean:

jdbc_1 accountsample mAccno accno mCustomer customer mBalance balance jdbc_1 is the JNDI name of the DataSource object identifying the database. accountsample is the name of the table used to store the bean instances in the database. mAccno, mCustomer, and mBalance are the names of the container−managed fields of the bean to be stored in the accno, customer, and balance columns of the accountsample table. This example applies to container−managed persistence. For bean−managed persistence, the database mapping does not exist.

For a CMP 2.0 entity bean, only the jndi−name element of the jdbc−mapping is mandatory, since the mapping may be generated automatically (for an explicit mapping definition, refer to the "JOnAS Database Mapping" section of the Using CMP2.0 persistence chapter):

jdbc_1 create

Configuring Database Access for Container−managed Persistence 114 EJB Programmer's Guide: Developing Entity Beans

For a CMP 2.0 entity bean, the JOnAS−specific deployment descriptor contains an additional element, cleanup, at the same level as the jdbc−mapping element, which can have one of the following values: removedata at bean loading time, the content of the tables storing the bean data is deleted removeall at bean loading time, the tables storing the bean data are dropped (if they exist) and created none do nothing create default value (if the element is not specified), at bean loading time, the tables for storing the bean data are created if they do not exist

For CMP 1.1, the jdbc−mapping element can also contain information defining the behaviour of the implementation of a find method (i.e. the ejbFind method, that will be generated by the platform tools). This information is represented by the finder−method−jdbc−mapping element.

For each finder method, this element provides a way to define an SQL WHERE clause that will be used in the generated finder method implementation to query the relational table storing the bean entities. Note that the table column names should be used, not the bean field names. Example:

findLargeAccounts where balance > ?

The previous finder method description will cause the platform tools to generate an implementation of ejbFindLargeAccount(double arg) that returns the primary keys of the entity bean objects corresponding to the tuples returned by the "select ... from Account where balance > ?", where '?' will be replaced by the value of the first argument of the findLargeAccount method. If several '?' characters appear in the provided WHERE clause, this means that the finder method has several arguments and the '?' characters will correspond to these arguments, adhering to the order of the method signature.

In the WHERE clause, the parameters can be followed by a number, which specifies the method parameter number that will be used by the query in this position. Example: The WHERE clause of the following finder method can be:

Enumeration findByTextAndDateCondition(String text, java.sql.Date date)

WHERE (description like ?1 OR summary like ?1) AND (?2 > date)

Note that a element for the findByPrimaryKey method is not necessary, since the meaning of this method is known.

Configuring Database Access for Container−managed Persistence 115 EJB Programmer's Guide: Developing Entity Beans

Additionally, note that for CMP 2.0, the information defining the behaviour of the implementation of a find method is located in the standard deployment descriptor, as an EJB−QL query (i.e. this is not JOnAS−specific information). The same finder method example in CMP 2.0:

findLargeAccounts double SELECT OBJECT(o) FROM accountsample o WHERE o.balance > ?1

The datatypes supported for container−managed fields in CMP 1.1 are the following:

JDBC driver Access Java Type JDBC Type methods getBoolean(), boolean BIT setBoolean() byte TINYINT getByte(), setByte() short SMALLINT getShort(), setShort() int INTEGER getInt(), setInt() long BIGINT getLong(), setLong() float FLOAT getFloat(), setFloat() getDouble(), double DOUBLE setDouble byte[] VARBINARY or LONGVARBINARY (1) getBytes(), setBytes() java.lang.String VARCHAR or LONGVARCHAR (1) getString(), setString() getBoolean(), java.lang.Boolean BIT setObject() java.lang.Integer INTEGER getInt(), setObject() java.lang.Short SMALLINT getShort(), setObject() java.lang.Long BIGINT getLong(), setObject() java.lang.Float REAL getFloat(), setObject() getDouble(), java.lang.Double DOUBLE setObject() getBigDecimal(), java.math.BigDecimal NUMERIC setObject() getBigDecimal(), java.math.BigInteger NUMERIC setObject()

Configuring Database Access for Container−managed Persistence 116 EJB Programmer's Guide: Developing Entity Beans

java.sql.Date DATE getDate(), setDate() java.sql.Time TIME getTime(), setTime() getTimestamp(), java.sql.Timestamp TIMESTAMP setTimestamp() any serializable class VARBINARY or LONGVARBINARY (1) getBytes(), setBytes() (1) The mapping for String will normally be VARCHAR, but will turn into LONGVARCHAR if the given value exceeds the driver's limit on VARCHAR values. The case is similar for byte[] and VARBINARY and LONGVARBINARY values.

For CMP 2.0, the supported datatypes depend on the JORM mapper used.

Tuning Container for Entity Bean Optimizations

JOnAS must make a compromise between scalability and performance. For that reason, several tags in the JOnAS−specific deployment descriptor have been introduced. For most applications, there is no need to change the default values for all these tags. See $JONAS_ROOT/xml/jonas−ejb−jar_4_0.xsd for a complete description of the JOnAS−specific deployment descriptor.

Note that if several of these elements are used, they should appear in the following order within the element:

1. is−modified−method−name 2. passivation−timeout 3. inactivity−timeout 4. shared 5. prefetch 6. max−cache−size 7. min−pool−size 8. lock−policy lock−policy

The JOnAS ejb container is able to manage six different lock−policies:

• container−serialized (default): The container ensures the transaction serialization. This policy is suitable for entity beans having non transacted methods that can modify the bean state. It works only if the bean is accessed from 1 jonas server (shared = false). • container−serialized−transacted : The container ensures the transaction serialization. This policy is suitable for most entity beans. • container−read−committed: This policy is similar to container−serialized−transacted, except that accesses outside transaction do not interfere with transactional accesses. This can avoid deadlocks in certain cases, when accessing a bean concurrently with and without a transactional context. The only drawback of this policy is that it consumes more memory (2 instances instead of 1).

Tuning Container for Entity Bean Optimizations 117 EJB Programmer's Guide: Developing Entity Beans

• container−read−uncommitted: all methods share the same instance (like container−serialized), but there is no synchronization. For example, this policy is of interest for read−only entity beans, or if the bean instances are very rarely modified. It will fail if two or more threads try to modify the same instance concurrently. This policy is deprecated because it can be replaced by container−read−write • database: Let the database deal with transaction isolation. With this policy, it is possible to choose the transaction isolation in a database. This may be of interest for applications that heavily use transactional read−only operations, or when the flag shared is needed. It does not work with all databases and is not memory efficient. • read−only: The bean state is never written to the database. If the bean is shared, the bean state is read from the database regularly. • container−read−write: all methods share the same instance (like container−serialized). A synchronization is done only when the instance is modified. No lock is taken while the instance is read only. This policy does not work if the bean is shared, nor for CMP 1.x beans.

Important: If CMP1 beans are deployed, only the following policies should be used:

• container−serialized • container−serialized−transacted • read−only • container−read−committed • database, but only with shared=true. shared

This flag will be defined as true if the bean persistent state can be accessed outside the JOnAS Server. When this flag is false, the JOnAS Server can do some optimization, such as not re−reading the bean state before starting a new transaction. The default value is false if lock−policy is container−serialized, and true in the other cases. prefetch

This is a CMP2−specific option. The default is false. This can be set to true if it is desirable to have a cache managed after finder methods execution, in order to optimize further accesses inside the same transaction.

Important note:

• The prefetch will not be used for methods that have no transactional context. • It is impossible to set the prefetch option if the lock policy is container−read−uncommitted. max−cache−size

This optional integer value represents the maximum number of instances in memory. The purpose of this value is to keep JOnAS scalable. The default value is "no limit". To save memory, this value should be set very low if it is known that instances will not be reused.

Tuning Container for Entity Bean Optimizations 118 EJB Programmer's Guide: Developing Entity Beans

min−pool−size

This optional integer value represents the number of instances that will be created in the pool when the bean is loaded. This will improve bean instance create time, at least for the first instances. The default value is 0. is−modified−method−name

To improve performance of CMP 1.1 entity beans, JOnAS implements the isModified extension. Before performing an update, the container calls a method of the bean whose name is identified in the is−modified−method−name element of the JOnAS−specific deployment descriptor. This method is responsible for determining if the state of the bean has been changed. By doing this, the container determines if it must store data in the database or not.

Note that this is useless with CMP2 entity beans, since this will be done automatically by the container.

Example

The bean implementation manages a boolean isDirty and implements a method that returns the value of this boolean: isModified

private transient boolean isDirty; public boolean isModified() { return isDirty; }

The JOnAS−specific deployment descriptor directs the bean to implement an isModified method:

Item isModified .....

Methods that modify the value of the bean must set the flag isDirty to true. Methods that restore the value of the bean from the database must reset the flag isDirty to false. Therefore, the flag must be set to false in the ejbLoad() and ejbStore() methods. passivation−timeout

Entity bean instances are passivated at the end of each transaction and reactivated at the beginning of the next transaction, when the shared flag has been set to true. In the case where shared has been set to false, a passivation will occur only if max−cache−size has been reached. In the event that these instances are accessed outside of any transaction, their state is kept in memory to improve performance. However, a passivation will occur in three situations:

Tuning Container for Entity Bean Optimizations 119 EJB Programmer's Guide: Developing Entity Beans

1. When the bean is unloaded from the server, at least when the server is stopped. 2. When a transaction is started on this instance. 3. After a configurable timeout. If the bean is always accessed with no transaction, it may be prudent to periodically store the bean state on disk.

This passivation timeout can be configured in the JOnAS−specific deployment descriptor, with the non−mandatory tag . Example:

Item 5 .....

This entity bean will be passivated every five second, if not accessed within transactions. This flag is also used to set the timeout to passivate beans modified inside transactions when max−cache−size has been reached. inactivity−timeout

Bean passivation sends the state of the bean to persistent storage and removes from memory only the bean instance objects that are holding this state. All container objects handling bean access (remote object, interceptors, ...) are kept in memory so that future access will work, requiring only a reload operation (getting the state). It may be advantageous to conserve more memory and completely remove the bean instance from memory; this can be achieved through the element. This element is used to save memory when a bean has not been used for a long period of time. If the bean has not been used after the specified time (in seconds), all its container objects are removed from the server. If a client has kept a reference on a remote object and tries to use it, then the client will receive an exception.

Using CMP2.0 persistence

This section highlights the main differences between CMP as defined in EJB 2.0 specification (called CMP2.0) and CMP as defined in EJB 1.1 specification (called CMP1.1). Major new features in the standard development and deployment of CMP2.0 entity beans are listed (comparing them to CMP1.1), along with JOnAS−specific information. Mapping CMP2.0 entity beans to the database is described in detail. Note that the database mapping can be created entirely by JOnAS, in which case the JOnAS−specific deployment descriptor for an entity bean should contain only the datasource and the element indicating how the database should be initialized.

Standard CMP2.0 Aspects

This section briefly describes the new features available in CMP2.0 as compared to CMP 1.1, and how these features change the development of entity beans.

Tuning Container for Entity Bean Optimizations 120 EJB Programmer's Guide: Developing Entity Beans

Entity Bean Implementation Class

The EJB implementation class 1) implements the bean's business methods of the component interface, 2) implements the methods dedicated to the EJB environment (the interface of which is explicitly defined in the EJB specification), and 3) defines the abstract methods representing both the persistent fields (cmp−fields) and the relationship fields (cmr−fields). The class must implement the javax.ejb.EntityBean interface, be defined as public, and be abstract (which is not the case for CMP1.1, where it must not be abstract). The abstract methods are the get and set accessor methods of the bean cmp and cmr fields. Refer to the examples and details in the section "Developing Entity Beans" of the JOnAS documentation.

Standard Deployment Descriptor

The standard way to indicate to an EJB platform that an entity bean has container−managed persistence is to fill the tag of the deployment descriptor with the value "container," and to fill the tags of the deployment descriptor with the list of container−managed fields (the fields that the container will have in charge to make persistent) and the tags identifying the relationships. The CMP version (1.x or 2.x) should also be specified in the tag. This is represented by the following lines in the deployment descriptor:

container 1.x fieldOne fieldTwo

Note that for running CMP1.1−defined entity beans on an EJB2.0 platform, such as JOnAS 3.x, you must introduce this element in your deployment descriptors, since the default cmp−version value (if not specified) is 2.x.

Note that for CMP 2.0, the information defining the behaviour of the implementation of a find method is located in the standard deployment descriptor as an EJB−QL query (this is not JOnAS−specific information). For CMP 1.1, this information is located in the JOnAS−specific deployment descriptor as an SQL WHERE clause specified in a element.

Finder method example in CMP 2.0: for a findLargeAccounts(double val) method defined on the Account entity bean of the JOnAS eb example.

findLargeAccounts double

Using CMP2.0 persistence 121 EJB Programmer's Guide: Developing Entity Beans

SELECT OBJECT(o) FROM accountsample o WHERE o.balance > ?1

JOnAS EJBQL extension

LIMIT clause

The LIMIT feature has been added to the standard EJBQL query language. This feature enables you to retrieve just a portion of the results generated by the rest of a query.

The syntax of the LIMIT clause is:

limit_clause ::= LIMIT limit_expression (, limit_expression )? limit_expression ::= integer_literal | input_parameter

The first limit_expression corresponds to the start_at range and the second one to the size range.

The limit_clause is the last clause of the query:

ejbql ::= select_clause from_clause [where_clause] [orderby_clause] [limit_clause]

Example:

SELECT OBJECT(c) FROM jt2_Customer AS c ORDER BY c.id LIMIT ?1, 20

Note that this feature is currently not implemented on all the database types supported by JORM/MEDOR.

JOnAS Database mappers

For implementing the EJB 2.0 persistence (CMP2.0), JOnAS relies on the JORM framework. JORM itself relies on JOnAS DataSources (specified in DataSource properties files) for connecting to the actual database. JORM must adapt its object−relational mapping to the underlying database, for which it makes use of adapters called "mappers." Thus, for each type of database (and more precisely for each JDBC driver), the corresponding mapper must be specified in the DataSource. This is the purpose of the datasource.mapper property of the DataSource properties file. Note that all JOnAS−provided DataSource properties files (in JOnAS_ROOT/conf) already contain this property with the correct mapper.

property name description possible values datasource.mapper JORM database mapper • rdb: generic mapper (JDBC standard driver ...) • rdb.cloudscape: Cloudscape • rdb.db2: DB2

Using CMP2.0 persistence 122 EJB Programmer's Guide: Developing Entity Beans

• rdb.firebird: Firebird • rdb.hsql: HSQL • rdb.mckoi: McKoi Db • rdb.mysql: MySQL • rdb.oracle8: Oracle 8 and lesser versions • rdb.oracle: Oracle 9 • rdb.postgres: PostgreSQL (>= 7.2) • rdb.sapdb: Sap DB • rdb.sqlserver: MS Sql Server • rdb.sybase: Sybase

Contact the JOnAS team to obtain a mapper for other databases.

The container code generated at deployment is now independent of the JORM mappers. Until JOnAS 4.1.4, the container code generated at deployment (GenIC or ejbjar ant task) was dependent on this mapper. It was possible to deploy (generate container code) a bean for several mappers in order to change the database (i.e. the DataSource file) without redeploying the bean. These mappers were specified as the mappernames argument of the GenIC command or as the mappernames attribute of the JOnAS ANT ejbjar task. The value was a comma−separated list of mapper names for which the container classes were generated. These mappernames options are now deprecated.

JOnAS Database Mapping (Specific Deployment Descriptor)

The mapping to the database of entity beans and their relationships may be specified in the JOnAS−specific deployment descriptor, in jonas−entity elements, and in jonas−ejb−relation elements. Since JOnAS is able to generate the database mapping, all the elements of the JOnAS−specific deployment descriptor defined in this section (which are sub−elements of jonas−entity or jonas−ejb−relation) are optional, except those for specifying the datasource and the initialization mode (i.e. the jndi−name of jdbc−mapping and cleanup). The default values of these mapping elements, provided in this section, define the JOnAS−generated database mapping.

Specifying and Initializing the Database

For specifying the database within which a CMP 2.0 entity bean is stored, the jndi−name element of the jdbc−mapping is necessary. This is the JNDI name of the DataSource representing the database storing the entity bean.

jdbc_1

For a CMP 2.0 entity bean, the JOnAS−specific deployment descriptor contains an additional element, cleanup, to be specified before the jdbc−mapping element, which can have one of the following values:

Using CMP2.0 persistence 123 EJB Programmer's Guide: Developing Entity Beans

removedata at bean loading time, the content of the tables storing the bean data is deleted removeall at bean loading time, the tables storing the bean data are dropped (if they exist) and created none do nothing create default value (if the element is not specified), at bean loading time, the tables for storing the bean data are created if they do not exist.

It may be useful for testing purposes to delete the database data each time a bean is loaded. For this purpose, the part of the JOnAS−specific deployment descriptor related to the entity bean may look like the following:

removedata jdbc_1

CMP fields Mapping

Mapping CMP fields in CMP2.0 is similar to that of CMP 1.1, but in CMP2.0 it is also possible to specify the SQL type of a column. Usually this SQL type is used if JOnAS creates the table (create value of the cleanup element), and if the JORM default chosen SQL type is not appropriate.

Standard Deployment Descriptor

..... A ..... idA f ..... .....

Database Mapping

t_A

Using CMP2.0 persistence 124 EJB Programmer's Guide: Developing Entity Beans

c_idA c_f

......

JOnAS Deployment Descriptor

..... A ..... jdbc_1 t_A idA c_idA f c_f varchar(40) ..... .....

Defaults values: jndi−name Mandatory jdbc−table−name Optional. Default value is the upper−case CMP2 abstract−schema−name, or the CMP1 ejb−name, suffixed by _. cmp−field−jdbc−mapping Optional. jdbc−field−name Optional. Default value is the field−name suffixed by _. idA_ and f_ in the example. sql−type Optional. Default value defined by JORM.

CMR fields Mapping to primary−key−fields (simple pk)

Using CMP2.0 persistence 125 EJB Programmer's Guide: Developing Entity Beans

1−1 unidirectional relationships

Standard Deployment Descriptor

..... A ..... idA idA ..... ..... B ..... idB idB ..... ..... a−b B −−> a2b One A b A −−> b2a One B .....

Using CMP2.0 persistence 126 EJB Programmer's Guide: Developing Entity Beans

Database Mapping

t_A t_B

c_idA cfk_idB c_idB

......

There is a foreign key in the table of the bean that owns the CMR field.

JOnAS Deployment Descriptor

..... A ..... jdbc_1 t_A/jdbc−table−name> idA c_idA ..... ..... B ..... jdbc_1 t_B/jdbc−table−name> idB c_idB ..... ..... a−b a2b cfk_idb

Using CMP2.0 persistence 127 EJB Programmer's Guide: Developing Entity Beans

..... foreign−key−jdbc−name is the column name of the foreign key in the table of the source bean of the relationship−role. In this example, where the destination bean has a primary−key−field, it is possible to deduce that this foreign−key−jdbc−name column is to be associated with the column of this primary−key−field in the table of the destination bean.

Default values: jonas−ejb−relation Optional foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean, suffixed by _, and by its primary−key−field. B_idb in the example.

1−1 bidirectional relationships

Compared to 1−1 unidirectional relationships, there is a CMR field in both of the beans, thus making two types of mapping possible.

Standard Deployment Descriptor

..... a−b B −−> a2b One A b A −−> b2a One B

Using CMP2.0 persistence 128 EJB Programmer's Guide: Developing Entity Beans

a .....

Database Mapping

Two mappings are possible. One of the tables may hold a foreign key.

Case 1:

t_A t_B

c_idA cfk_idB c_idB

......

Case 2:

t_A t_B

c_idA c_idB cfk_idA

......

JOnAS Deployment Descriptor

Case 1:

..... a−b a2b cfk_idb .....

Using CMP2.0 persistence 129 EJB Programmer's Guide: Developing Entity Beans

Case 2:

..... a−b b2a cfk_ida .....

For the default mapping, the foreign key is in the table of the source bean of the first ejb−relationship−role of the ejb−relation. In the example, the default mapping corresponds to case 1, since the ejb−relationship−role a2b is the first defined in the ejb−relation a−b. Then, the default values are similar to those of the 1−1 unidirectional relationship.

1−N unidirectional relationships

Standard Deployment Descriptor

..... a−b B −−> a2b One A b java.util.Collection A −−> b2a Many B

Using CMP2.0 persistence 130 EJB Programmer's Guide: Developing Entity Beans

.....

Database Mapping

t_A t_B

c_idA c_idB cfk_idA

......

In this case, the foreign key must be in the table of the bean which is on the "many" side of the relationship (i.e. in the table of the source bean of the relationship role with multiplicity many), t_B.

JOnAS Deployment Descriptor

..... a−b b2a cfk_ida .....

Default values: jonas−ejb−relation Optional foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean of the "one" side of the relationship (i.e. the source bean of the relationship role with multiplicity one), suffixed by _, and by its primary−key−field. A_ida in the example.

1−N bidirectional relationships

Similar to 1−N unidirectional relationships, but with a CMR field in each bean.

Using CMP2.0 persistence 131 EJB Programmer's Guide: Developing Entity Beans

Standard Deployment Descriptor

..... a−b B −−> a2b One A b java.util.Collection A −−> b2a Many B a .....

Database mapping

t_A t_B

c_idA c_idB cfk_idA

......

In this case, the foreign key must be in the table of the bean which is on the "many" side of the relationship (i.e. in the table of the source bean of the relationship role with multiplicity many), t_B.

JOnAS Deployment Descriptor

..... a−b

Using CMP2.0 persistence 132 EJB Programmer's Guide: Developing Entity Beans

b2a cfk_ida .....

Default values: jonas−ejb−relation Optional foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean of the "one" side of the relationship (i.e. the source bean of the relationship role with multiplicity one), suffixed by _, and by its primary−key−field. A_ida in the example.

N−1 unidirectional relationships

Similar to 1−N unidirectional relationships, but the CMR field is defined on the "many" side of the relationship, i.e. on the (source bean of the) relationship role with multiplicity "many."

Standard Deployment Descriptor

..... a−b B −−> a2b Many A b A −−> b2a One B

Using CMP2.0 persistence 133 EJB Programmer's Guide: Developing Entity Beans

.....

Database mapping

t_A t_B

c_idA cfk_idB c_idB

......

In this case, the foreign key must be in the table of the bean which is on the "many" side of the relationship (i.e. in table of the source bean of the relationship role with multiplicity many), t_A.

JOnAS Deployment Descriptor

..... a−b a2b cfk_idb .....

Default values: jonas−ejb−relation Optional foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean of the "one" side of the relationship (i.e. the source bean of the relationship role with multiplicity one), suffixed by _, and by its primary−key−field. B_idb in the example.

Using CMP2.0 persistence 134 EJB Programmer's Guide: Developing Entity Beans

N−M unidirectional relationships

Standard Deployment Descriptor

..... a−b B −−> a2b Many A b java.util.Collection A −−> b2a Many B .....

Database mapping

t_A t_B tJoin_AB

c_idA c_idB cfk_idA cfk_idB

......

In this case, there is a join table composed of the foreign keys of each entity bean table.

JOnAS Deployment Descriptor

..... a−b tJoin_AB

Using CMP2.0 persistence 135 EJB Programmer's Guide: Developing Entity Beans

a2b cfk_idb b2a cfk_ida .....

Default values jonas−ejb−relation Optional jdbc−table−name Optional. Default value is built from the abstract−schema−names of the beans, separated by _. A_B in the example. foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean, suffixed by _, and by its primary−key−field. B_idb and A_ida in the example.

N−M bidirectional relationships

Similar to N−M unidirectional relationships, but a CMR field is defined for each bean.

Standard deployment Descriptor

..... a−b B −−> a2b Many A b java.util.Collection

Using CMP2.0 persistence 136 EJB Programmer's Guide: Developing Entity Beans

A −−> b2a Many B a java.util.Collection .....

Database mapping

t_A t_B tJoin_AB

c_idA c_idB cfk_idA cfk_idB

......

In this case, there is a join table composed of the foreign keys of each entity bean table.

JOnAS Deployment Descriptor

..... a−b tJoin_AB a2b cfk_idb b2a cfk_ida .....

Default values:

Using CMP2.0 persistence 137 EJB Programmer's Guide: Developing Entity Beans

jonas−ejb−relation Optional jdbc−table−name Optional. Default value is built from the abstract−schema−names of the beans, separated by _. A_B in the example. foreign−key−jdbc−name Optional. Default value is the abstract−schema−name of the destination bean, suffixed by _, and by its primary−key−field. B_idb and A_ida in the example.

CMR fields Mapping to composite primary−keys

In the case of composite primary keys, the database mapping should provide the capability to specify which column of a foreign key corresponds to which column of the primary key. This is the only difference between relationships based on simple primary keys. For this reason, not all types of relationship are illustrated below.

1−1 bidirectional relationships

Standard Deployment Descriptor

..... A ..... p.PkA ..... id1A id2A ..... ..... B ..... p.PkB ..... id1B id2B ..... .....

Using CMP2.0 persistence 138 EJB Programmer's Guide: Developing Entity Beans

a−b B −−> a2b One A b A −−> b2a One B a .....

Database mapping

Two mappings are possible, one or another of the tables may hold the foreign key.

Case 1:

t_A t_B

c_id1A c_id2A cfk_id1B cfk_id2B c_id1B c_id2B

......

Case 2:

Using CMP2.0 persistence 139 EJB Programmer's Guide: Developing Entity Beans

t_A t_B

c_id1A c_id2A c_id1B c_id2B cfk_id1A cfk_id2A

......

JOnAS Deployment Descriptor

Case 1:

..... a−b a2b cfk_id1b c_id1b cfk_id2b c_id2b .....

Case 2:

..... a−b b2a cfk_id1a c_id1a cfk_id2a c_id2a .....

Using CMP2.0 persistence 140 EJB Programmer's Guide: Developing Entity Beans

For the default mapping (values), the foreign key is in the table of the source bean of the first ejb−relationship−role of the ejb−relation. In the example, the default mapping corresponds to case 1, since the ejb−relationship−role a2b is the first defined in the ejb−relation a−b.

N−M unidirectional relationships

Standard Deployment Descriptor

..... A ..... id1A id2A ..... ..... B ..... id1B id2B ..... ..... a−b B −−> a2b Many A b java.util.Collection A −−> b2a

Using CMP2.0 persistence 141 EJB Programmer's Guide: Developing Entity Beans

Many B .....

Database mapping

t_A t_B tJoin_AB c_id1A c_id2A c_id1B c_id2B cfk_id1A cfk_id2A cfk_id1B cfk_id2B ...... In this case, there is a join table composed of the foreign keys of each entity bean table.

JOnAS Deployment Descriptor

..... a−b tJoin_AB a2b cfk_id1b c_id1b cfk_id2b c_id2b b2a cfk_id1a c_id1a cfk_id2a c_id2a .....

Using CMP2.0 persistence 142 EJB Programmer's Guide: Message−driven Beans

The content of this guide is the following:

1. Description of a Message−driven Bean 2. Developing a Message−driven Bean 3. Administration aspects 4. Running a Message−driven Bean 5. Transactional aspects 6. Example 7. Tuning Message−driven Bean Pool

The EJB 2.1 specification defines a new kind of EJB component for receiving asynchronous messages. This implements some type of "asynchronous EJB component method invocation" mechanism. The Message−driven Bean (also referred to as MDB in the following) is an Enterprise JavaBean, not an Entity Bean or a Session Bean, which plays the role of a JMS MessageListener.

The EJB 2.1 specification contains detailed information about MDB.The Java Message Service Specification 1.1 contains detailed information about JMS. This chapter focuses on the use of Message−driven beans within the JOnAS server.

Description of a Message−driven Bean

A Message−driven Bean is an EJB component that can be considered as a JMS MessageListener, i.e. processing JMS messages asynchronously; it implements the onMessage(javax.jms.Message) method, defined in the javax.jms.MessageListener interface. It is associated with a JMS destination, i.e. a Queue for "point−to−point" messaging or a Topic for "publish/subscribe." The onMessage method is activated on receipt of messages sent by a client application to the corresponding JMS destination. It is possible to associate a JMS message selector to filter the messages that the Message−driven Bean should receive.

JMS messages do not carry any context, thus the onMessage method will execute without pre−existing transactional context. However, a new transaction can be initiated at this moment (refer to the "Transactional aspects" section for more details). The onMessage method can call other methods on the MDB itself or on other beans, and can involve other resources by accessing databases or by sending messages. Such resources are accessed the same way as for other beans (entity or session), i.e. through resource references declared in the deployment descriptor.

The JOnAS container maintains a pool of MDB instances, allowing large volumes of messages to be processed concurrently. An MDB is similar in some ways to a stateless session bean: its instances are relatively short−lived, it retains no state for a specific client, and several instances may be running at the same time.

Developing a Message−driven Bean

The MDB class must implement the javax.jms.MessageListener and the javax.ejb.MessageDrivenBean interfaces. In

EJB Programmer's Guide: Message−driven Beans 143 EJB Programmer's Guide: Message−driven Beans

addition to the onMessage method, the following must be implemented:

• A public constructor with no argument. • public void ejbCreate(): with no arguments, called at the bean instantiation time. It may be used to allocate some resources, such as connection factories, for example if the bean sends messages, or datasources or if the bean accesses databases. • public void ejbRemove(): usually used to free the resources allocated in the ejbCreate method. • public void setMessageDrivenContext(MessageDrivenContext mdc): called by the container after the instance creation, with no transaction context. The JOnAS container provides the bean with a container context that can be used for transaction management, e.g. for calling setRollbackOnly(), getRollbackOnly(), getUserTransaction().

The following is an example of an MDB class: public class MdbBean implements MessageDrivenBean, MessageListener {

private transient MessageDrivenContext mdbContext;

public MdbBean() {}

public void setMessageDrivenContext(MessageDrivenContext ctx) { mdbContext = ctx; }

public void ejbRemove() {}

public void ejbCreate() {}

public void onMessage(Message message) { try { TextMessage mess = (TextMessage)message; System.out.println( "Message received: "+mess.getText()); }catch(JMSException ex){ System.err.println("Exception caught: "+ex); } } }

The destination associated to an MDB is specified in the deployment descriptor of the bean. A destination is a JMS−administered object, accessible via JNDI. The description of an MDB in the EJB 2.0 deployment descriptor contains the following elements, which are specific to MDBs:

• the JMS acknowledgment mode: auto−acknowledge or dups−ok−acknowledge (refer to the JMS specification for the definition of these modes) • an eventual JMS message selector: this is a JMS concept which allows the filtering of the messages sent to the destination • a message−driven−destination, which contains the destination type (Queue or Topic) and the subscription durability (in case of Topic)

EJB Programmer's Guide: Message−driven Beans 144 EJB Programmer's Guide: Message−driven Beans

The following example illustrates such a deployment descriptor:

Describe here the message driven bean Mdb Message Driven Bean Mdb Mdb samplemdb.MdbBean Container Weight >= 60.00 AND LName LIKE 'Sm_th' javax.jms.Topic NonDurable Auto−acknowledge

If the transaction type is "container," the transactional behavior of the MDB's methods are defined as for other enterprise beans in the deployment descriptor, as in the following example:

Mdb * Required

For the onMessage method, only the Required or NotSupported transaction attributes must be used, since there can be no pre−existing transaction context.

For the message selector specified in the previous example, the sent JMS messages are expected to have two properties, "Weight" and "LName," for example assigned in the JMS client program sending the messages, as follows:

message.setDoubleProperty("Weight",75.5); message.setStringProperty("LName","Smith");

Such a message will be received by the Message−driven bean. The message selector syntax is based on a subset of the SQL92. Only messages whose headers and properties match the selector are delivered. Refer to the JMS specification for more details.

The JNDI name of a destination associated with an MDB is defined in the JOnAS−specific deployment descriptor, within a jonas−message−driven element, as illustrated in the following:

EJB Programmer's Guide: Message−driven Beans 145 EJB Programmer's Guide: Message−driven Beans

Mdb sampleTopic

Once the destination is established, a client application can send messages to the MDB through a destination object obtained via JNDI as follows:

Queue q = context.lookup("sampleTopic");

If the client sending messages to the MDB is an EJB component itself, it is preferable that it use a resource environment reference to obtain the destination object. The use of resource environment references is described in the JMS User's Guide (Writing JMS operations within an application component / Accessing the destination object section).

Administration aspects

It is assumed at this point that the JOnAS server will make use of an existing JMS implementation, e.g. Joram, SwiftMQ.

The default policy is that the MDB developer and deployer are not concerned with JMS administration. This means that the developer/deployer will not create or use any JMS Connection factories and will not create a JMS destination (which is necessary for performing JMS operations within an EJB component, refer to the JMS User's Guide); they will simply define the type of destination in the deployment descriptor and identify its JNDI name in the JOnAS−specific deployment descriptor, as described in the previous section. This means that JOnAS will implicitly create the necessary administered objects by using the proprietary administration APIs of the JMS implementation (since the administration APIs are not standardized). To perform such administration operations, JOnAS uses wrappers to the JMS provider administration API. For Joram, the wrapper is org.objectweb.jonas_jms.JmsAdminForJoram (which is the default wrapper class defined by the jonas.service.jms.mom property in the jonas.properties file). For SwiftMQ, a com.swiftmq.appserver.jonas.JmsAdminForSwiftMQ class can be obtained from the SwiftMQ site.

For the purpose of this implicit administration phase, the deployer must add the 'jms' service in the list of the JOnAS services. For the example provided, the jonas.properties file should contain the following: jonas.services registry,security,jtm,dbm,jms,ejb // The jms service must be added jonas.service.ejb.descriptors samplemdb.jar jonas.service.jms.topics sampleTopic // not mandatory

The destination objects may or may not pre−exist. The EJB server will not create the corresponding JMS destination object if it already exists. (Refer also to JMS administration). The sampleTopic should be explicitly declared only if the JOnAS Server is going to create it first, even if the Message−driven bean is not loaded, or if it is use by another client before the Message−driven bean is loaded. In general, it is not necessary to declare the sampleTopic.

Administration aspects 146 EJB Programmer's Guide: Message−driven Beans

JOnAS uses a pool of threads for executing Message−driven bean instances on message reception, thus allowing large volumes of messages to be processed concurrently. As previously explained, MDB instances are stateless and several instances may execute concurrently on behalf of the same MDB. The default size of the pool of thread is 10, and it may be customized via the jonas property jonas.service.ejb.mdbthreadpoolsize, which is specified in the jonas.properties file as in the following example:

jonas.service.ejb.mdbthreadpoolsize 50

Running a Message−driven Bean

To deploy and run a Message−driven Bean, perform the following steps:

• Verify that a registry is running. • Start the Message−Oriented Middleware (the JMS provider implementation). Refer to the section "Launching the Message−Oriented Middleware." • Create and register in JNDI the JMS destination object that will be used by the MDB.

This can be done automatically by the JMS service or explicitly by the proprietary administration facilities of the JMS provider (JMS administration). The JMS service creates the destination object if this destination is declared in the jonas.properties file (as specified in the previous section). • Deploy the MDB component in JOnAS.

Note that, if the destination object is not already created when deploying an MDB, the container asks the JMS service to create it based on the deployment descriptor content. • Run the EJB client application. • Stop the application.

When using JMS, it is very important to stop JOnAS using the jonas stop command; it should not be stopped directly by killing it.

Launching the Message−Oriented Middleware

If the configuration property jonas.services contains the jms service, then the JOnAS JMS service will be launched and may try to launch a JMS implementation (a MOM).

For launching the MOM, three possibilities can be considered:

1. Launching the MOM in the same JVM as JOnAS

This is the default situation obtained by assigning the true value to the configuration property jonas.service.jms.collocated in the jonas.properties file.

jonas.services security,jtm,dbm,jms,ejb // The jms service must be in the list jonas.service.jms.collocated true

Running a Message−driven Bean 147 EJB Programmer's Guide: Message−driven Beans

In this case, the MOM is automatically launched by the JOnAS JMS service at the JOnAS launching time (command jonas start). 2. Launching the MOM in a separate JVM

The Joram MOM can be launched using the command:

JmsServer

For other MOMs, the proprietary command should be used.

The configuration property jonas.service.jms.collocated must be set to false in the jonas.properties file. Setting this property is sufficient if the JORAM's JVM runs on the same host as JONAS, and if the MOM is launched with its default options (unchanged a3servers.xml configuration file under JONAS_BASE/conf or JONAS_ROOT/conf if JONAS_BASE not defined).

jonas.services security,jtm,dbm,jms,ejb // The jms service must be in the list jonas.service.jms.collocated false

To use a specific configuration for the MOM, such as changing the default host (which is localhost) or the default connection port number (which is 16010), requires defining the additional jonas.service.jms.url configuration property as presented in the following case. 3. Launching the MOM on another host

This requires defining the jonas.service.jms.url configuration property. When using Joram, its value should be the Joram URL joram://host:port where host is the host name, and port is the connection port (by default, 16010). For SwiftMQ, the value of the URL is similar to the following: smqp://host:4001/timeout=10000.

jonas.services security,jtm,dbm,jms,ejb // The jms service must be in the list jonas.service.jms.collocated false jonas.service.jms.url joram://host2:16010

• Change Joram default configuration

As mentioned previously, the default host or default connection port number may need to be changed. This requires modifying the a3servers.xml configuration file provided by the JOnAS delivery in JONAS_ROOT/conf directory. For this, JOnAS must be configured with the property jonas.service.jms.collocated set to false, and the property jonas.service.jms.url set to joram://host:port. Additionally, the MOM must have been previously launched with the JmsServer command. This command defines a Transaction property set to fr.dyade.aaa.util.NullTransaction. If the messages need to be persistent, replace the −DTransaction=fr.dyade.aaa.util.NullTransaction option with the −DTransaction=fr.dyade.aaa.util.ATransaction option. Refer to the Joram documentation for more details about this command. To define a more complex configuration (e.g., distribution, multi−servers), refer to the Joram documentation on http://joram.objectweb.org.

Running a Message−driven Bean 148 EJB Programmer's Guide: Message−driven Beans

Transactional aspects

Because a transactional context cannot be carried by a message (according to the EJB 2.0 specification), an MDB will never execute within an existing transaction. However, a transaction may be started during the onMessage method execution, either due to a "required" transaction attribute (container−managed transaction) or because it is explicitly started within the method (if the MDB is bean−managed transacted). In the second case, the message receipt will not be part of the transaction. In the first case, container−managed transaction, the container will start a new transaction before de−queueing the JMS message (the receipt of which will, thus, be part of the started transaction), then enlist the resource manager associated with the arriving message and all the resource managers accessed by the onMessage method. If the onMessage method invokes other enterprise beans, the container passes the transaction context with the invocation. Therefore, the transaction started at the onMessage method execution may involve several operations, such as accessing a database (via a call to an entity bean, or by using a "datasource" resource), or sending messages (by using a "connection factory" resource).

Example

JOnAS provides examples that are located in the examples/src/mdb install directory. samplemdb is a very simple example, the code of which is used in the previous topics for illustrating how to use Message−driven beans. sampleappli is a more complex example that shows how the sending of JMS messages and updates in a database via JDBC may be involved in the same distributed transaction. The following figure illustrates the architecture of this example application.

Transactional aspects 149 EJB Programmer's Guide: Message−driven Beans

Transactional aspects 150 EJB Programmer's Guide: Message−driven Beans

There are two Message−driven beans in this example:

• StockHandlerBean is a Message−driven bean listening to a topic and receiving Map messages. The onMessage method runs in the scope of a transaction started by the container. It sends a Text message on a Queue (OrdersQueue) and updates a Stock element by decreasing the stock quantity. If the stock quantity becomes negative, an exception is received and the current transaction is marked for rollback. • OrderBean is another Message−driven bean listening on the OrdersQueue Queue. On receipt of a Text message on this queue, it writes the corresponding String as a new line in a file ("Order.txt").

The example also includes a CMP entity bean Stock that handles a stock table.

A Stock item is composed of a Stockid (String), which is the primary key, and a Quantity (int). The method decreaseQuantity(int qty) decreases the quantity for the corresponding stockid, but can throw a RemoteException "Negative stock."

The client application SampleAppliClient is a JMS Client that sends several messages on the topic StockHandlerTopic. It uses Map messages with three fields: "CustomerId," "ProductId," "Quantity." Before sending messages, this client calls the EnvBean for creating the StockTable in the database with known values in order to check the results of updates at the end of the test. Eleven messages are sent, the corresponding transactions are committed, and the last message sent causes the transaction to be rolled back.

Compiling this example

To compile examples/src/mdb/sampleappli, use Ant with the $JONAS_ROOT/examples/src/build.xml file.

Running this example

The default configuration of the JMS service in jonas.properties is the following:

jonas.services jmx,security,jtm,dbm,jms,ejb // The jms service must be added jonas.service.ejb.descriptors sampleappli.jar jonas.service.jms.topics StockHandlerTopic jonas.service.jms.queues OrdersQueue jonas.service.jms.collocated true

This indicates that the JMS Server will be launched in the same JVM as the JOnAS Server, and the JMS−administered objects StockHandlerTopic (Topic) and OrdersQueue (Queue) will be created and registered in JNDI, if not already existing.

• Run the JOnAS Server.

jonas start • Deploy the sampleappli container.

Example 151 EJB Programmer's Guide: Message−driven Beans

jonas admin −a sampleappli.jar • Run the EJB client.

jclient sampleappli.SampleAppliClient • Stop the server.

jonas stop

Tuning Message−driven Bean Pool

A pool is handled by JOnAS for each Message−driven bean. The pool can be configured in the JOnAS−specific deployment descriptor with the following tags: min−pool−size

This optional integer value represents the minimum instances that will be created in the pool when the bean is loaded. This will improve bean instance creation time, at least for the first beans. The default value is 0. max−cache−size

This optional integer value represents the maximum number of instances of ServerSession that may be created in memory. The purpose of this value is to keep JOnAS scalable. The policy is the following: When the ConnectionConsumer ask for a ServerSession instance (in order to deliver a new message) JOnAS try to give a instance from the ServerSessionPool. If the pool is empty, a new instance is created only if the number of yet created instances is smaller than max−cache−size parameter. When the max−cache−size is reached the ConnectionConsumer is blocked and it cannot deliver new messages until a ServerSession is eventually returned in the pool. A ServerSession is pushed into the pool at the end of onMessage method. The default value is no limit (this means that a new instance of ServerSession is always created when the pool is empty). example

Mdb mdbTopic 20 10

Tuning Message−driven Bean Pool 152 EJB Programmer's Guide: Transactional Behaviour

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side. It describes how to define the transactional behaviour of an EJB application.

The content of this guide is the following:

1. Target Audience and Content 2. Declarative Transaction Management 3. Bean−managed Transaction 4. Distributed Transaction Management

Declarative Transaction Management

For container−managed transaction management, the transactional behaviour of an enterprise bean is defined at configuration time and is part of the assembly−descriptor element of the standard deployment descriptor. It is possible to define a common behaviour for all the methods of the bean, or to define the behaviour at the method level. This is done by specifying a transactional attribute, which can be one of the following:

• NotSupported: if the method is called within a transaction, this transaction is suspended during the time of the method execution. • Required: if the method is called within a transaction, the method is executed in the scope of this transaction, else, a new transaction is started for the execution of the method, and committed before the method result is sent to the caller. • RequiresNew: the method will always be executed within the scope of a new transaction. The new transaction is started for the execution of the method, and committed before the method result is sent to the caller. If the method is called within a transaction, this transaction is suspended before the new one is started and resumed when the new transaction has completed. • Mandatory: the method should always be called within the scope of a transaction, else the container will throw the TransactionRequired exception. • Supports: the method is invoked within the caller transaction scope; if the caller does not have an associated transaction, the method is invoked without a transaction scope. • Never: The client is required to call the bean without any transaction context; if it is not the case, a java.rmi.RemoteException is thrown by the container.

This is illustrated in the following table:

Transaction Attribute Client transaction Transaction associated with enterprise Bean's method − − NotSupported T1 −

EJB Programmer's Guide: Transactional Behaviour 153 EJB Programmer's Guide: Transactional Behaviour

− T2 Required T1 T1 − T2 RequiresNew T1 T2 − error Mandatory T1 T1 − − Supports T1 T1 − − Never T1 error

In the deployment descriptor, the specification of the transactional attributes appears in the assembly−descriptor as follows:

AccountImpl * Supports AccountImpl getBalance Required AccountImpl setBalance Mandatory

In this example, for all methods of the AccountImpl bean which are not explicitly specified in a container−transaction element, the default transactional attribute is Supports (defined at the bean−level), and the transactional attributes are Required and Mandatory (defined at the method−name level) for the methods getBalance and setBalance respectively.

EJB Programmer's Guide: Transactional Behaviour 154 EJB Programmer's Guide: Transactional Behaviour

Bean−managed Transaction

A bean that manages its transactions itself must set the transaction−type element in its standard deployment descriptor to:

Bean

To demarcate the transaction boundaries in a bean with bean−managed transactions, the bean programmer should use the javax.transaction.UserTransaction interface, which is defined on an EJB server object that may be obtained using the EJBContext.getUserTransaction() method (the SessionContext object or the EntityContext object depending on whether the method is defined on a session or on an entity bean). The following example shows a session bean method "doTxJob" demarcating the transaction boundaries; the UserTransaction object is obtained from the sessionContext object, which should have been initialized in the setSessionContext method (refer to the example of the session bean). public void doTxJob() throws RemoteException { UserTransaction ut = sessionContext.getUserTransaction(); ut.begin(); ... // transactional operations ut.commit(); }

Another way to do this is to use JNDI and to retrieve UserTransaction with the name java:comp/UserTransaction in the initial context.

Distributed Transaction Management

As explained in the previous section, the transactional behaviour of an application can be defined in a declarative way or coded in the bean and/or the client itself (transaction boundaries demarcation). In any case, the distribution aspects of the transactions are completely transparent to the bean provider and to the application assembler. This means that a transaction may involve beans located on several JOnAS servers and that the platform itself will handle management of the global transaction. It will perform the two−phase commit protocol between the different servers, and the bean programmer need do nothing.

Once the beans have been developed and the application has been assembled, it is possible for the deployer and for the administrator to configure the distribution of the different beans on one or several machines, and within one or several JOnAS servers. This can be done without impacting either the beans code or their deployment descriptors. The distributed configuration is specified at launch time. In the environment properties of an EJB server, the following can be specified:

• which enterprise beans the JOnAS server will handle, • if a Java Transaction Monitor will be located in the same Java Virtual Machine (JVM) or not.

To achieve this goal, two properties must be set in the jonas.properties file, jonas.service.ejb.descriptors and jonas.service.jtm.remote. The first one lists the beans that will be handled on this server (by specifying the name of

Bean−managed Transaction 155 EJB Programmer's Guide: Transactional Behaviour

their ejb−jar files), and the second one sets the Java Transaction Monitor (JTM) launching mode:

• if set to true, the JTM is remote, i.e. the JTM must be launched previously in another JVM, • if set to false, the JTM is local, i.e. it will run in the same JVM as the EJB Server.

Example:

jonas.service.ejb.descriptors Bean1.jar, Bean2.jar jonas.service.jtm.remote false

The Java Transaction Monitor can run outside any EJB server, in which case it can be launched in a stand−alone mode using the following command:

TMServer

Using these configuration facilities, it is possible to adapt the beans distribution to the resources (cpu and data) location, for optimizing performance.

The following figure illustrates four cases of distribution configuration for three beans.

1. Case 1: The three beans B1, B2, and B3 are located on the same JOnAS server, which embeds a Java Transaction Monitor. 2. Case 2: The three beans are located on different JOnAS servers, one of them running the Java Transaction Monitor, which manages the global transaction.

Bean−managed Transaction 156 EJB Programmer's Guide: Transactional Behaviour

3. Case 3: The three beans are located on different JOnAS servers, the Java Transaction Monitor is running outside of any JOnAS server. 4. Case 4: The three beans are located on different JOnAS servers. Each server is running a Java Transaction Monitor. One of the JTM acts as the master monitor, while the two others are slaves.

These different configuration cases may be obtained by launching the JOnAS servers and eventually the JTM (case 3) with the adequate properties. The rational when choosing one of these configurations is resources location and load balancing. However, consider the following pointers:

• if the beans should run on the same machine, with the same server configuration, case 1 is the more appropriate; • if the beans should run on different machines, case 4 is the more appropriate, since it favours local transaction management; • if the beans should run on the same machine, but require different server configurations, case 2 is a good approach.

Bean−managed Transaction 157 EJB Programmer's Guide: Enterprise Bean Environment

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side. It describes how an enterprise component can refer to values, resources, or other components in a way that is configurable at deployment time.

The content of this guide is the following:

1. Target Audience and Content 2. Introduction 3. Environment Entries 4. Resource References 5. Resource Environment References 6. EJB References 7. Deprecated EJBContext.getEnvironment() method

Introduction

The enterprise bean environment is a mechanism that allows customization of the enterprise bean's business logic during assembly or deployment. The environment is a way for a bean to refer to a value, to a resource, or to another component so that the code will be independent of the actual referred object. The actual value of such environment references (or variables) is set at deployment time, according to what is contained in the deployment descriptor. The enterprise bean's environment allows the enterprise bean to be customized without the need to access or change the enterprise bean's source code.

The enterprise bean environment is provided by the container (i.e. the JOnAS server) to the bean through the JNDI interface as a JNDI context. The bean code accesses the environment using JNDI with names starting with "java:comp/env/".

Environment Entries

The bean provider declares all the bean environment entries in the deployment descriptor via the env−entry element. The deployer can set or modify the values of the environment entries.

A bean accesses its environment entries with a code similar to the following:

InitialContext ictx = new InitialContext(); Context myenv = ictx.lookup("java:comp/env"); Integer min = (Integer) myenv.lookup("minvalue"); Integer max = (Integer) myenv.lookup("maxvalue");

EJB Programmer's Guide: Enterprise Bean Environment 158 EJB Programmer's Guide: Enterprise Bean Environment

In the standard deployment descriptor, the declaration of these variables are as follows:

minvalue java.lang.Integer 12 maxvalue java.lang.Integer 120

Resource References

The resource references are another examples of environment entries. For such entries, using subcontexts is recommended:

• java:comp/env/jdbc for references to DataSources objects. • java:comp/env/jms for references to JMS connection factories.

In the standard deployment descriptor, the declaration of a resource reference to a JDBC connection factory is:

jdbc/AccountExplDs javax.sql.DataSource Container

And the bean accesses the datasource as in the following:

InitialContext ictx = new InitialContext(); DataSource ds = ictx.lookup("java:comp/env/jdbc/AccountExplDs");

Binding of the resource references to the actual resource manager connection factories that are configured in the EJB server is done in the JOnAS−specific deployment descriptor using the jonas−resource element.

jdbc/AccountExplDs jdbc_1

Resource References 159 EJB Programmer's Guide: Enterprise Bean Environment

Resource Environment References

The resource environment references are another example of environment entries. They allow the Bean Provider to refer to administered objects that are associated with resources (for example, JMS Destinations), by using logical names. Resource environment references are defined in the standard deployment descriptor.

jms/stockQueue javax.jms.Queue

Binding of the resource environment references to administered objects in the target operational environment is done in the JOnAS−specific deployment descriptor using the jonas−resource−env element.

jms/stockQueue myQueue

EJB References

The EJB reference is another special entry in the enterprise bean's environment. EJB references allow the Bean Provider to refer to the homes of other enterprise beans using logical names. For such entries, using the subcontext java:comp/env/ejb is recommended.

The declaration of an EJB reference used for accessing the bean through its remote home and component interfaces in the standard deployment descriptor is shown in the following example:

ejb/ses1 session tests.SS1Home tests.SS1

The declaration of an EJB reference used for accessing the bean through its local home and component interfaces in the standard deployment descriptor is shown in the following example:

ejb/locses1 session tests.LocalSS1Home tests.LocalSS1 LocalBean

Resource Environment References 160 EJB Programmer's Guide: Enterprise Bean Environment

Local interfaces are available in the same JVM as the bean providing this interface. The use of these interfaces also implies that the classloader of the component performing a lookup (bean or servlet component) is a child of the EJB classloader providing the local interface. Local interfaces, then, are not available to outside WARs or outside EJB−JARs even if they run in the same JVM. This is due to the fact that classes of the local interfaces are not visible on the client side. Putting them under the WEB−INF/lib folder of a WAR would not change anything as the two classes would be loaded by different classloaders, which will throw a "ClassCastException".

To summarize, local interfaces are available only for

• beans in a same ejb jar file. • from servlets to beans or ejbs to ejbs but in the same ear file.

If the referred bean is defined in the same ejb−jar or EAR file, the optional ejb−link element of the ejb−ref element can be used to specify the actual referred bean. The value of the ejb−link element is the name of the target enterprise bean, i.e. the name defined in the ejb−name element of the target enterprise bean. If the target enterprise bean is in the same EAR file, but in a different ejb−jar file, the name of the ejb−link element may be the name of the target bean, prefixed by the name of the containing ejb−jar file followed by '#' (e.g. "My_EJBs.jar#bean1"); prefixing by the name of the ejb−jar file is necessary only if some ejb−name conflicts occur, otherwise the name of the target bean is enough. In the following example, the ejb−link element has been added to the ejb−ref (in the referring bean SSA) and a part of the description of the target bean (SS1) is shown:

SSA ... ejb/ses1 session tests.SS1Home tests.SS1 SS1 ... ... SS1 tests.SS1Home tests.LocalSS1Home tests.SS1 tests.LocalSS1 tests.SS1Bean ... ...

Resource Environment References 161 EJB Programmer's Guide: Enterprise Bean Environment

If the bean SS1 was not in the same ejb−jar file as SSA, but in another file named product_ejbs.jar, the ejb−link element could have been:

product_ejbs.jar#SS1

If the referring component and the referred bean are in separate files and not in the same EAR, the current JOnAS implementation does not allow use of the ejb−link element. In this case, to resolve the reference, the jonas−ejb−ref element in the JOnAS−specific deployment descriptor would be used to bind the environment JNDI name of the EJB reference to the actual JNDI name of the associated enterprise bean home. In the following example, it is assumed that the JNDI name of the SS1 bean home is SS1Home_one.

SSA SSAHome ejb/ses1 SS1Home_one ... SS1 SS1Home_one SS1LocalHome_one ...

The bean locates the home interface of the other enterprise bean using the EJB reference with the following code:

InitialContext ictx = new InitialContext(); Context myenv = ictx.lookup("java:comp/env"); SS1Home home = (SS1Home)javax.rmi.PortableRemoteObject.narrow(myEnv.lookup("ejb/ses1"), SS1Home.class);

Deprecated EJBContext.getEnvironment() method

JOnAS provides support for EJB 1.0−style definition of environment properties. EJB1.0 environment must be declared in the ejb10−properties sub−context. For example:

ejb10−properties/foo java.lang.String foo value

Deprecated EJBContext.getEnvironment() method 162 EJB Programmer's Guide: Enterprise Bean Environment

The bean can retrieve its environment with the following code:

SessionContext ctx; Properties prop; public void setSessionContext(SessionContext sc) { ctx = sc; prop = ctx.getEnvironment(); } public mymethod() { String foo = prop.getProperty("foo"); ... }

Deprecated EJBContext.getEnvironment() method 163 EJB Programmer's Guide: Security Management

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side. It explains how security behavior should be defined.

The content of this guide is the following:

1. Target Audience and Content 2. Introduction 3. Declarative Security Management 4. Programmatic Security Management

Introduction

The EJB architecture encourages the Bean programmer to implement the enterprise bean class without hard−coding the security policies and mechanisms into the business methods.

Declarative Security Management

The application assembler can define a security view of the enterprise beans contained in the ejb−jar file. The security view consists of a set of security roles. A security role is a semantic grouping of permissions for a given type of application user that allows that user to successfully use the application. The application assembler can define (declaratively in the deployment descriptor) method permissions for each security role. A method permission is a permission to invoke a specified group of methods for the enterprise beans' home and remote interfaces. The security roles defined by the application assembler present this simplified security view of the enterprise beans application to the deployer; the deployer's view of security requirements for the application is the small set of security roles, rather than a large number of individual methods.

Security roles

The application assembler can define one or more security roles in the deployment descriptor. The application assembler then assigns groups of methods of the enterprise beans' home and remote interfaces to the security roles in order to define the security view of the application.

The scope of the security roles defined in the security−role elements is the ejb−jar file level, and this includes all the enterprise beans in the ejb−jar file.

...

EJB Programmer's Guide: Security Management 164 EJB Programmer's Guide: Security Management

tomcat ...

Method permissions

After defining security roles for the enterprise beans in the ejb−jar file, the application assembler can also specify the methods of the remote and home interfaces that each security role is allowed to invoke.

Method permissions are defined as a binary relationship in the deployment descriptor from the set of security roles to the set of methods of the home and remote interfaces of the enterprise beans, including all their super interfaces (including the methods of the javax.ejb.EJBHome and javax.ejb.EJBObject interfaces). The method permissions relationship includes the pair (R, M) only if the security role R is allowed to invoke the method M.

The application assembler defines the method permissions relationship in the deployment descriptor using the method−permission element as follows:

• Each method−permission element includes a list of one or more security roles and a list of one or more methods. All the listed security roles are allowed to invoke all the listed methods. Each security role in the list is identified by the role−name element, and each method is identified by the method element. • The method permissions relationship is defined as the union of all the method permissions defined in the individual method−permission elements. • A security role or a method can appear in multiple method−permission elements.

It is possible that some methods are not assigned to any security roles. This means that these methods can be accessed by anyone.

The following example illustrates how security roles are assigned to methods' permissions in the deployment descriptor:

... tomcat Op * ...

Programmatic Security Management

Because not all security policies can be expressed declaratively, the EJB architecture also provides a simple programmatic interface that the Bean programmer can use to access the security context from the business methods.

Declarative Security Management 165 EJB Programmer's Guide: Security Management

The javax.ejb.EJBContext interface provides two methods that allow the Bean programmer to access security information about the enterprise bean's caller. public interface javax.ejb.EJBContext { ... // // The following two methods allow the EJB class // to access security information // java.security.Principal getCallerPrincipal() ; boolean isCallerInRole (String roleName) ; ... }

Use of getCallerPrincipal()

The purpose of the getCallerPrincipal() method is to allow the enterprise bean methods to obtain the current caller principal's name. The methods might, for example, use the name as a key to access information in a database.

An enterprise bean can invoke the getCallerPrincipal() method to obtain a java.security.Principal interface representing the current caller. The enterprise bean can then obtain the distinguished name of the caller principal using the getName() method of the java.security.Principal interface.

Use of isCallerInRole(String roleName)

The main purpose of the isCallerInRole(String roleName) method is to allow the Bean programmer to code the security checks that cannot be easily defined declaratively in the deployment descriptor using method permissions. Such a check might impose a role−based limit on a request, or it might depend on information stored in the database.

The enterprise bean code uses the isCallerInRole(String roleName) method to test whether the current caller has been assigned to a given security role or not. Security roles are defined by the application assembler in the deployment descriptor and are assigned to principals by the deployer.

Declaration of security roles referenced from the bean's code

The Bean programmer must declare in the security−role−ref elements of the deployment descriptor all the security role names used in the enterprise bean code. Declaring the security roles' references in the code allows the application assembler or deployer to link the names of the security roles used in the code to the actual security roles defined for an assembled application through the security−role elements.

... ...

Programmatic Security Management 166 EJB Programmer's Guide: Security Management

sb.OpBean ... role1 ... ... ...

The deployment descriptor in this example indicates that the enterprise bean Op makes the security checks using isCallerInRole("role1") in at least one of its business methods.

Linking security role references and security roles

If the security−role elements have been defined in the deployment descriptor, all the security role references declared in the security−role−ref elements must be linked to the security roles defined in the security−role elements.

The following deployment descriptor example shows how to link the security role references named role1 to the security role named tomcat.

... ... Op sb.OpBean ... role1 tomcat ... ... ...

In summary, the role names used in the EJB code (in the isCallerInRole method) are, in fact, references to actual security roles, which makes the EJB code independent of the security configuration described in the deployment descriptor. The programmer makes these role references available to the Bean deployer or application assembler via the security−role−ref elements included in the session or entity elements of the deployment descriptor. Then, the Bean deployer or application assembler must map the security roles defined in the deployment descriptor to the "specific" roles of the target operational environment (e.g. groups on Unix systems). However, this last mapping step is not currently available in JOnAS.

Programmatic Security Management 167 EJB Programmer's Guide: Defining the Deployment Descriptor

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side. It describes how the bean provider should build the deployment descriptors of its components.

The content of this guide is the following:

1. Target Audience and Content 2. Principles 3. Example of Session Descriptors 4. Example of Container−managed Persistence Entity Descriptors (CMP1.1) 5. Tips

Principles

The bean programmer is responsible for providing the deployment descriptor associated with the developed Enterprise Beans. The Bean Provider's responsibilities and the Application Assembler's responsibilities is to provide an XML deployment descriptor that conforms to the deployment descriptor's XML schema as defined in the EBJ specification version 2.1. (Refer to $JONAS_ROOT/xml/ejb−jar_2_1.xsd or http://java.sun.com/xml/ns/j2ee/ejb−jar_2_1.xsd).

To deploy Enterprise JavaBeans on the EJB server, information not defined in the standard XML deployment descriptor may be needed. For example, this information may include the mapping of the bean to the underlying database for an entity bean with container−managed persistence. This information is specified during the deployment step in another XML deployment descriptor that is specific to JOnAS. The JOnAS−specific deployment descriptor's XML schema is located in $JONAS_ROOT/xml/jonas−ejb−jar_X_Y.xsd. The file name of the JOnAS−specific XML deployment descriptor must be the file name of the standard XML deployment descriptor prefixed by 'jonas−'.

The parser gets the specified schema via the classpath (schemas are packaged in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

The standard deployment descriptor should contain structural information for each enterprise bean that includes the following:

• the Enterprise bean's name, • the Enterprise bean's class, • the Enterprise bean's home interface, • the Enterprise bean's remote interface,

EJB Programmer's Guide: Defining the Deployment Descriptor 168 EJB Programmer's Guide: Defining the Deployment Descriptor

• the Enterprise bean's type, • a re−entrancy indication for the entity bean, • the session bean's state management type, • the session bean's transaction demarcation type, • the entity bean's persistence management, • the entity bean's primary key class, • container−managed fields, • environment entries, • the bean's EJB references, • resource manager connection factory references, • transaction attributes.

The JOnAS−specific deployment descriptor contains information for each enterprise bean including:

• the JNDI name of the Home object that implement the Home interface of the enterprise bean, • the JNDI name of the DataSource object corresponding to the resource manager connection factory referenced in the enterprise bean's class, • the JNDI name of each EJB references, • the JNDI name of JMS administered objects, • information for the mapping of the bean to the underlying database, if it is an entity with container−managed persistence.

Example of Session Descriptors

Here is the description of the test's beans ... Bean example one ... Bean example one ExampleOne tests.Ex1Home tests.Ex1 tests.Ex1Bean Stateful Container name1 java.lang.String value1 ejb/ses1

Example of Session Descriptors 169 EJB Programmer's Guide: Defining the Deployment Descriptor

session tests.SS1Home tests.SS1 jdbc/mydb javax.sql.DataSource Application ExampleOne * Required ExampleOne Home * Supports ExampleOne methodOne NotSupported ExampleOne methodTwo int Mandatory ExampleOne methodTwo java.lang.String NotSupported

Example of Session Descriptors 170 EJB Programmer's Guide: Defining the Deployment Descriptor

ExampleOne ExampleOneHome ejb/ses1 SS1Home_one jdbc/mydb jdbc_1

Example of Container−managed Persistence Entity Descriptors (CMP 1.1)

Here is the description of the test's beans ... Bean example one ... Bean example two ExampleTwo tests.Ex2Home tests.Ex2 tests.Ex2LocalHome tests.Ex2Local tests.Ex2Bean Container tests.Ex2PK False 1.x field1 field2

Example of Container−managed Persistence Entity Descriptors (CMP 1.1) 171 EJB Programmer's Guide: Defining the Deployment Descriptor

field3 field3 name1 java.lang.String value1 ExampleTwo * Supports

ExampleTwo ExampleTwoHome ExampleTwoLocalHome jdbc_1 YourTable field1 dbf1 field2 dbf2 field3 dbf3 findByField1 where dbf1 = ?

Example of Container−managed Persistence Entity Descriptors (CMP 1.1) 172 EJB Programmer's Guide: Defining the Deployment Descriptor

Tips

Although some characters, such as ">", are legal, it is good practice to replace them with XML entity references.

The following is a list of the predefined entity references for XML:

< < less than > > greater than & & ampersand ' ' apostrophe quotation " " mark

Tips 173 EJB Programmer's Guide: EJB Packaging

Target Audience and Content

The target audience for this guide is the Enterprise Bean provider, i.e. the person in charge of developing the software components on the server side. It describes how the bean components should be packaged.

The content of this guide is the following:

1. Target Audience and Content 2. Principles

Principles

Enterprise Beans are packaged for deployment in a standard Java programming language Archive file, called an ejb−jar file. This file must contain the following:

The beans' class files The class files of the remote and home interfaces, of the beans' implementations, of the beans' primary key classes (if there are any), and of all necessary classes. The beans' deployment descriptor The ejb−jar file must contain the deployment descriptors, which are made up of: ◊ The standard xml deployment descriptor, in the format defined in the EJB 2.1 specification. Refer to $JONAS_ROOT/xml/ejb−jar_2_1.xsd or http://java.sun.com/xml/ns/j2ee/ejb−jar_2_1.xsd . This deployment descriptor must be stored with the name META−INF/ejb−jar.xml in the ejb−jar file. ◊ The JOnAS−specific XML deployment descriptor in the format defined in $JONAS_ROOT/xml/jonas−ejb−jar_X_Y.xsd. This JOnAS deployment descriptor must be stored with the name META−INF/jonas−ejb−jar.xml in the ejb−jar file.

Example

Before building the ejb−jar file of the Account entity bean example, the java source files must be compiled to obtain the class files and the two XML deployment descriptors must be written.

Then, the ejb−jar file (OpEB.jar) can be built using the jar command:

cd your_bean_class_directory mkdir META−INF cp .../eb/*.xml META−INF jar cvf OpEB.jar sb/*.class META−INF/*.xml

EJB Programmer's Guide: EJB Packaging 174 Web Application Programmer's Guide

Target Audience and Content

The target audience for this guide is the Web component provider, i.e. the person in charge of developing the Web components on the server side. It describes how the Web component provider should build the deployment descriptors of its Web components and how the web components should be packaged.

The content of this guide is the following:

1. Target Audience and Content 2. Developing Web Components ♦ Introduction ♦ The JSP Pages ♦ The Servlets ♦ Accessing an EJB from a Servlet or JSP page 3. Defining the Web Deployment Descriptor ♦ Principles ♦ Examples of Web Deployment Descriptors ♦ Tips 4. WAR Packaging

Developing Web Components

Introduction

A Web Component is a generic term which denotes both JSP pages and Servlets. Web components are packaged in a .war file and can be deployed in a JOnAS server via the web container service. Web components can be integrated in a J2EE application by packing the .war file in an .ear file (refer to the J2EE Application Programmer's Guide).

The JOnAS distribution includes a Web application example: The EarSample example.

The directory structure of this application is the following: etc/xml contains the web.xml file describing the web application etc/resources/web contains html pages and images; JSP pages can also be placed here. src/org/objectweb/earsample/servlets servlet sources src/org/objectweb/earsample/beans beans sources

The bean directory is not needed if beans coming from another application will be used.

Web Application Programmer's Guide 175 Web Application Programmer's Guide

The JSP pages

Java Server Pages (JSP) is a technology that allows regular, static HTML, to be mixed with dynamically−generated HTML written in Java programming language for encapsulating the logic that generates the content for the page. Refer to the Java Server PagesTM and the Quickstart guide for more details.

Example:

The following example shows a sample JSP page that lists the content of a cart.

<%@ page session="true" %>

<%@ page import="java.util.Enumeration" %> <%@ page import="java.util.Vector" %>

Content of your cart

<% Cart cart = (Cart) session.getAttribute("cart"); Vector products = cart.getProducts(); Enumeration enum = products.elements(); // loop through the enumeration while (enum.hasMoreElements()) { Product prod = (Product) enum.nextElement(); %>

<% } // end loop %>

Product Reference	Product Name	Product Price
<%=prod.getReference()%>	<%=prod.getName()%>	<%=prod.getPrice()%>

It is a good idea to hide all the mechanisms for accessing EJBs from JSP pages by using a proxy java bean, referenced

Developing Web Components 176 Web Application Programmer's Guide

in the JSP page by the usebean special tag. This technique is shown in the alarm example, where the .jsp files communicate with the EJB via a proxy java bean ViewProxy.java.

The Servlets

Servlets are modules of Java code that run in an application server for answering client requests. Servlets are not tied to a specific client−server protocol. However, they are most commonly used with HTTP, and the word "Servlet" is often used as referring to an "HTTP Servlet."

Servlets make use of the Java standard extension classes in the packages javax.servlet (the basic Servlet framework) and javax.servlet.http (extensions of the Servlet framework for Servlets that answer HTTP requests).

Typical uses for HTTP Servlets include:

• processing and/or storing data submitted by an HTML form, • providing dynamic content generated by processing a database query, • managing information of the HTTP request.

For more details refer to the JavaTM Servlet Technology and the Servlets tutorial.

Example:

The following example is a sample of a Servlet that lists the content of a cart. This example is the servlet version of the previous JSP page example.

import java.util.Enumeration; import java.util.Vector; import java.io.PrintWriter; import java.io.IOException; import javax.servlet.ServletException; import javax.servlet.http.HttpServlet; import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpSession;

public class GetCartServlet extends HttpServlet {

protected void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {

res.setContentType("text/html"); PrintWriter out = res.getWriter();

out.println(""); out.println(""); out.println("

Content of your cart

"); out.println("");

Developing Web Components 177 Web Application Programmer's Guide

// The header of the table out.println("

"); out.println(""); out.println(""); out.println(""); out.println("");

// Each iteration of the loop display a line of the table HttpSession session = req.getSession(true); Cart cart = (Cart) session.getAttribute("cart"); Vector products = cart.getProducts(); Enumeration enum = products.elements(); while (enum.hasMoreElements()) { Product prod = (Product) enum.nextElement(); int prodId = prod.getReference(); String prodName = prod.getName(); float prodPrice = prod.getPrice(); out.println("

"); out.println("); out.println("); out.println("); out.println(""); }

out.println("

Product Reference	Product Name	Product Price
" + prodId +	" + prodName +	" + prodPrice +

"); out.println(""); out.println(""); out.close(); } }

Accessing an EJB from a Servlet or JSP page

Through the JOnAS web container service, it is possible to access an enterprise java bean and its environment in a J2EE−compliant way.

The following sections describe:

1. How to access the Remote Home interface of a bean. 2. How to access the Local Home interface of a bean. 3. How to access the environment of a bean. 4. How to start transactions in servlets.

Note that all the following code examples are taken from the The EarSample example provided in the JOnAS distribution.

Developing Web Components 178 Web Application Programmer's Guide

Accessing the Remote Home interface of a bean:

In this example the servlet gets the Remote Home interface OpHome registered in JNDI using an EJB reference, then creates a new instance of the session bean: import javax.naming.Context; import javax.naming.InitialContext;

//remote interface import org.objectweb.earsample.beans.secusb.Op; import org.objectweb.earsample.beans.secusb.OpHome;

Context initialContext = null; try { initialContext = new InitialContext(); } catch (Exception e) { out.print("

Cannot get initial context for JNDI: "); out.println(e + "

"); return; } // Connecting to OpHome thru JNDI OpHome opHome = null; try { opHome = (OpHome) PortableRemoteObject.narrow(initialContext.lookup ("java:comp/env/ejb/Op"),OpHome.class); } catch (Exception e) { out.println("

Cannot lookup java:comp/env/ejb/Op: " + e + "

"); return; } // OpBean creation Op op = null; try { op = opHome.create("User1"); } catch (Exception e) { out.println("

Cannot create OpBean: " + e + "

"); return; }

Note that the following elements must be set in the web.xml file tied to this web application:

ejb/Op Session org.objectweb.earsample.beans.secusb.OpHome org.objectweb.earsample.beans.secusb.Op secusb.jar#Op

Developing Web Components 179 Web Application Programmer's Guide

Accessing the Local Home of a bean:

The following example shows how to obtain a local home interface OpLocalHome using an EJB local reference:

//local interfaces import org.objectweb.earsample.beans.secusb.OpLocal; import org.objectweb.earsample.beans.secusb.OpLocalHome;

// Connecting to OpLocalHome thru JNDI OpLocalHome opLocalHome = null; try { opLocalHome = (OpLocalHome) initialContext.lookup("java:comp/env/ejb/OpLocal"); } catch (Exception e) { out.println("

Cannot lookup java:comp/env/ejb/OpLocal: " + e + "

"); return; }

This is found in the web.xml file:

ejb/OpLocal Session org.objectweb.earsample.beans.secusb.OpLocalHome org.objectweb.earsample.beans.secusb.OpLocal secusb.jar#Op

Accessing the environment of the component:

In this example, the servlet seeks to access the component's environment:

String envEntry = null; try { envEntry = (String) initialContext.lookup("java:comp/env/envEntryString"); } catch (Exception e) { out.println("

Cannot get env−entry on JNDI " + e + "

"); return; }

This is the corresponding part of the web.xml file:

envEntryString This is a string from the env−entry java.lang.String

Developing Web Components 180 Web Application Programmer's Guide

Starting transactions in servlets:

The servlet wants to start transactions via the UserTransaction: import javax.transaction.UserTransaction;

// We want to start transactions from client: get UserTransaction UserTransaction utx = null; try { utx = (UserTransaction) initialContext.lookup("java:comp/UserTransaction"); } catch (Exception e) { out.println("

Cannot lookup java:comp/UserTransaction: " + e + "

"); return; }

try { utx.begin(); opLocal.buy(10); opLocal.buy(20); utx.commit();

} catch (Exception e) { out.println("

exception during 1st Tx: " + e + "

"); return; }

Defining the Web Deployment Descriptor

Principles

The Web component programmer is responsible for providing the deployment descriptor associated with the developed web components. The Web component provider's responsibilities and the application assembler's responsibilities are to provide an XML deployment descriptor that conforms to the deployment descriptor's XML schema as defined in the Java TM Servlet Specification Version 2.4. (Refer to $JONAS_ROOT/xml/web−app_2_4.xsd or http://java.sun.com/xml/ns/j2ee/web−app_2_4.xsd).

To customize the Web components, information not defined in the standard XML deployment descriptor may be needed. For example, the information may include the mapping of the name of referenced resources to its JNDI name. This information can be specified during the deployment phase, within another XML deployment descriptor that is specific to JOnAS. The JOnAS−specific deployment descriptor's XML schema is located in $JONAS_ROOT/xml/jonas−web−app_X_Y.xsd. The file name of the JOnAS−specific XML deployment descriptor must be the file name of the standard XML deployment descriptor prefixed by 'jonas−'.

The parser gets the specified schema via the classpath (schemas are packaged in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

The standard deployment descriptor (web.xml) should contain structural information that includes the following:

Developing Web Components 181 Web Application Programmer's Guide

• The Servlet's description (including Servlet's name, Servlet's class or jsp−file, Servlet's initialization parameters), • Environment entries, • EJB references, • EJB local references, • Resource references, • Resource env references.

The JOnAS−specific deployment descriptor (jonas−web.xml) may contain information that includes:

• The JNDI name of the external resources referenced by a Web component, • The JNDI name of the external resources environment referenced by a Web component, • The JNDI name of the referenced bean's by a Web component, • The name of the virtual host on which to deploy the servlets, • The name of the context root on which to deploy the servlets, • The compliance of the web application classloader to the java 2 delegation model or not.

element: If the configuration file of the web container contains virtual hosts, the host on which the WAR file is deployed can be set.

element: The name of the context on which the application will be deployed should be specified. If it is not specified, the context−root used can be one of the following:

• If the war is packaged into an EAR file, the context−root used is the context specified in the application.xml file. • If the war is standalone, the context−root is the name of the war file (i.e, the context−root is jonasAdmin for jonasAdmin.war).

If the context−root is / or empty, the web application is deployed as ROOT context (i.e., http://localhost:9000/).

element: Set the compliance to the java 2 delegation model.

• If true: the web application context uses a classloader, using the Java 2 delegation model (ask parent classloader first). • If false: the class loader searches inside the web application first, before asking parent class loaders.

Examples of Web Deployment Descriptors

• Example of a standard Web Deployment Descriptor (web.xml):

Defining the Web Deployment Descriptor 182 Web Application Programmer's Guide

Op org.objectweb.earsample.servlets.ServletOp

Op /secured/Op

Protected Area /secured/* DELETE GET POST PUT tomcat role1

BASIC Example Basic Authentication Area

envEntryString This is a string from the env−entry java.lang.String

ejb/Op Session org.objectweb.earsample.beans.secusb.OpHome org.objectweb.earsample.beans.secusb.Op

ejb/EjbLinkOp Session org.objectweb.earsample.beans.secusb.OpHome

Defining the Web Deployment Descriptor 183 Web Application Programmer's Guide

org.objectweb.earsample.beans.secusb.Op secusb.jar#Op

ejb/OpLocal Session org.objectweb.earsample.beans.secusb.OpLocalHome org.objectweb.earsample.beans.secusb.OpLocal secusb.jar#Op

• Example of a specific Web Deployment Descriptor (jonas−web.xml):

ejb/Op OpHome

localhost

web−application

Tips

Although some characters, such as ">", are legal, it is good practice to replace them with XML entity references. The following is a list of the predefined entity references for XML:

< < less than > > greater than & & ampersand ' ' apostrophe quotation " " mark

Defining the Web Deployment Descriptor 184 Web Application Programmer's Guide

WAR Packaging

Web components are packaged for deployment in a standard Java programming language Archive file called a war file (Web ARchive), which is a jar similar to the package used for Java class libraries. A war has a specific hierarchical directory structure. The top−level directory of a war is the document root of the application.

The document root is where JSP pages, client−side classes and archives, and static web resources are stored. The document root contains a subdirectory called WEB−INF, which contains the following files and directories:

• web.xml: The standard xml deployment descriptor in the format defined in the Java Servlet 2.4 Specification. Refer to $JONAS_ROOT/xml/web−app_2_4.xsd. • jonas−web.xml: The optional JOnAS−specific XML deployment descriptor in the format defined in $JONAS_ROOT/xml/jonas−web_X_Y.xsd. • classes: a directory that contains the servlet classes and utility classes. • lib: a directory that contains jar archives of libraries (tag libraries and any utility libraries called by server−side classes). If the Web application uses Enterprise Beans, it can also contain ejb−jars. This is necessary to give to the Web components the visibility of the EJB classes. However, if the war is intended to be packed in a ear, the ejb−jars must not be placed here. In this case, they are directly included in the ear. Due to the use of the class loader hierarchy, Web components have the visibility of the EJB classes. Details about the class loader hierarchy are described in JOnAS class loader hierarchy.

Example

Before building a war file, the java source files must be compiled to obtain the class files (located in the WEB−INF/classes directory) and the two XML deployment descriptors must be written.

Then, the war file (.war) is built using the jar command:

cd jar cvf .war *

During the development process, an 'unpacked version' of the war file can be used. Refer to Configuring Web Container Service for information about how to use directories for the web application.

WAR Packaging 185 J2EE Connector Programmer's Guide

The content of this guide is the following:

1. Target Audience and Content 2. Principles 3. Defining the JOnAS Connector Deployment Descriptor 4. Resource Adapter (RAR) Packaging 5. Use and Deployment of a Resource Adapter 6. JDBC Resource Adapters 7. Appendix: Connector Architecture Principles

Target Audience and Content

This chapter is provided for advanced JOnAS users concerned with EAI (Enterprise Application Integration) and using the J2EE Connector Architecture principles (refer to the Appendix for an introduction to the connectors). The target audience for this guide is the Resource Adapter deployer and programmer. It describes the JOnAS specific deployment file (jonas−ra.xml) and the sample code to access deployed RARs.

Principles

Resource Adapters are packaged for deployment in a standard Java programming language Archive file called a rar file (Resource ARchive), which is described in the J2EE Connector Architecture specification.

The standard method for creating the jonas−ra.xml file is to use the RAConfig tool. For a complete description refer to RAConfig.

Defining the JOnAS Connector Deployment Descriptor

The jonas−ra.xml contains JOnAS specific information describing deployment information, logging, pooling, jdbc connections, and RAR config property values.

• Deployment Tags: ♦ jndiname: (Required) Name the RAR will be registered as. This value will be used in the resource−ref section of an EJB. ♦ rarlink: Jndiname of a base RAR file. Useful for deploying multiple connection factories without having to deploy the complete RAR file again. When this is used, the only entry in RAR is a META−INF/jonas−ra.xml. ♦ native−lib: Directory where additional files in the RAR should be deployed. • Logging Tags: ♦ log−enabled: Determines if logging should be enabled for the RAR. ♦ log−topic: Log topic to use for the PrintWriter logger, which allows a separate handler for each deployed RAR.

J2EE Connector Programmer's Guide 186 J2EE Connector Programmer's Guide

• Pooling Tags: ♦ pool−init: Initial size of the managed connection pool. ♦ pool−min: Minimum size of the managed connection pool. ♦ pool−max: Maximum size of the managed connection pool. Value of −1 is unlimited. ♦ pool−max−age: Maximum number of milliseconds to keep the managed connection in the pool. Value of 0 is an unlimited amount of time. ♦ pstmt−max: Maximum number of PreparedStatements per managed connection in the pool. Only needed with the JDBC RA of JOnAS or another database vendor's RAR. Value of 0 is unlimited and −1 disables the cache. • JDBC Connection Tags: Only valid with a Connection implementation of java.sql.Connection. ♦ jdbc−check−level: Level of checking that will be done for the jdbc connection. Values are 0 for no checking, 1 to validate that the connection is not closed before returning it, and greater than 1 to send the jdbc−test−statement. ♦ jdbc−test−statement: Test SQL statement sent on the connection if the jdbc−check−level is set accordingly. • Config Property Value Tags: ♦ Each entry must correspond to the config−property specified in the ra.xml of the RAR file.

Deployment Descriptor Examples

The following portion of a jonas−ra.xml file shows the linking to a base RAR file named BaseRar. All properties from the base RAR will be inherited and any values given in this jonas−ra.xml will override the other values.

rar1 BaseRar nativelib false com.xxx.rar1 ip www.xxx.com . .

The following portion of a jonas−ra.xml file shows the configuration of a jdbc rar file.

jdbc1 nativelib false com.xxx.jdbc1 0 0 100

Defining the JOnAS Connector Deployment Descriptor 187 J2EE Connector Programmer's Guide

0 20 2 select 1 url jdbc:oracle:thin:@test:1521:DB1 . .

Resource Adapter (RAR) Packaging

Resource Adapters are packaged for deployment in a standard Java programming language Archive file called an RAR file (Resource Adapter ARchive). This file can contain the following:

Resource Adapters' deployment descriptor The RAR file must contain the deployment descriptors, which are made up of: ◊ The standard xml deployment descriptor, in the format defined in the J2EE 1.4 specification. Refer to $JONAS_ROOT/xml/connector_1_5.xsd or http://java.sun.com/xml/ns/j2ee/connector_1_5.xsd. This deployment descriptor must be stored with the name META−INF/ra.xml in the RAR file. ◊ The JOnAS−specific XML deployment descriptor in the format defined in $JONAS_ROOT/xml/jonas−ra_X_Y.xsd. This JOnAS deployment descriptor must be stored with the name META−INF/jonas−ra.xml in the RAR file.

Resource adapter components (jar) One or more jars which contain the java interfaces, implementation, and utility classes required by the resource adapter. Platform−specific native libraries One or more native libraries used by the resource adapter Misc One or more html, image files, or locale files used by the resource adapter.

Before deploying an RAR file, the JOnAS−specific XML must be configured and added. Refer to the RAConfig section for information.

Use and Deployment of a Resource Adapter

Accessing Resource Adapter involves the following steps:

• The bean provider must specify the connection factory requirements by declaring a resource manager

Resource Adapter (RAR) Packaging 188 J2EE Connector Programmer's Guide

connection factory reference in its EJB deployment descriptor. For example:

eis/MyEIS javax.resource.cci.ConnectionFactory Container

The mapping to the actual JNDI name of the connection factory (here adapt_1) is done in the JOnAS−specific deployment descriptor with the following element:

eis/MyEIS adapt_1

This means that the bean programmer will have access to a connection factory instance using the JNDI interface via the java:comp/env/eis/MyEIS name:

// obtain the initial JNDI naming context Context inictx = new InitialContext();

// perform JNDI lookup to obtain the connection factory javax.resource.cci.ConnectionFactory cxf = (javax.resource.cci.ConnectionFactory) inictx .lookup("java:comp/env/eis/MyEIS");

The bean programmer can then get a connection by calling the method getConnection on the connection factory.

javax.resource.cci.Connection cx = cxf.getConnection();

The returned connection instance represents an application−level handle to a physical connection for accessing the underlying EIS. After finishing with the connection, it must be closed using the close method on the Connection interface:

cx.close();

• ♦ The resource adapter must be deployed before being used by the application. Deploying the resource adapter requires the following: ◊ Build a JOnAS−specific resource adapter configuration file that will be included in the resource adapter. This jonas−ra XML file is used to configure the resource adapter in the operational environment and reflects the values of all properties declared in the deployment descriptor for the resource adapter, plus additional JOnAS−specific configuration properties. JOnAS

Resource Adapter (RAR) Packaging 189 J2EE Connector Programmer's Guide

provides a deployment tool RAConfig that is capable of building this XML file from an RA deployment descriptor inside an RAR file. Example:

RAConfig −j adap_1 ra

These properties may be specific for each resource adapter and its underlying EIS. They are used to configure the resource adapter via its managedConnectionFactory class. It is mandatory that this class provide getter and setter method for each of its supported properties (as it is required in the Connector Architecture specification).

After configuring the jonas−ra.xml file created above, it can be added to the resource adapter by executing the following:

RAConfig −u jonas−ra.xml ra

This will add the xml file to the ra.rar file, which is now ready for deployment. ♦ The JOnAS resource service must be configured and started at JOnAS launching time: In the jonas.properties file: ◊ Verify that the name resource is included in the jonas.services property. ◊ Use one of the following methods to deploy an RAR file: ⋅ The names of the resource adapter files (the '.rar' suffix is optional) must be added in the list of Resource Adapters to be used in the jonas.service.resource.resources property. If the '.rar' suffix is not used on the property, it will be used when trying to allocate the specified Resource Adapter.

jonas.service.resource.resources MyEIS.rar, MyEIS1

⋅ Place the RAR file in the connectors autoload directory of $JONAS_BASE, default value is $JONAS_BASE/rars/autoload. Note that it may be different if jonas.service.resource.autoload in jonas.properties is configured differently. ⋅ Add the RAR via the "jonas admin −a xxx.rar" command. ⋅ Add the RAR via the JonasAdmin console.

JDBC Resource Adapters

These generic JDBC resource adapters are supplied by JOnAS and are a replacement for the DBM service. Refer to Configuring JDBC Resource Adapters for a complete description and usage guide.

JDBC Resource Adapters 190 J2EE Connector Programmer's Guide

Appendix: Connector Architecture Principles

The Java Connector Architecture allows the connection of different Enterprise Information Systems (EIS) to an application server such as JOnAS. It defines a way for enterprise applications (based on EJB, servlet, JSP or J2EE clients) to communicate with existing EIS. This requires the use of a third party software component called "Resource Adapter" for each type of EIS, which should be previously deployed on the application server. The Resource Adapter is an architecture component comparable to a software driver, which connects the EIS, the application server, and the enterprise application (J2EE components in the case of JOnAS as application server). The RA provides an interface (the Common Client Interface or CCI) to the enterprise application (J2EE components) for accessing the EIS. The RA also provides standard interfaces for plugging into the application server, so that they can collaborate to keep all system−level mechanisms (transactions, security, and connection management) transparent from the application components.

Appendix: Connector Architecture Principles 191 J2EE Connector Programmer's Guide

The resource adapter plugs into JOnAS and provides connectivity between the EIS, JOnAS, and the application. The application performs "business logic" operations on the EIS data using the RA client API (CCI), while transactions, connections (including pooling), and security on the EIS is managed by JOnAS through the RA (system contract).

Appendix: Connector Architecture Principles 192 J2EE Client Application Programmer's Guide

Target Audience and Content

The target audience for this guide is the Client component provider, i.e. the person in charge of developing the Client components on the client side. It describes how the Client component provider should build the deployment descriptors of its Client components and how the client components should be packaged.

The content of this guide is the following:

1. Target Audience and Content 2. Launching J2EE Client Applications ♦ Launching clients ♦ Configuring client container ♦ Examples 3. Defining the Client Deployment Descriptor ♦ Principles ♦ Examples of Client Deployment Descriptors ♦ Tips 4. Client Packaging ♦ Principles

Launching J2EE Client Applications

Launching clients

The J2EE client application can be

• a standalone client in a .jar file, • a client bundle in an .ear file. An ear can contain many java clients. • a class name which must be found in the CLASSPATH.

All the files required to launch the client container are in the JONAS_ROOT/lib/client.jar file. This jar includes a manifest file with the name of the class to launch. To launch the client container, simply type: java −jar $JONAS_ROOT/lib/client.jar −?. This will launch the client container and display usage information about this client container.

To launch the client container on a remote computer, copy the client.jar and invoke the client container by typing java −jar path_to_your/client.jar.

The client that must be launched by the client container is given as an argument of the client container. example : java −jar client.jar myApplication.ear

J2EE Client Application Programmer's Guide 193 J2EE Client Application Programmer's Guide

or java −jar client.jar myClient.jar.

Configuring client container

JNDI access

Defining the JNDI access and the protocol to use is an important part of configuration. The JOnAS server, as well as the ClientContainer, uses the values specified in the carol.properties file. This file can be used at different levels. The carol.properties is searched with the following priority (high to low):

• the carol.properties specified by the −carolFile argument to the client container • the carol.properties packaged into the client application (the jar client) • if not located previously, it will use the carol.properties contained in the JONAS_ROOT/lib/client.jar.

A convenient way is to update the carol.properties of a client.jar with a customized carol.properties file. That is, use the jar −uf client.jar carol.properties command.

Trace configuration

The client container client.jar includes a traceclient.properties file. This is the same file as the one in JONAS_ROOT/conf directory. A different configuration file can be used for the traces by specifying the parameter −traceFile when invoking the client container. The file in the client.jar can be replaced with the jar −uf client.jar traceclient.properties command.

Classpath configuration

Some jars/classes can be added to the client container. For example if a class requires some extra libraries/classes, the option −cp path/to/classes can be used.

The classloader of the client container will use the libraries/classes provided by the −cp flag.

Specifying the client to use (EAR case)

An ear can contain many java clients, which are described in the application.xml file inside the elements. To invoke the client container with an ear, such as java −jar client.jar my.ear, specify the java client to use if there are many clients. Otherwise, it will take the first client. To specify the jar client to use from an ear, use the argument −jarClient and supply the name of the client to use. The earsample example in the JOnAS examples has two java clients in its ear.

Launching J2EE Client Applications 194 J2EE Client Application Programmer's Guide

Specifying the directory for unpacking the ear (EAR case)

By default, the client container will use the system property java.io.tmpdir. To use another temporary directory, specify the path by giving the argument −tmpDirto the client container.

Disable Automated WsGen

By default, the client container will apply WsGen (generation of web services artifacts) on all given archives. To disable that feature (because WsGen has already been applied on the application, or because the client contains no web services), add the −nowsgen option to the client container.

Examples

The earsample and jaasclient examples of the JOnAS examples are packaged for use by the client container. The first example demonstrates the client inside an ear. The second example demonstrates the use of a standalone client.

Defining the Client Deployment Descriptor

Principles

The Client component programmer is responsible for providing the deployment descriptor associated with the developed client components.

The client component provider's responsibilities and the Application Assembler's responsibilities are to provide an XML deployment descriptor that conforms to the deployment descriptor's XML DTD as defined in the Java TM Application Client Specification Version 1.4.(Refer to $JONAS_ROOT/xml/application−client_1_4.xsd or http://java.sun.com/xml/ns/j2ee/application−client_1_4.xsd).

To customize the Client components, information not defined in the standard XML deployment descriptor may be needed. Such information might include, for example, the mapping of the name of referenced resources to its JNDI name. This information can be specified during the deployment phase within another XML deployment descriptor that is specific to JOnAS. The JOnAS−specific deployment descriptor's XML schema is located in $JONAS_ROOT/xml/jonas−client_X_Y.xsd. The file name of the JOnAS−specific XML deployment descriptor must be 'jonas−client.xml'.

JOnAS interprets the tag at the parsing of the deployment descriptor XML files. The parser first tries to get the specified DTD via the classpath, then it uses the specified URL (or path).

The parser gets the specified schema via the classpath (schemas are packaged in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

Launching J2EE Client Applications 195 J2EE Client Application Programmer's Guide

The standard deployment descriptor (application−client.xml) should contain structural information that includes the following:

• A Client description • Environment entries • EJB references • Resource references • Resource env references • The callback handler to use

The JOnAS−specific deployment descriptor (jonas−client.xml) may contain information that includes the following::

• The JNDI name of the external resources referenced by a Client component • The JNDI name of the external resources environment referenced by a Client component • The JNDI name of the beans referenced by a Client component • The security aspects including the jaas file, the jaas entry, and a login/password to use for a specific callback handler

Examples of Client Deployment Descriptors

• Example of a standard Client Deployment Descriptor (application−client.xml):

Client of the earsample client of the earsample

envEntryString java.lang.String Test of envEntry of application−client.xml file

ejb/Op Session org.objectweb.earsample.beans.secusb.OpHome org.objectweb.earsample.beans.secusb.Op secusb.jar#EarOp

url/jonas

Defining the Client Deployment Descriptor 196 J2EE Client Application Programmer's Guide

java.net.URL Container

org.objectweb.jonas.security.auth.callback.LoginCallbackHandler

• Example of a specific Client Deployment Descriptor (jonas−client.xml):

url/jonas http://jonas.objectweb.org

jaas.config earsample jonas jonas

Tips

Although some characters, such as ">", are legal, it is good practice to replace them with XML entity references.

The following is a list of the predefined entity references for XML:

< < less than > > greater than & & ampersand ' ' apostrophe quotation " " mark

Client Packaging

Defining the Client Deployment Descriptor 197 J2EE Client Application Programmer's Guide

Principles

Client components are packaged for deployment in a standard Java programming language Archive file called a jar file (Java ARchive). The document root contains a subdirectory called META−INF, which contains the following files and directories:

• application−client.xml: The standard xml deployment descriptor in the format defined in the J2EE 1.4 Specification. Refer to $JONAS_ROOT/xml/application−client_1_4.xsd. • jonas−client.xml: The optional JOnAS specific xml deployment descriptor in the format defined in $JONAS_ROOT/xml/jonas−client_X_Y.xsd.

The manifest of this client jar must contain the name of the class to launch (containing the main method). This is defined by the value of the Main−Class attribute of the manifest file. For a standalone client (not bundled in an Ear), all the Ejb classes (except the skeleton) on which lookups will be performed must be included.

Example

Two examples of building a java client are provided.

• The first is the build.xml of the earsample example with a java client inside the ear. Refer to the client1jar and client2jar targets. • The second is the build.xml of the jaasclient example with a java standalone client which performs a lookup on an EJB. Refer to the clientjars target.

Client Packaging 198 J2EE Application Assembler's Guide

Target Audience and Content

The target audience for this guide is the Application Provider and Assembler, i.e. the person in charge of combining one or more components (ejb−jars and/or wars) to create a J2EE application. It describes how the J2EE components should be packaged to create a J2EE application.

The content of this guide is the following:

1. Target Audience and Content 2. Defining the Ear Deployment Descriptor ♦ Principles ♦ Simple example of Application deployment Descriptors ♦ Advanced example of Application deployment Descriptors with alternate DD and security ♦ Tips 3. EAR Packaging

Defining the Ear Deployment Descriptor

Principles

The application programmer is responsible for providing the deployment descriptor associated with the developed application (Enterprise ARchive). The Application Assembler's responsibilities is to provide a XML deployment descriptor that conforms to the deployment descriptor's XML schema as defined in the J2EE specification version 1.4. (Refer to $JONAS_ROOT/xml/application_1_4.xsd or http://java.sun.com/xml/ns/j2ee/application_1_4.xsd).

To deploy J2EE applications on the application server, all information is contained in one XML deployment descriptor. The file name for the application XML deployment descriptor is application.xml and it must be located in the top level META−INF directory.

The parser gets the specified schema via the classpath (schemas are packaged in the $JONAS_ROOT/lib/common/ow_jonas.jar file).

Some J2EE application examples are provided in the JOnAS distribution:

• $JONAS_ROOT/examples/alarm for The Alarm demo • $JONAS_ROOT/examples/cmp2 for The Cmp2 example • $JONAS_ROOT/examples/earsample for The EarSample example • $JONAS_ROOT/examples/petstore1.3 for The Blueprints Petstore application

The standard deployment descriptor should contain structural information that includes the following:

J2EE Application Assembler's Guide 199 J2EE Application Assembler's Guide

• EJB components, • Web components, • Client components, • Alternate Deployment Descriptor for theses components, • Security role.

There is no JOnAS−specific deployment descriptor for the Enterprise ARchive.

Simple example of Application Deployment Descriptor

Simple example of application Simple example

ejb1.jar ejb2.jar

web.war web

Advanced example of Application Deployment Descriptors with alternate DD and security

Ear Security Application with alt−dd and security

Defining the Ear Deployment Descriptor 200 J2EE Application Assembler's Guide

admin.war admin ejb.jar altdd.xml admin

Tips

Although some characters, such as ">", are legal, it is good practice to replace them with XML entity references.

The following is a list of the predefined entity references for XML:

< < less than > > greater than & & ampersand ' ' apostrophe quotation " " mark

EAR Packaging

J2EE applications are packaged for deployment in a standard Java programming language Archive file called an ear file (Enterprise ARchive). This file can contain the following:

The web components (war) One or more wars which contain the web components of the J2EE application. Due to the class loader hierarchy, when the wars are packaged in a J2EE application, it is not necessary to package classes of EJBs accessed by the web components in the WEB−INF/lib directory. Details about this class loader hierarchy are described in JOnAS class loader hierarchy. The EJB components (ejb−jar) One or more ejb−jars, which contain the beans of the J2EE application. The RAR components (resource adapters) One or more rars, which contain the resource adapters of the J2EE application. The libraries (jar) One or more jars which contain the libraries (tag libraries and any utility libraries) used for the J2EE application.

Defining the Ear Deployment Descriptor 201 J2EE Application Assembler's Guide

The J2EE deployment descriptor The standard xml deployment descriptor in the format defined in the J2EE 1.4 specification. See $JONAS_ROOT/xml/application_1_4.xsd. This deployment descriptor must be stored with the name META−INF/application.xml in the ear file.

Example

Before building an ear file for a J2EE application, the ejb−jars and the wars that will be packaged in the J2EE application must be built and the XML deployment descriptor (application.xml) must be written.

Then, the ear file (.ear) can be built using the jar command:

cd jar cvf .ear *

EAR Packaging 202 Deployment and Installation Guide

Target audience

The target audience for this guide is the application deployer.

The content of this guide is the following:

1. Deployment and installation process principles 2. Example of deploying and installing an EJB using an ejb−jar file 3. Deploying and installing a Web application 4. Deploying and installing a J2EE application

Deployment and installation process principles

The deployment and installation of Enterprise Beans

This guide assumes that the Enterprise Bean provider followed the Enterprise Beans Programmer's Guide and packaged the beans's classes together with the deployment descriptors in a ejb−jar file. To deploy un−packed Enterprise Beans, refer to Configuring EJB Container service.

To deploy the Enterprise Beans in JOnAS, the deployer must add the interposition classes interfacing the EJB components with the services provided by the JOnAS application server. The GenIC tool supplied in the JOnAS distribution provides the capability of generating interposition classes and updating the ejb−jar file. The application deployer may also need to customize the deployment descriptors in order to adapt it to a specific operational environment. This must be done before using GenIC.

The deployer may choose to deploy the Enterprise Beans as stand−alone application components, in which case the ejb−jar must be installed in the $JONAS_ROOT/ejbjars directory. The deployer may also choose to include them in war or ear packaging, which is presented in the following sections.

The deployment and installation of Web and J2EE applications

Once the packaging of the application components has been completed as described in the WAR Packaging or EAR Packaging guides, the obtained archive file must be installed in the:

• $JONAS_ROOT/webapps directory, for war files • $JONAS_ROOT/apps directory, for ear files

Deployment and Installation Guide 203 Deployment and Installation Guide

Example of deploying and installing an EJB using an ejb−jar file

For this example, it is assumed that a user wants to customize the deployment of the AccountImpl bean in the JOnAS example examples/src/eb by changing the name of the database table used for the persistence of the AccountImpl.

The current directory is $JONAS_ROOT/examples/src/eb. The user will do the following:

• Edit jonas−ejb−jar.xml and modify the value of the element included in the element corresponding to AccountImpl entity. • Compile all the .java files present in this directory: javac −d ../../classes Account.java AccountImplBean.java AccountExplBean.java AccountHome.java ClientAccount.java • Perform deployment ♦ Build an ejbjar file named ejb−jar.jar with all the corresponding classes and the two deployment descriptors: mkdir −p ../../classes/META−INF cp ejb−jar.xml ../../classes/META−INF/ejb−jar.xml cp jonas−ejb−jar.xml ../../classes/META−INF/jonas−ejb−jar.xml cd ../../classes jar cvf eb/ejb−jar.jar META−INF/ejb−jar.xml META−INF/jonas−ejb−jar.xml eb/Account.class eb/AccountExplBean.class eb/AccountHome.class eb/AccountImplBean.class ♦ From the source directory, run the GenIC generation tool that will generate the final ejb−jar.jar file with the interposition classes: GenIC −d ../../classes ejb−jar.jar • Install the ejb−jar in the $JONAS_ROOT/ejbjars directory: cp ../../classes/eb/ejb−jar.jar $JONAS_ROOT/ejbjars/ejb−jar.jar

The JOnAS application Server can now be launched using the command: jonas start

The steps just described for building the new ejb−jar.jar file explain the deployment process. It is generally implemented by an ANT build script.

If Apache ANT is installed on your machine, type ant install in the $JONAS_ROOT/examples/src directory to build and install all ejb−jar.jar files for the examples. To write a build.xml file for ANT, use the ejbjar task, which is one of the optional EJB tasks defined in ANT. The ejbjar task contains a nested element called jonas, which implements the deployment process described above (interposition classes generation and EJB−JAR file update). Generally, the latest version of the EJB task containing an updated implementation of the jonas nested element is provided with JOnAS, in $JONAS_ROOT/lib/common/ow_jonas_ant.jar. Click here for the documentation corresponding to this new version of the jonas nested element. As an example, this code snippet is taken from the $JONAS_ROOT/examples/src/alarm/build.xml:

Example of deploying and installing an EJB using an ejb−jar file 204 Deployment and Installation Guide

Deploying and installing a Web application

Before deploying a web application in the JOnAS application server, first package its components in a war file as explained in the WAR packaging guide. For Apache ANT, refer to the target war in the $JONAS_ROOT/examples/earsample/build.xml file.

Next, install the war file into the $JONAS_ROOT/webapps directory. Note: Be aware that the war file must not be installed in the $CATALINA_HOME/webapps directory.

Then, check the configuration: before running the web application; check that the web service is present in the jonas.services property. The ejb service may also be needed if the Web application uses enterprise beans. The name of the war file can be added in the jonas.service.web.descriptors section.

Finally, run the application Server: jonas start

The web components are deployed in a web container created during the startup. If the war file was not added in the jonas.service.web.descriptors list, the web components can be dynamically deployed using the jonas admin command or JonasAdmin tool.

Deploying and installing a J2EE application

Before deploying a J2EE application in the JOnAS application server, first package its components in an ear file as explained in the EAR packaging guide. For Apache ANT, refer to the target ear in the $JONAS_ROOT/examples/earsample/build.xml file.

Deploying and installing a Web application 205 Deployment and Installation Guide

Next, install the ear file into the $JONAS_ROOT/apps directory.

Then, check the configuration: before running the application, check that the ejb, web and ear services are present in the jonas.services property. The name of the ear file can be added in the jonas.service.ear.descriptors section.

Finally, run the application Server: jonas start

The application components are deployed in EJB and web containers created during the startup. If the ear file was not added in the jonas.service.ear.descriptors list, the application components can be dynamically deployed using the jonas admin command or JonasAdmin tool.

Deploying and installing a Web application 206 Administration Guide

The target audience for this guide is the JOnAS server administrator.

JOnAS provides the following two tools for performing some administration tasks on a running JOnAS Server:

• jonas admin, a command line tool • JonasAdmin, a graphical tool based on the Struts framework and the JMX technology ♦ Installing JonasAdmin ♦ Using JonasAdmin

These tools also allow administration of several JOnAS Servers. Each JOnAS Server is identified by a name, which is the value of the −n option used in the jonas start command (the default name is jonas). Begining with JOnAS 4, we also provide the J2EE Management EJB component (MEJB), as specified by the J2EE Management Specification which defines the J2EE Management Model. jonas admin jonas admin is described in the JOnAS Commands chapter.

JonasAdmin

This chapter provides information about installing, configuring, and using the JonasAdmin administration console.

JonasAdmin is the new administration tool for JOnAS and replaces the deprecated Jadmin tool.

JonasAdmin was developed using the Struts framework; it uses standard technologies such as Java Servlets and JavaServer Pages. JonasAdmin is more ergonomic than Jadmin and provides integrated administration facilities for a Tomcat server running embedded in JOnAS.

Installing JonasAdmin

Designed as a web application, JonasAdmin is packed in a WAR and installed under the JONAS_ROOT/webapps/autoload/ directory. This WAR can be installed in JONAS_BASE/webapps/autoload if a JONAS_BASE variable has been defined in the environment. When installed in the autoload directory, JonasAdmin is deployed when starting the JOnAS server, thus the administration console is automatically accessible.

As with any web application, JonasAdmin requires a servlet server to be installed. Additionally, the JOnAS server running JonasAdmin must have the web container service present in the list of services defined in the jonas.properties configuration file.

Administration Guide 207 Administration Guide

When accessing JonasAdmin, the administrator must provide identification and authentication. The jonas−realm.xml configuration file contains a memory realm definition named memrlm_1, which is referenced in both server.xml (for Tomcat) and jetty.xml (for Jetty) configuration files. The default user name (jonas) and password (jonas) corresponding to the admin role can be modified here.

Using JonasAdmin

Once started, JonasAdmin can administer the JOnAS server in which it is running, as well as other JOnAS servers with which it shares the same registry. Typically, this is used to administer JOnAS servers running without the WEB container service. Note that the administered JOnAS servers can be running on the same host or on different hosts. Also, if Tomcat is used as the WEB container service implementation, it can be administered using JonasAdmin.

Running JonasAdmin

Ensure that the web service is listed in the jonas.services property in the jonas.properties configuration file. If you are not using a jonas−tomcat or jonas−jetty package, depending on the Servlet container being used, the CATALINA_HOME or the JETTY_HOME environment variable must have been previously set. Note that when running the Servlet container on top of Unix, the DISPLAY environment variable must be set in order to use the JOnAS server monitoring feature of JonasAdmin.

Once JOnAS is launched, JonasAdmin must be loaded if it was not installed in the autoload directory. The administration console is accessible at the URL: http://:/jonasAdmin/ using any web browser.

is the name of the host where the Servlet container is running and is the http port number (default is 9000).

After logging in, the left−hand frame in the Welcome page displays the management tree associated with the JOnAS server running the administration application (the following example assumes that its name is jonas). If other servers are running that share the same registry with jonas, the selector in the upper frame can be used to select the server to administer.

Click on the Server JOnAS node to display the following page:

JonasAdmin 208 Administration Guide

The management tree in this figure allows access to the following main management facilities:

• General information concerning the administered server • Server monitoring • Logging management • Communication protocols management • Active services presentation and configuration • Dynamic deployment of application modules • Resources management • Security management

The console also allows browsing of MBeans registered in the MBean server that are associated with the currently

JonasAdmin 209 Administration Guide

managed JOnAS server.

Server management

Displays general information about the administered JOnAS server, including the JMX server and the WEB server, and provides the capability of listing the content of the Registry.

Server monitoring

Presents memory usage, a count of the threads created by JOnAS, and other monitoring information concerning managed services and resources.

Logging management

Allows the administrator to configure the JOnAS Logging system. Additionally, if Tomcat is used as the WEB container service implementation, it allows creation of HTTP access loggers.

Communication protocols management

This management facility relates to the integration of Tomcat management in JonasAdmin. It currently presents connectors defined in the Tomcat configuration and allows for the creation of new HTTP, HTTPS, or AJP connectors. Note that the Protocols sub−tree is not presented if Jetty is used as the WEB container service implementation.

Active services presentation and configuration

All the active services have a corresponding sub−tree in the Services tree.

Managing the various container services consists of presenting information about the components deployed in these containers. New components can be deployed using the dynamic deployment facilities presented in the next section. However, it may be necessary to create a new context for WEB components (WAR package) to be deployed in a Tomcat server before the deployment step, if a customized context is required by the component. This operation is performed using the New web application button.

Similarly, the services that allow management of the different types of resources (DataSources, Resource Adapters, Jms and Mail resources) also provide information about the resources being deployed. Additionally, deployed resources (DataSources or MailFactories) can be reconfigured and their new configuration made persistent by using a Save button.

The transaction service management allows reconfiguration (possibly persistent) and presents monitoring information about transactions managed by JOnAS.

JonasAdmin 210 Administration Guide

Dynamic deployment with JonasAdmin

A very useful management operation is the capability of loading stand−alone J2EE components (JAR, WAR, RAR packages) or J2EE applications (EAR packages) using the Deployments sub−tree in the JonasAdmin console. The administrator's task is facilitated by the display of the list of deployable modules, the list of deployed modules, and the capability of transferring modules from one list to another. The deployable modules are those installed in directories specific to their type. For example, the deployable JARs are un−deployed JARs installed in JONAS_BASE/ejbjars/ or in a JONAS_BASE/ejbjars/autoload/ directory.

Resources management

The Resources sub−tree provides the capability of loading or creating new resources managed by the active services. For example, if the JMS service is running, the JMS sub−tree in Resources presents the existing JMS destinations (Topics and Queues), and allows the removal of unused destinations and the creation of new JMS destinations. Adding or removing resources implies reconfiguration of the corresponding service. If this new configuration is saved using the Save button, the JOnAS configuration file is updated. As in the JMS service example, the removed topics are deleted from the list assigned to the jonas.service.jms.topics property and the newly created topics are added to this list.

Security management

The Security sub−tree presents existing security realms and allows the creation of new realms of different types: memory, datasource, and ldap realms.

Note concerning persistent reconfiguration facilities

It is important to note that JOnAS and Tomcat have different approaches to reconfiguration persistency. In JOnAS, every Save operation is related to a service or a resource reconfiguration. For example, the administrator can reconfigure a service and a resource, but choose to save only the new resource configuration. In Tomcat, the Save operation is global to all configuration changes that have been performed. For example, if a new HTTP connector is reconfigured and a new context created for a web application, both configuration changes are saved when using the Save button.

Management EJB Component

The MEJB component exposes the managed objects within the JOnAS platform as JMX manageable resources. It is packed in an ejb−jar file installed in the $JONAS_ROOT/ejbjars/autoload directory, and therefor it is loaded at server start−up.

The MEJB component is registered under the name java:comp/env/ejb/MEJB.

The current implementation allows access only to the manageable resources within the current server (the server containing the MEJB's container).

JonasAdmin 211 Administration Guide

The JOnAS distribution was enriched with a new example called j2eemanagement, which shows how the MEJB can be used. You can find details about this management application in $JONAS_ROOT/j2eemanagement/README file.

JonasAdmin 212 JOnAS Commands Reference Guide

Commands provided with JOnAS are described in this chapter. jonas JOnAS manager jclient Starting a JOnASclient newbean Bean generator registry Java Remote Object Registry GenIC Container classes generator JmsServer JMS Server RAConfig Resource Adapter configuration tool newjb Build a new JONAS_BASE for the conformance tests newjc Build a cluster configuration jonas

Synopsis

jonas start [−fg | −bg | −win] [−n name] start a JOnAS server jonas stop [−n name] stop a JOnAS server jonas admin [−n name] [admin_options] administrate a JOnAS server jonas check check JOnAS environment jonas version print JOnAS version

Description

This command replaces the deprecated commands EJBServer, JonasAdmin, and CheckEnv. It provides the capability to start, stop, or administrate JOnAS servers.

JOnAS Commands Reference Guide 213 JOnAS Commands Reference Guide

The outcome of this program may depend on the directory from which the command is run (existence of a jonas.properties file in the current directory). It is possible to set system properties to the program by using the JAVA_OPTS environment variable, if required. Note that setting system properties with a −D option will always take precedence over the properties described in the other jonas.properties files.

The following two scripts can be reviewed and possibly modified for assistance with problems or for obtaining additional information:

jonas for UNIX systems jonas.bat for WINDOWS systems There are five different sub−commands, that depend on the first mandatory argument: jonas start Start a new JOnAS server. The process can be run in the foreground, in the background, or in a new window. If the background option is chosen (default option), control is given back to the caller only when the server is ready. The default name is jonas. A different name can be given with the −n option. jonas stop Stop a running JOnAS server. Use the −n option if the server was given a name other than the default name. jonas admin Administrate a JOnAS server. Use the −n option if the server was given a name other than the default name. Used without any other option, this command will prompt the user for an administrative command (interactive mode). Each administrative command exists in a non−interactive mode, for use in shell scripts or bat scripts, for example. Refer to the option list for a description of each. Another way to manage JOnAS is to use the graphical tool JonasAdmin. The functionality is essentially the same for JonasAdmin as it is for jonas admin. jonas check Check the environment before running a JOnAS server. jonas version Print the current version of JOnAS.

Options

Each option may be pertinent only for a subset of the five different sub−commands. For example, jonas check and jonas version do not accept any options.

−n name Give a name to the JOnAS server. The default is jonas. Used for start, stop, or admin. −fg Used for start only. The server is launched in the foreground: Control is given back to the user only at the end of the process. −bg

jonas 214 JOnAS Commands Reference Guide

Used for start only. The server is launched in the background. Control is given back to the user only when the JOnAS server is ready. This is the default mode. −win Used for start only. The server is launched in a new window. −? Used for admin only. Prints a help with all possible options. −a filename Used for admin only. Deploys a new application described by filename inside the JOnAS Server. The application can be one of the following: ⋅ a standard ejb−jar file. This will lead to the creation of a new EJB Container in the JOnAS Server. If the file name has a relative path, this path is relative to where the EJB server has been launched or relative to the $JONAS_ROOT/ejbjars directory for an ejb−jar file. ⋅ a standard .war file containing a WEB Component. If the file name has a relative path, this path is relative to where the EJB server has been launched or relative to the $JONAS_ROOT/webapps directory for a war file. ⋅ a standard .ear file containing a complete J2EE application. If the file name has a relative path, this path is relative to where the EJB server has been launched or relative to the $JONAS_ROOT/apps directory for an ear file. −r filename Used for admin only. Dynamically removes a previous −a filename command. −gc Used for admin only. Runs the garbage collector in the specified JOnAS server. −passivate Used for admin only. Passivates all entity bean instances. This affects only instances outside transaction. −e Used for admin only. Lists the properties of the specified JOnAS server. −j Used for admin only. Lists the registered JNDI names, as seen by the specified JOnAS server. −l Used for admin only. Lists the beans currently loaded by the specified JOnAS server. −sync Used for admin only. Synchronizes the entity bean instances on the current JOnAS server. Note that this affects only the instances that are not involved in a transaction. −debug topic Used for admin only. Sets the topic level to DEBUG. −tt timeout Used for admin only. Changes the default timeout for transactions. timeout is in seconds. Each jonas admin option has its equivalent in the interactive mode. To enter interactive mode and access the following list of subcommands, type jonas admin [−n name] without any other argument. To exit from interactive mode, use the exit command.

on−line matching interactive command command

jonas 215 JOnAS Commands Reference Guide

addbeans −a fileName env −e gc −gc help −? jndinames −j listbeans −l removebeans −r fileName sync −sync trace −debug topic ttimeout −tt timeout quit exit interactive mode

Examples

jonas check jonas start −n jonas1 jonas admin −n jonas1 −a bean1.jar jonas stop −n jonas1 jclient

Synopsis

jclient [options] java−class [args]

Description

The jclient command allows the user to easily start a "heavy" java client that will be able to reach beans in remote JOnAS servers and start distributed transactions.

It is not the J2EE compliant way to run a java client which is to use to package the java client in a J2EE container client (refer to Client Packaging). The jclient command may be deprecated in a future release.

Options

−cp classpath Add an additional classpath before running the java program. −security

jonas 216 JOnAS Commands Reference Guide

Set a security manager using the policy file in $JONAS_BASE/conf/java.policy. (Used for automatic stubs downloading)

Examples

jclient package.javaclassname args newbean

Synopsis

newbean

Description

The newbean tool helps the bean writer start developing a bean by generating skeletons for all the necessary files for making a bean. Note that this tool only creates templates of the files. These templates must then be customized and the business logic written. However, the files should be compilable.

To create these templates, type newbean and enter a set of parameters in interactive mode.

The Bean Name must start with a capital letter. Avoid the reserved names: Home, EJB, Session, Entity. This name will be used as a prefix for all filenames relative to the bean.

The Bean Type must be one of the following:

♦ S Session bean ♦ E Entity bean ♦ MD Message−Driven bean The Session Type must be one of the following:

♦ L Stateless Session Bean ♦ F Stateful Session Bean The Persistence manager must be one of the following:

♦ C2 Container−Managed Persistence (CMP 2.x) ♦ C Container−Managed Persistence (CMP 1.x) ♦ B Bean−Managed Persistence (BMP) The Bean Location must be one of the following:

♦ R Remote Interfaces ♦ L Local Interfaces

jclient 217 JOnAS Commands Reference Guide

The Package Name is a dot−separated string representing the package to which the bean belongs. Usually this is the same as the current directory.

The Jar Name argument is the name that will be used to build the .jar file. Do not provide the .jar extension with this argument. Typically, the last part of the package name is used.

The Primary Key class is the class representing the primary key. Only needed for entity beans. Possible values are:

♦ S java.lang.String ♦ I java.lang.Integer ♦ O Object (Will be chosen later)

Example

newbean Bean Name > MyEntity

Bean type S Session bean E Entity bean MD Message−Driven bean > E

Persistance manager C Container B Bean > C

Bean location R Remote L Local > R

Package name > truc.machin

Jar name > machin

Primary Key class 0 S String I Integer O Object > S

Creating bean MyEntity (type ECR) in package truc.machin Your bean files have been created. You can now customize them.

newbean 218 JOnAS Commands Reference Guide

registry

Synopsis

registry [ ]

Description

The registry tool creates and starts a remote object registry on the specified port of the current host, based on the ORB type defined in the JOnAS configuration (RMI or Jeremie).

If the port is omitted, the registry is started on port 1099 on RMI, or on port 1234 on Jeremie.

Note that, by default, the registry is collocated in the same JVM as the JOnAS Server. In this case, it is not necessary to use this tool; the registry is automatically launched.

Options

port

Port number.

Example

The registry command can normally be run in the background:

♦ registry & on Unix, or ♦ start registry.bat on Windows

GenIC

Synopsis

GenIC [ Options ]

Description

The GenIC utility generates the container classes for JOnAS from the given Enterprise Java Beans.

The InputFileName is either the file name of an ejb−jar file or the file name of an XML deployment descriptor of beans.

The GenIC utility does the following in the order listed:

registry 219 JOnAS Commands Reference Guide

1) generates the sources of the container classes for all the beans defined in the deployment descriptor, 2) compiles these classes via the java compiler, 3) generates stubs and skeletons for those remote objects via the rmi compiler, and 4) if the InputFile is an ejb−jar file, adds the generated classes in this ejb−jar file.

Options

−d directory

Specifies the root directory of the class hierarchy. This option can be used to specify a destination directory for the generated files. If the −d option is not used, the package hierarchy of the target class is ignored and the generated files are placed in the current directory. If the InputFile is an ejb−jar file, the generated classes are added to the ejb−jar file, unless the −noaddinjar option is set. −invokecmd Invokes directly, in some cases, the method of the java class corresponding to the command. This is useful on Windows in the event of a CreateProcess Exception (this occurs when the command line is too long). −javac options Specifies the java compiler name to use (javac by default). −javacopts options Specifies the options to pass to the java compiler. −keepgenerated Do not immediately delete generated files. −noaddinjar If the InputFile is an ejb−jar file, do not add the generated classes to the ejb−jar file. −nocompil Do not compile the generated source files via the java and rmi compilers. −novalidation Remove xml validation during parsing. −protocols Comma−separated list of protocols (chosen within jeremie, jrmp, iiop, cmi) for which stubs should be generated. Default is jrmp,jeremie. −rmiopts options Specifies the options to pass to the rmi compiler. −verbose Displays additional information about command execution. −nofastrmic Disable the use of fastrmic for stubs/ties generation.

GenIC 220 JOnAS Commands Reference Guide

Example

GenIC −d ../../classes sb.xml generates container classes of all the Enterprise JavaBeans defined in the sb.xml file. Classes are generated in the ../../classes directory adhering to the classes hierarchy.

GenIC sb.jar generates container classes for all the Enterprise JavaBeans defined in the sb.jar file and adds the generated classes to this ejb−jar file.

Environment

If InputFile is an XML deployment descriptor, the classpath must include the paths of the directories in which the Enterprise Bean's classes can be found, as well as the path of the directory specified by the −d option.

If InputFile is an ejb−jar file, the classpath must include the path of the directory specified by the −d option.

JmsServer

Synopsis

JmsServer

Description

Launches the Joram Server (ie the MOM) with its default options.

Options

none

Example

The JmsServer command is typically run in the background:

♦ JmsServer & on Unix, or ♦ start JmsServer on Windows.

GenIC 221 JOnAS Commands Reference Guide

RAConfig

Synopsis

RAConfig [ Options ] []

Description

The RAConfig utility generates a JOnAS−specific resource adapter configuration file (jonas−ra.xml) from an ra.xml file (Resource adapter deployment descriptor).

The InputFileName is the file name of a the resource adapter.

The OutputFileName is the file name of an output resource adapter used with the −p(required) or −u(optional).

Options: Only capital letters or the full option name must be specified

−? or −HELP options

Gives a summary of the options. −DM,−DS,−PC,−XA DriverManager, DataSource, PooledConnection, XAConnection Specifies the rarlink value to configure, used with the −p option. −ENcrypt Used with −SecurityFile to encrypt the specified passwords. −Jndiname jndiname It is a mandatory option with a 1.0 Resource Adapter. It specifies the JNDI name of the connection factory. This name corresponds to the name of the element of the element in the JOnAS−specific deployment descriptor. This name is used by the resource service for registering in JNDI the connection factory corresponding to this resource adapter. −NoValidation Turn off the xml dtd/schema validation. −PATH output directory for the generated jonas−ra.xml Specifies the directory name to place the generated jonas−ra.xml file. The default value when not specified is the System attribute of java.io.tmpdir. −Property database properties file Specifies the name of the database.properties file to process. The result of this processing will be a jonas−ra.xml file that will update the /META−INF/jonas−ra.xml file in the output rar. −Rarlink rarlink Specifies the jndi name of an rar file with which to link. This option can be used when this rar file will inherit all attributes associated with the specified jndi name. If this option is specified in the jonas−ra.xml file, it is the only file needed in the rar, and the ra.xml file will be

RAConfig 222 JOnAS Commands Reference Guide

processed from the rarlink file. −SecurityFile security property file to process Specifies the security property file to process and add security information to jonas−ra.xml. This will map the specified principal name to the user on the EIS system. The specified file must be in the following form: principal = user::password . When used in conjunction with the −ENcrypt option, then the resulting information will be encrypted in jonas−ra.xml. −Update inputname Specifies the name of the XML file to process. This file will update the /META−INF/jonas−ra.xml file in the rar. If this argument is used, it is the only argument executed. −Verbose Verbose mode. Displays the deployment descriptor of the resource adapter on standard System.out.

Example

• RAConfig −j adapt_1 MyRA.rar Generates the jonas−ra.xml file from the ra.xml file.

After the jonas−ra.xml has been configured for the MyRA rar file RAConfig −u jonas−ra.xml MyRA.rar Updates/inserts the jonas−ra.xml file into the rar file. • RAConfig −dm −p MySQL1 $JONAS_ROOT/rars/autoload/JOnAS_jdbcDM MySQL_dm

Generates the jonas−ra.xml file from the ra.xml file of the JOnAS_jdbcDM.rar and inserts the corresponding values from the MySQL1.properties file. The jonas−ra.xml file is then added/updated to the MySQL_dm.rar file. This rar file can then be deployed and will replace the configured MySQL1 datasource. newjb

Synopsis

newjb;

Description

The newjb utility builds a new JONAS_BASE directory that allows the conformance tests to be launched. At the start, the user must choose:

− the protocol among jrmp,jeremie,iiop,cmi − the database

RAConfig 223 JOnAS Commands Reference Guide

− the web container among tomcat, jetty and the tool generates the configuration automatically.

The $JONAS_BASE variable must be set before launching the tool; it specifies the path to the new directory that will be built.

The $HOME/jb.config/lib directory must be created before launching the tool. It can contain some specific user configuration (see below).

The tool relies on JOnAS's ant tasks and thus builds a configuration compatible with the JOnAS version. Firstly, a JONAS_BASE with default values is built, and then the configuration files are modified with the values defined in the centralized configuration file of newjb (see below).

A default configuration file is provided in $JONAS_ROOT/build−jc.properties. It contains the variable parameters used by the tool, such as port number and database properties.

A user configuration can be set in the $HOME/jb.config/conf/jonas−newjb.properties file. If this file is present, the parameters it contains will override the default parameters.

By default, only the HSQL database can be configured with this tool. For other databases, the specific drivers must be stored in the $HOME/jb.config/lib directory before the run and the properties must be set in the $HOME/jb.config/conf/jonas−newjb.properties file. newjc

Synopsis

cd $JONAS_ROOT/examples/sampleCluster2/newjc newjc.sh;

Description

The newjc utility builds a new cluster configuration. Here a cluster configuration is a set of new JONAS_BASE directories and the mod_jk/director configuration files. At the start, the user must choose:

− the output directory. The default value is the $JONAS_BASE value. This is the directory where all the JONAS_BASE directories of the cluster configuration and the mod_jk/director configuration will be created. − the prefix for the JONAS_BASE directories. By default jb is suggested and in this case, the JONAS_BASE will be 'jb1', 'jb2', and so on. − the protocol between jrmp,jeremie,iiop,cmi − the database − the web container

newjc 224 JOnAS Commands Reference Guide

− the cluster architecture between bothWebEjb and diffWebEjb. The first describes a cluster where all the nodes contain the same services, whereas the second one describes an architecture where the web level and the ejb level are separated. − the number of web instances to create. − the number of ejb instances to create. If there is not a separation between the web and ejb levels, the total number of instances is the sum of the web instances and the ejb instances. Once this is done, the tool generates the configuration automatically.

The $HOME/jc.config/lib directory must be created before launching the tool. It can contain some specific user configuration (see below).

The tool relies on JOnAS's ant tasks and thus builds a configuration compatible with the JOnAS version. Firstly, the JONAS_BASE directories with default values are built, and then the configuration files are modified with the values defined in the centralized configuration file of newjc (see below).

A default configuration file is provided in $JONAS_ROOT/examples/sampleCluster2/newjc/build−jc.properties. It contains the variable parameters used by the tool, such as port number range and database properties.

An user configuration can be set in the $HOME/jc.config/conf/jonas−newjc.properties file. If this file is present, the parameters it contains override the default parameters.

By default, only the HSQL database can be configured with this tool. For other databases, the specific drivers must be stored in the $HOME/jc.config/lib directory before the run and the properties must be set in the $HOME/jc.config/conf/jonas−newjb.properties file.

By default, the load−balancing at the web level is implemented through the Apache mod_jk plugin. The Enhydra−director plugin can be also used by modifying the configuration file ($HOME/jc.config/conf/jonas−newjb.properties) and by storing the tomcat5.5−director.jar (http://director.objectweb.org/) file in the $HOME/jc.config/lib directory before the run.

newjc 225 Creating a New JOnAS Service

The content of this guide is the following:

1. Target Audience and Rationale 2. Introducing a new Service 3. Advanced Understanding

Target Audience and Rationale

This chapter is intended for advanced JOnAS users who require that some "external" services run along with the JOnAS server. A service is something that may be initialized, started, and stopped. JOnAS itself already defines a set of services, some of which are cornerstones of the JONAS Server. The JOnAS pre−defined services are listed in Configuring JOnAS services.

J2EE application developers may need to access other services, for example another Web container or a Versant container, for their components. Thus, it is important that such services be able to run along with the application server. To achieve this, it is possible to define them as JOnAS services.

This chapter describes how to define a new JOnAS service and how to specify which service should be started with the JOnAS server.

Introducing a new Service

The customary way to define a new JOnAS service is to encapsulate it in a class whose interface is known by JOnAS. More precisely, such a class provides a way to initialize, start, and stop the service. Then, the jonas.properties file must be modified to make JOnAS aware of this service.

Defining the Service class

A JOnAS service is represented by a class that implements the interface org.objectweb.jonas.service.Service, and, thus should implement the following methods:

• public void init(Context ctx) throws ServiceException; • public void start() throws ServiceException; • public void stop() throws ServiceException; • public boolean isStarted(); • public String getName(); • public void setName(String name);

It should also define a public constructor with no argument.

Creating a New JOnAS Service 226 Creating a New JOnAS Service

These methods will be called by JOnAS for initializing, starting, and stopping the service. Configuration parameters are provided to the initialization method through a naming context. This naming context is built from properties defined in the jonas.properties file as explained in the following section.

The Service class should look like the following: package a.b; import javax.naming.Context; import javax.naming.NamingException; import org.objectweb.jonas.service.Service; import org.objectweb.jonas.service.ServiceException; ..... public class MyService implements Service { private String name = null; private boolean started = false; ..... public void init(Context ctx) throws ServiceException { try { String p1 = (String) ctx.lookup("jonas.service.serv1.p1"); ..... } catch (NamingException e) { throw new ServiceException("....", e); } ..... } public void start() throws ServiceException { ..... this.started = true; } public void stop() throws ServiceException { if (this.started) { this.started = false; ..... } } public boolean isStarted() { return this.started; } public String getName() { return this.name; } public void setName(String name) { this.name = name; } }

Modifying the jonas.properties file

The service is defined and its initialization parameters specified in the jonas.properties file. First, choose a name for the service (e.g. "serv1"), then do the following:

Introducing a new Service 227 Creating a New JOnAS Service

• add this name to the jonas.services property; this property defines the set of services (comma−separated) that will be started with JOnAS, in the order of this list. • add a jonas.service.serv1.class property specifying the service class. • add as many jonas.service.serv1.XXX properties specifying the service initialization parameters, as will be made available to the service class via the Context argument of the init method.

This is illustrated as follows:

jonas.services ...... ,serv1 jonas.service.serv1.class a.b.MyService jonas.service.serv1.p1 value

Using the New Service

The new service has been given a name in jonas.properties. With this name, it is possible to get a reference on the service implementation class by using the ServiceManager method: getService(name). The following is an example of accessing a Service: import org.objectweb.jonas.service.ServiceException; import org.objectweb.jonas.service.ServiceManager;

MyService sv = null;

// Get a reference on MyService. try { sv = (MyService) ServiceManager.getInstance().getService("serv1"); } catch (ServiceException e) { Trace.errln("Cannot find MyService:"+e); }

Adding the class of the new service to JOnAS

Package the class of the service into a .jar file and add the jar in the JONAS_ROOT/lib/ext directory. All the libraries required by the service can also be placed in this directory.

Advanced Understanding

Refer to the JOnAS sources for more details about the classes mentioned in this section.

JOnAS built−in services

The existing JOnAS services are the following:

Service name Service class

Introducing a new Service 228 Creating a New JOnAS Service

registry RegistryServiceImpl ejb EJBServiceImpl web CatalinaJWebContainerServiceImpl / JettyJWebContainerServiceImpl ear EarServiceImpl dbm DataBaseServiceImpl jms JmsServiceImpl jmx JmxServiceImpl jtm TransactionServiceImpl mail MailServiceImpl resource ResourceServiceImpl security JonasSecurityServiceImpl ws AxisWSService

If all of these services are required, they will be launched in the following order: registry, jmx, security, jtm,dbm,mail,jms,resource,ejb, ws, web, ear. jmx, security, dbm, mail, resource are optional when you are using service ejb. registry must be launched first. (Note that for reasons of compatability with previous versions of JOnAS, if registry is unintentionally not set as the first service to launch, JOnAS will automatically launch the registry service.)

Note that dbm, jms, resource, and ejb depend on jtm. Note that ear depends on ejb and web (that provide the ejb and web containers), thus these services must be launched before the ear service. Note that ear and web depends on ws, thus the ws service must be launched before the ear and web service.

It is possible to launch a stand−alone Transaction Manager with only the registry and jtm services.

A jonas.properties file looks like the following:

......

jonas.services registry,jmx,security,jtm,dbm,mail,jms,ejb,resource,serv1

jonas.service.registry.class org.objectweb.jonas.registry.RegistryServiceImpl jonas.service.registry.mode automatic

jonas.service.dbm.class org.objectweb.jonas.dbm.DataBaseServiceImpl jonas.service.dbm.datasources Oracle1

jonas.service.ejb.class org.objectweb.jonas.container.EJBServiceImpl jonas.service.ejb.descriptors ejb−jar.jar jonas.service.ejb.parsingwithvalidation true

Introducing a new Service 229 Creating a New JOnAS Service

jonas.service.ejb.mdbthreadpoolsize 10

jonas.service.web.class org.objectweb.jonas.web.catalina.CatalinaJWebContainerServiceImpl jonas.service.web.descriptors war.war jonas.service.web.parsingwithvalidation true

jonas.service.ear.class org.objectweb.jonas.ear.EarServiceImpl jonas.service.ear.descriptors j2ee−application.ear jonas.service.ear.parsingwithvalidation true

jonas.service.jms.class org.objectweb.jonas.jms.JmsServiceImpl jonas.service.jms.mom org.objectweb.jonas_jms.JmsAdminForJoram jonas.service.jms.collocated true jonas.service.jms.url joram://localhost:16010

jonas.service.jmx.class org.objectweb.jonas.jmx.JmxServiceImpl

jonas.service.jtm.class org.objectweb.jonas.jtm.TransactionServiceImpl jonas.service.jtm.remote false jonas.service.jtm.timeout 60

jonas.service.mail.class org.objectweb.jonas.mail.MailServiceImpl jonas.service.mail.factories MailSession1

jonas.service.security.class org.objectweb.jonas.security.JonasSecurityServiceImpl

jonas.service.resource.class org.objectweb.jonas.resource.ResourceServiceImpl jonas.service.resource.resources MyRA

jonas.service.serv1.class a.b.MyService jonas.service.serv1.p1 John

The ServiceException

The org.objectweb.jonas.service.ServiceException exception is defined for Services. Its type is java.lang.RuntimeException. and it can encapsulate any java.lang.Throwable.

The ServiceManager

The org.objectweb.jonas.service.ServiceManager class is responsible for creating, initializing, and launching the services. It can also return a service from its name and list all the services.

Advanced Understanding 230 JMS User's Guide

1. JMS installation and configuration aspects 2. Writing JMS operations within an application component 3. Some programming rules and restrictions when using JMS within EJB 4. JMS administration 5. Running an EJB performing JMS operations 6. A JMS EJB example

As required by the J2EE v1.4 specification, application components (servlets, JSP pages and enterprise beans) can use JMS for Java messaging. Furthermore, applications can use Message−driven Beans for asynchronous EJB method invocation, as specified by the EJB 2.1 specification.

Starting with the JOnAS 3.1 version, JOnAS supports the Java Message Service Specification 1.1. Previously in JMS 1.0.2, client programming for Point−to−point and Pub/Sub domains was achieved using similar, but separate, class hierarchies. Now, JMS 1.1 offers a domain−independent approach to programming the client application. Thus, the programming model is simpler and it is now possible to engage queues and topics in the same transaction.

Enterprise Bean providers can use JMS Connection Factory resources via resource references, and JMS Destination resources (JMS Queues and JMS Topics) via resource environment references. Thus, they are able to provide JMS code, inside an EJB method or web component method, for sending or synchronously receiving messages to/from a JMS Queue or Topic.

The EJB container and the Web container can allow for JMS operations within a global transaction, which may include other resources such as databases.

JOnAS integrates a third party JMS implementation (JORAM) which is the default JMS service, and for which a J2EE1.4−compliant Resource Adapter archive file is also provided. Other JMS providers, such as SwiftMQ and WebSphere MQ, may easily be integrated.

Starting with release 4.1, a JMS provider can be integrated within JOnAS by deploying a corresponding resource adapter. This is the preferred method as the JMS service will eventually become deprecated in later JOnAS releases. Also, this method allows deployment of 2.1 MDBs (not possible with the JMS service).

For performing JMS operations, JMS−administered objects will be used by the application components, such as connection factories and destinations. Refer to the JMS Administration section for an explanation of how to create those objects.

JMS installation and configuration aspects

To use JMS with JOnAS, no additional installation or configuration operations are required. JOnAS contains:

• the Java[TM] Message Service API 1.1, currently integrated with the JOnAS distribution,

JMS User's Guide 231 JMS User's Guide

• a JMS implementation. Currently, the OpenSource JORAM (http://joram.objectweb.org), is integrated with the JOnAS distribution, thus no installation is necessary.

Additionally, the SwiftMQ product and IBM's WebSphere MQ have been used with JOnAS.

Writing JMS operations within an application component

To send (or synchronously receive) JMS messages, the component requires access to JMS−administered objects, i.e. Connection Factories for creating connections to JMS resources and Destination objects (Queue or Topic), which are the JMS entities used as destinations within JMS sending operations. Both are made available through JNDI by the JMS provider administration facility.

Refer to the JOnAS example jms as a supplement to this present reading. This example jms is described here.

Accessing the Connection Factory

The EJB specification introduces the concept of Resource Manager Connection Factory References. This concept also appears in the J2EE v1.4 specification. It is used to create connections to a resource manager. To date, three types of Resource Manager Connection Factories are considered:

• DataSource objects (javax.sql.DataSource) represent connection factories for JDBC connection objects. • JMS Connection factories (javax.jms.ConnectionFactory, javax.jms.QueueConnectionFactory and javax.jms.TopicConnectionFactory) are connection factories for JMS connection objects. • Java Mail Connection factories (javax.mail.Session or javax.mail.internet.MimePartDataSource) are connection factories for Java Mail connection objects.

The connection factories of interest here are the second type, which should be used to get JMS Connection Factories.

Note that starting with JMS 1.1, it is recommended that only the javax.jms.ConnectionFactory be used (rather than javax.jms.QueueConnectionFactory or javax.jms.TopicConnectionFactory ). However, the new implementation is fully backwards compatible and existing applications will work as is.

The standard deployment descriptor should contain the following resource−ref element:

jms/conFact javax.jms.ConnectionFactory Container

This means that the programmer will have access to a ConnectionFactory object using the JNDI name java:comp/env/jms/conFact. The source code for obtaining the factory object is the following:

Writing JMS operations within an application component 232 JMS User's Guide

ConnectionFactory qcf = (ConnectionFactory) ctx.lookup("java:comp/env/jms/conFact");

The mapping to the actual JNDI name of the connection factory (as assigned by the JMS provider administration tool), CF in the example, is defined in the JOnAS−specific deployment descriptor with the following element:

jms/conFact CF

Accessing the Destination Object

Accessing a JMS destination within the code of an application component requires using a Resource Environment Reference, which is represented in the standard deployment descriptor as follows:

jms/stockQueue javax.jms.Queue

The application component's source code should contain:

Queue q = (Queue) ctx.lookup("java:comp/env/jms/stockQueue"); the mapping to the actual JNDI name (e.g. "myQueue") being defined in the JOnAS−specific deployment descriptor in the following way:

jms/stockQueue myQueue

Writing JMS Operations

A typical method performing a message sending JMS operations looks like the following:

void sendMyMessage() {

ConnectionFactory cf = (ConnectionFactory) ctx.lookup("java:comp/env/jms/conFact"); Queue queue = (Queue) ctx.lookup("java:comp/env/jms/stockQueue"); Connection conn = cf.createConnection(); Session sess = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);

MessageProducer mp = sess.createProducer((Destination)queue); ObjectMessage msg = sess.createObjectMessage();

Writing JMS operations within an application component 233 JMS User's Guide

msg.setObject("Hello"); sender.send(msg); sess.close(); conn.close(); }

It is also possible for an application component to synchronously receive a message. An EJB method performing synchronous message reception on a queue is illustrated in the following:

public String recMsg() { ConnectionFactory cf = (ConnectionFactory) ctx.lookup("java:comp/env/jms/conFact"); Queue queue = (Queue) ctx.lookup("java:comp/env/jms/stockQueue"); Connection conn = cf.createConnection(); Session sess = conn.createSession(true, Session.AUTO_ACKNOWLEDGE); MessageConsumer mc = sess.createConsumer((Destination)queue); conn.start(); ObjectMessage msg = (ObjectMessage) mc.receive(); String msgtxt = (String) msg.getObject(); sess.close(); conn.close(); return msgtxt; }

A method that performs JMS operations should always contain the session create and close statements, as follows:

public void doSomethingWithJMS (...) { ... session = connection.createSession(...); ... // JMS operations session.close(); }

The contained JMS operations will be a part of the transaction, if there is one, when the JOnAS server executes the method.

Be sure to never send and receive a particular message in the same transaction, since the JMS sending operations are actually performed at commit time only.

The previous examples illustrate point−to−point messaging. However, application components can also be developed using the publish/subscribe JMS API, i.e. using the Topic instead of the Queue destination type. This offers the capability of broadcasting a message to several message consumers at the same time. The following example illustrates a typical method for publishing a message on a JMS topic and demonstrates how interfaces have been simplified since JMS 1.1.

public void sendMsg(java.lang.String s) { ConnectionFactory cf = (ConnectionFactory) ictx.lookup("java:comp/env/jms/conFactSender"); Topic topic = (Topic) ictx.lookup("java:comp/env/jms/topiclistener"); Connection conn = cf.createConnection();

Writing JMS operations within an application component 234 JMS User's Guide

Session session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE); MessageConsumer mc = session.createConsumer((Destination)topic); ObjectMessage message = session.createObjectMessage(); message.setObject(s); mc.send(message); session.close(); conn.close(); }

Transactions and JMS sessions within an application component

JMS session creation within an application component will result in different behaviors, depending on whether the session is created at execution time within or outside a transaction. In fact, the parameters of the createSession(boolean transacted, int acknowledgeMode) method are never taken into account.

• If the session creation occurs outside a transaction, the parameters is considered as being transacted = false and acknowledgeMode = AUTO_ACKNOWLEDGE. This means that each operation of the session is immediately executed. • If the session creation occurs inside a transaction, the parameters have no meaning, the session may be considered as transacted, and the commit and rollback operations are handled by the JOnAS server at the level of the associated XA resource.

Authentication

If your JMS implementation performs user authentication, the following methods can be used on Connection Factories:

• createConnection(String userName, String password) on ConnectionFactory • createQueueConnection(String userName, String password) on QueueConnectionFactory • createTopicConnection(String userName, String password) on TopicConnectionFactory

Some programming rules and restrictions when using JMS within EJB

This section presents some programming restrictions and rules for using JMS operations within entity components.

Connection Management

Depending on the JMS implementation and the application, it may be desirable to keep the JMS connections open for the life of the bean instance or for the duration of the method call. These two programming modes are illustrated in the following example (this example illustrates a stateful session bean):

Writing JMS operations within an application component 235 JMS User's Guide

public class EjbCompBean implements SessionBean { ... QueueConnectionFactory qcf = null; Queue queue = null;

public void ejbCreate() { .... ictx = new InitialContext(); qcf = (QueueConnectionFactory) ictx.lookup("java:comp/env/jms/conFactSender"); queue = (Queue) ictx.lookup("java:comp/env/jms/queue1"); }

public void doSomethingWithJMS (...) { ... Connection conn = qcf.createConnection(); Session session = conn.createSession(...); ... // JMS operations session.close(); conn.close(); }

... }

To keep the connection open during the life of a bean instance, the programming style shown in the following example is preferred, since it avoids many connection opening and closing operations: public class EjbCompBean implements SessionBean { ... ConnectionFactory qcf = null; Queue queue = null; Connection conn = null;

public void ejbCreate() { .... ictx = new InitialContext(); cf = (ConnectionFactory) ictx.lookup("java:comp/env/jms/conFactSender"); queue = (Queue) ictx.lookup("queue1"); conn = cf.createConnection(); }

public void doSomethingWithJMS (...) { ... Session session = conn.createSession(...); ... // JMS operations session.close(); }

public void ejbRemove() { conn.close(); }

Writing JMS operations within an application component 236 JMS User's Guide

... }

Be aware that maintaining JMS objects in the bean state is not always possible, depending on the type of bean.

• For a stateless session bean, the bean state is not maintained across method calls. Therefore, the JMS objects should always be initialized and defined in each method that performs JMS operations. • For an entity bean, an instance may be passivated, and only the persistent part of the bean state is maintained. Therefore, it is recommended that the JMS objects be initialized and defined in each method performing JMS operations. If these objects are defined in the bean state, they can be initialized in the ejbActivate method (if the connection is created in the ejbActivate method, be sure to close it in the ejbPassivate method). • For a stateful session bean (as shown in the previous example), JMS objects can be defined in the bean state. Stateful session bean instances can be passivated (not in the current version of JOnAS). Since connection factories and destinations are serializable objects, they can be initialized only in ejbCreate. However, be aware that a connection must be closed in ejbPassivate (with the state variable set to null) and recreated in ejbActivate.

Note that, due to a known problem with the Sun JDK 1.3 on Linux, the close of the connection can block. The problem is fixed with JDK 1.4.

Starting Transactions after JMS Connection or Session creation

Currently, it is not possible to start a bean−managed transaction after the creation of a JMS session and have the JMS operations involved in the transaction. In the following code example, the JMS operations will not occur within the ut transaction: public class EjbCompBean implements SessionBean { ...

public void doSomethingWithJMS (...) { ... Connection conn = cf.createConnection(); Session session = conn.createSession(...); ut = ejbContext.getUserTransaction(); ut.begin(); ... // JMS operations ut.commit(); session.close(); conn.close(); }

... }

To have the session operations involved in the transaction, the session creation and close should be inside the transaction boundaries, and the connection creation and close operations can either be both outside the transaction

Some programming rules and restrictions when using JMS withinEJB 237 JMS User's Guide

boundaries or both inside the transaction boundaries, as follows: public class EjbCompBean implements SessionBean { ...

public void doSomethingWithJMS (...) { ... Connection conn = qcf.createConnection(); ut = ejbContext.getUserTransaction(); ut.begin(); Session session = conn.createSession(...); ... // JMS operations session.close(); ut.commit(); conn.close(); }

... } or public class EjbCompBean implements SessionBean { ...

public void doSomethingWithJMS (...) { ... ut = ejbContext.getUserTransaction(); ut.begin(); Connection conn = cf.createConnection(); Session session = conn.createSession(...); ... // JMS operations session.close(); conn.close(); ut.commit(); }

... }

Programming EJB components with bean−managed transactions can result in complex code. Using container−managed transactions can help avoid problems such as those previously described.

JMS administration

Applications using messaging require some JMS−administered objects: connection factories and destinations. These objects are created via the proprietary administration interface (not standardized) of the JMS provider. For simple cases, it is possible to have either the jms service or the JMS resource adapter perform administration operations during startup.

JMS administration 238 JMS User's Guide

As provided, the default JMS service and JORAM adapter configurations automatically create six connection factories and two destination objects.

The six connection factories automatically created are described in the following table:

JNDI JMS type Usage name CF ConnectionFactory To be used by an application component to create a Connection. QCF QueueConnectionFactory To be used by an application component to create a QueueConnection. TCF TopicConnectionFactory To be used by an application component to create a TopicConnection. To be used by any other Java component (for instance a client) to create a JCF ConnectionFactory Connection. To be used by any other Java component (for instance a client) to create a JQCF QueueConnectionFactory QueueConnection. To be used by any other Java component (for instance a client) to create a JTCF TopicConnectionFactory TopicConnection.

The CF, QCF and TCF connection factories are managed connection factories. The application components should use only managed connection factories to allow JOnAS to manage the JMS resources created via these connection factories (the JMS sessions). In contrast, JCF, JQCF and JTCF are non−managed connection factories. They are used by Java components implementing a JMS client behavior, but running outside the application server.

The two destinations automatically created are described in the following table:

JNDI name JMS type Usage sampleQueue Queue Can be equally used by an EJB component or a Java component. sampleTopic Topic Can be equally used by an EJB component or a Java component.

JMS service administration

For using the JMS service in the default configuration, it is only necessary to require the use of the JMS service in the jonas.properties file:

jonas.services security,jtm,dbm,jms,ejb

JOnAS will not create additional connection factories when using the default configuration. However, JOnAS can create requested destination objects at server launching time, if specified in the jonas.properties file. To do this, specify the JNDI names of the Topic and Queue destination objects to be created in a jonas.service.jms.topics and jonas.service.jms.queues property respectively, as follows:

JMS administration 239 JMS User's Guide

jonas.service.jms.topics t1,t2 // JOnAS server creates 2 topic destinations (t1,t2) jonas.service.jms.queues myQueue // JOnAS server creates 1 queue destination (myQueue)

It is recommended that programmers use resource references and resource environment references to access the connection factories and destination objects created by JOnAS, as already presented in the "Writing JMS operations within an application component" section.

JMS resource adapter configuration

Starting with JOnAS release 4.1, it is recommended that a JMS resource adapter be deployed instead of using the jms service. Refer to the JMS Resource Adapters configuration guide for an explanation.

Running an EJB performing JMS operations

All that is necessary to have an Enterprise Bean perform JMS operations is: jonas start

The Message−Oriented Middleware (the JMS provider implementation) is automatically started (or at least accessed) and the JMS−administered objects that will be used by the Enterprise Beans are automatically created and registered in JNDI.

Then, the EJB can be deployed as usual with: jonas admin −a XX.jar

Accessing the Message−Oriented Middleware... as a service...

If the JOnAS property jonas.services contains the jms service, the JOnAS JMS service will be launched and will eventually try to launch a JMS implementation (e.g. the JORAM MOM or the SwiftMQ MOM).

For launching the MOM, consider the following possibilities:

1. Launching the MOM automatically in the JOnAS JVM This is done using the default values for the configuration options, i.e. keeping the JOnAS property jonas.service.jms.collocated value true in the jonas.properties file (see the jonas.properties file provided in $JONAS_ROOT/conf directory).

jonas.service.jms.collocated true

In this case, the MOM will be launched automatically at server launching time (command jonas start).

JMS administration 240 JMS User's Guide

Note for using the JORAM MOM from a distant host:

♦ To use the JMS resources from a distant host, the hostname property value in the default a3servers.xml configuration file must be changed from localhost to the actual host name. See case 4 (Launching the MOM on another port number) for details on the JORAM configuration.

2. Launching the MOM in a separate JVM on the same host The JORAM MOM can be launched with its default options using the command: JmsServer

For other MOMs, use the proprietary command.

In this case, the JOnAS property jonas.service.jms.collocated must be set to false in the jonas.properties file.

jonas.service.jms.collocated false 3. Launching the MOM on another host The MOM can be launched on a separate host. In this case, the JOnAS server must be notified that the MOM is running on another host via the JOnAS property jonas.service.jms.url in the jonas.properties file. For JORAM, its value should be the JORAM URL joram://host:port where host is the host name, and port the default JORAM port number, i.e. 16010 (For SwiftMQ, the value of the URL is similar to smqp://host:4001/timeout=10000).

jonas.service.jms.collocated false jonas.service.jms.url joram://host2:16010 4. Launching the MOM on another port number (for JORAM) To change the default JORAM port number requires a JORAM−specific configuration operation (modifying the a3servers.xml configuration file located in the directory where JORAM is explicitly launched). A default a3servers.xml file is provided in the $JONAS_ROOT/conf directory; this a3servers.xml file specifies that the MOM runs on the localhost using the JORAM default port number. To launch the MOM on another port number, change the args attribute of the service class="fr.dyade.aaa.mom.ConnectionFactory" element in the a3servers.xml file and update the jonas.service.jms.url property in the jonas.properties file.

The default a3servers.xml file is located in $JONAS_ROOT/conf. To change the location of this file, the system property −Dfr.dyade.aaa.agent.A3CONF_DIR="your directory for a3.xml" must be passed.

5. Specifying JORAM's persistence mode When automatically starting JORAM, or when starting JORAM with the JmsServer command, the default mode is non−persistent. Meaning that in the event of a crash, the non−delivered and non−acknowledged messages are lost.

Running an EJB performing JMS operations 241 JMS User's Guide

In order to start a persistent JORAM server, guaranteeing message delivery even in case of failures, the Transaction system property should be set to fr.dyade.aaa.util.ATransaction.

Note: the MOM may be directly launched by the proprietary command. The command for JORAM is: java −DTransaction=fr.dyade.aaa.util.NullTransaction fr.dyade.aaa.agent.AgentServer 0 ./s0

This command corresponds to the default options used by the JmsServer command.

The server is not persistent when launched with this command. If persistence is required, the −DTransaction=fr.dyade.aaa.util.NullTransaction option should be replaced with the −DTransaction=fr.dyade.aaa.util.ATransaction option.

To change other MOM configurations (distribution, multi−servers, ...), refer to the JORAM documentation on http://joram.objectweb.org.

... or as a J2EE1.4 adapter

Starting with JOnAS release 4.1, a JMS server can be accessed through a resource adapter which may be deployed.

For deploying such a resource adapter, place the corresponding archive file (*.rar) in the JOnAS's rars/autoload directory, or declare it at the end of the jonas.properties file, or deploy it manually through the jonasAdmin tool.

Configuring and deploying such adapters is explained in the Configuring JMS Resource Adapters section.

A JMS EJB example

This example shows an EJB application that combines an Enterprise Bean sending a JMS message and an Enterprise Bean writing a Database (an Entity Bean) within the same global transaction. It is composed of the following elements:

• A Session Bean, EjbComp, with a method for sending a message to a JMS topic. • An Entity Bean, Account (the one used in the sample eb with container−managed persistence), which writes its data into a relational database table and is intended to represent a sent message (i.e. each time the EjbComp bean sends a message, an entity bean instance will be created). • An EJB client, EjbCompClient, which calls the sendMsg method of the EjbComp bean and creates an Account entity bean, both within the same transaction. For a transaction commit, the JMS message is actually sent and the record corresponding to the entity bean in the database is created. For a rollback, the message is not sent and nothing is created in the database. • A pure JMS client MsgReceptor, outside the JOnAS server, the role of which is to receive the messages sent by the Enterprise Bean on the topic.

Running an EJB performing JMS operations 242 JMS User's Guide

The Session Bean performing JMS operations

The bean should contain code for initializing the references to JMS administered objects that it will use. To avoid repeating this code in each method performing JMS operations, it can be introduced in the ejbCreate method. public class EjbCompBean implements SessionBean { ... ConnectionFactory cf = null; Topic topic = null;

public void ejbCreate() { .... ictx = new InitialContext(); cf = (ConnectionFactory) ictx.lookup("java:comp/env/jms/conFactSender"); topic = (Topic) ictx.lookup("java:comp/env/jms/topiclistener"); } ... }

This code has been intentionally cleared from all the elements in which it is not necessary for understanding the JMS logic aspects of the example, e.g. exception management.

The JMS−administered objects ConnectionFactory and Topic have been made available to the bean by a resource reference in the first example, and by a resource environment reference in the second example. The standard deployment descriptor should contain the following element:

jms/conFactSender javax.jms.ConnectionFactory Container

jms/topiclistener javax.jms.Topic

The JOnAS−specific deployment descriptor should contain the following element:

jms/conFactSender TCF

jms/topiclistener sampleTopic

A JMS EJB example 243 JMS User's Guide

Note that the EjbComp SessionBean will use the administered objects automatically created by JOnAS in the default JMS configuration.

Because the administered objects are now accessible, it is possible to perform JMS operations within a method. The following occurs in the sendMsg method: public class EjbCompBean implements SessionBean { ... public void sendMsg(java.lang.String s) { // create Connection, Session and MessageProducer Connection conn = null; Session session = null; MessageProducer mp = null; try { conn = cf.createConnection(); session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE); mp = session.createProducer((Destination)topic); } catch (Exception e) {e.printStackTrace();}

// send the message to the topic try { ObjectMessage message; message = session.createObjectMessage(); message.setObject(s); mp.send(message); session.close(); conn.close(); } catch (Exception e) { e.printStackTrace(); } } ... }

This method sends a message containing its String argument.

The Entity Bean

The example uses the simple entity bean Account for writing data into a database. Refer to the sample eb.

The Client Application

The client application calls the sendMsg method of the EjbComp bean and creates an AccountImpl entity bean, both within the same transaction. public class EjbCompClient { ... public static void main(String[] arg) { ...

A JMS EJB example 244 JMS User's Guide

utx = (UserTransaction) initialContext.lookup("javax.transaction.UserTransaction"); ... home1 = (EjbCompHome) initialContext.lookup("EjbCompHome"); home2 = (AccountHome) initialContext.lookup("AccountImplHome"); ... EjbComp aJmsBean = home1.create(); Account aDataBean = null; ... utx.begin(); aJmsBean.sendMsg("Hello commit"); // sending a JMS message aDataBean = home2.create(222, "JMS Sample OK", 0); utx.commit();

utx.begin(); aJmsBean.sendMsg("Hello rollback"); // sending a JMS message aDataBean = home2.create(223, "JMS Sample KO", 0); utx.rollback(); ... } }

The result of this client execution will be that:

• the "Hello commit" message will be sent and the [222, 'JMS Sample OK', 0] record will be created in the database (corresponding to the entity bean 109 creation). • the "Hello rollback" message will never be sent and the [223, 'JMS Sample KO', 0] record will not be created in the database (since the entity bean 110 creation will be canceled).

A pure JMS client for receiving messages

In this example, the messages sent by the EJB component are received by a simple JMS client that is running outside the JOnAS server, but listening for messages sent on the JMS topic "sampleTopic." It uses the ConnectionFactory automatically created by JOnAS named "JCF." public class MsgReceptor {

static Context ictx = null; static ConnectionFactory cf = null; static Topic topic = null;

public static void main(String[] arg) {

ictx = new InitialContext(); cf = (ConnectionFactory) ictx.lookup("JCF"); topic = (Topic) ictx.lookup("sampleTopic"); ... Connection conn = cf.createConnection(); Session session = conn.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer mc = session.createConsumer((Destination)topic);

A JMS EJB example 245 JMS User's Guide

MyListenerSimple listener = new MyListenerSimple(); mc.setMessageListener(listener); conn.start();

System.in.read(); // waiting for messages

session.close(); conn.close(); ... } } public MyListenerSimple implements javax.jms.MessageListener { MyListenerSimple() {}

public void onMessage(javax.jms.Message msg) { try { if(msg==null) System.out.println("Message: message null "); else { if(msg instanceof ObjectMessage) { String m = (String) ((ObjectMessage)msg).getObject(); System.out.println ("JMS client: received message ======> " + m); } else if(msg instanceof TextMessage) { String m = ((TextMessage)msg).getText(); System.out.println ("JMS client: received message ======> " + m); } }catch(Exception exc) { System.out.println("Exception caught :" + exc); exc.printStackTrace(); } } }

A JMS EJB example 246 Ant EJB Tasks User Manual

New JOnAS (Java Open Application Server) element for the current JOnAS version

The nested element uses the GenIC−specific tool to build JOnAS−specific stubs and skeletons and construct a JAR file which may be deployed to the JOnAS Application Server. The build process will always determine if the EJB stubs/skeletons and the EJB−JAR file are up to date, and it will perform the minimum amount of work required.

A naming convention for the EJB descriptors is most commonly used to specify the name for the completed JAR file. For example, if the EJB descriptor ejb/Account−ejb−jar.xml is located in the descriptor directory, the element will search for a JOnAS−specific EJB descriptor file named ejb/Account−jonas−ejb−jar.xml, and a JAR file named ejb/Account.jar will be written in the destination directory. The element can also use the JOnAS naming convention. Using the same example, the EJB descriptor can also be named ejb/Account.xml (no base name terminator here) in the descriptor directory. The element will then search for a JOnAS−specific EJB descriptor file called ejb/jonas−Account.xml. This convention does not strictly follow the ejb−jar naming convention recommendation, but it is supported for backward compatibility with previous version of JOnAS.

Note that when the EJB descriptors are added to the JAR file, they are automatically renamed META−INF/ejb−jar.xml and META−INF/jonas−ejb−jar.xml.

Furthermore, this naming behaviour can be modified by specifying attributes in the ejbjar task (for example, basejarname, basenameterminator, and flatdestdir) as well as the iplanet element (for example, suffix). Refer to the appropriate documentation for more details.

Parameters:

Attribute Description Required destdir The base directory into which the generated JAR files will be written. Each JAR file is Yes written in directories which correspond to their location within the "descriptordir" namespace. jonasroot The root directory for JOnAS. Yes jonasbase The base directory for JOnAS. If omitted, it defaults to jonasroot. No classpath The classpath used when generating EJB stubs and skeletons. If omitted, the classpath No specified in the "ejbjar" parent task will be used. If specified, the classpath elements will be prefixed to the classpath specified in the parent "ejbjar" task. A nested "classpath" elements can also be used. Note that the needed JOnAS JAR files are automatically added to the classpath. keepgenerated No

Ant EJB Tasks User Manual 247 Ant EJB Tasks User Manual

true if the intermediate Java source files generated by GenIC must not be deleted. If omitted, it defaults to false. nofastrmic if true, the external RMIC compiler is used by GenIC. The default is false, which No means the internal fast RMIC compiler is used. nocompil true if the generated source files must not be compiled via the java and rmi compilers. If No omitted, it defaults to false. novalidation true if the XML deployment descriptors must be parsed without validation. If omitted, it No defaults to false. javac Java compiler to use. If omitted, it defaults to the value of build.compiler property. No javacopts Options to pass to the java compiler. No protocols Comma−separated list of protocols (chosen within jeremie, jrmp, iiop, cmi) for which No stubs should be generated. Default is jrmp,jeremie. rmicopts Options to pass to the rmi compiler. No verbose Indicates whether or not to use −verbose switch. If omitted, it defaults to false. No additionalargs Add additional args to GenIC. No keepgeneric true if the generic JAR file used as input to GenIC must be retained. If omitted, it No defaults to false. suffix String value appended to the JAR filename when creating each JAR. If omitted, it defaults No to ".jar". nogenic If this attribute is set to true, JOnAS's GenIC will not be run on the EJB JAR. Use this if No you prefer to run GenIC at deployment time. If omitted, it defaults to false. jvmopts Additional args to pass to the GenIC JVM. No invokecmd If this attribute is set to true, GenIC will use the Javac sun class to avoid using 'javac' No command line. This is useful for users getting 'java.io.Exception CreateProcess' because of too long command lines. Defaults to false. As noted above, the jonas element supports additional nested elements.

Examples

Note : To avoid java.lang.OutOfMemoryError, the element jvmopts can be used to change the default memory usage.

This example shows ejbjar being used to generate deployment jars using a JOnAS EJB container. This example requires the naming standard to be used for the deployment descriptors. Using this format creates a EJB JAR file for each variation of '*−jar.xml' that is located in the deployment descriptor directory.

New JOnAS (Java Open Application Server) element for the currentJOnAS version 248 Ant EJB Tasks User Manual

protocols="jrmp,iiop"/>

This example shows ejbjar being used to generate a single deployment jar using a JOnAS EJB container. This example does require the deployment descriptors to use the naming standard. This creates only one ejb jar file − 'TheEJBJar.jar'.

GenIC Ant Task

Why is there a new task?

Previous versions of the JOnAS EjbJar Ant task have some limitationsespecially when you are developing webservices.

In previous versions of JOnAS, jonas−ejb−jar constructed the JAR for you, using information gathered from the ejb−jar.xml and from the classes themselves (dependencies using BCEL). But if you have a Session Bean exposed as a webservice, you want to have more files in your archive (webservices.xml, JAX−RPC mapping file, WSDL + imported WSDL definitions + imported XML Schema).

The older task did not package these files inside the archive, and therefore, when GenIC loaded the descriptors, some dependencies were missing, causing GenIC to throw an exception.

The solution is to let the developer create the JAR file, so that the exact content of the file can be controlled.

The file should have at least the following content:

• META−INF/ejb−jar.xml • META−INF/jonas−ejb−jar.xml • **/*.class

Notice that webservices files are optional.

GenIC Ant Task 249 Ant EJB Tasks User Manual

Task Attributes

The genic task supports most attributes of the jonas−ejb−jar task.

Differences:

• Removed destdir: JAR files are directly modified • Removed classpath: classpath is now set as inner element • Removed novalidation: validation attribute is used now • Removed keepgeneric: not meaningful (input JAR is already specific) • Removed suffix: not meaningful (no JAR generated) • Removed nogenic: not meaningful (we want to run GenIC)

Attribute Description Required jonasroot The root directory for JOnAS. Yes (Can be read from ${jonas.root} property if not set) jonasbase The base directory for JOnAS. If omitted, it defaults to jonasroot. No keepgenerated true if the intermediate Java source files generated by GenIC must not be No deleted. If omitted, it defaults to false. nofastrmic if true, the external RMIC compiler is used by GenIC. The default is No false, which means the internal fast RMIC compiler is used. nocompil true if the generated source files must not be compiled via the Java and No RMI compilers. If omitted, it defaults to false. validation true if the XML deployment descriptors must be parsed with validation. No If omitted, it defaults to true. javac Java compiler to use. If omitted, it defaults to the value of No build.compiler property. javacopts Options to pass to the Java compiler. No protocols Comma−separated list of protocols (chosen from jeremie, jrmp, iiop, cmi) No for which stubs should be generated. Default is jrmp,jeremie. rmicopts Options to pass to the RMI compiler. No verbose Indicates whether or not to use −verbose switch. If omitted, it defaults to No false. additionalargs Add additional arguments to GenIC. No jvmopts Additional arguments to pass to the GenIC JVM. No jvmdebug Indicates whether you want to debug the forked JVM; it defaults to No false. The JVM will be suspended and waiting a connection on port 12345.

GenIC Ant Task 250 Ant EJB Tasks User Manual

invokecmd If this attribute is set to true, GenIC will use the Javac sun class to avoid No using 'javac' command line. This is useful for users getting 'java.io.Exception CreateProcess' because of too long command lines. Defaults to false.

Nested Description Required Element classpath The additional classpath entries used when generating EJB stubs and skeletons. No fileset Points out the ejb−jars that will be processed by GenIC. Note that you can add as many Yes (at least filesets as you want (useful if your JARs are in different directories). 1)

Example:

1. First, define this new task:

2. Then use it: a. Create the JAR file :

b. Process this JAR with the GenIC task :

GenIC Ant Task 251 Login Modules in a Java Client Guide

The content of this guide is the following:

1. Configuring an environment to use login modules with java clients 2. Example of a client

Configuring an environment to use login modules with java clients

The login modules for use by clients are defined in the file $JONAS_ROOT/conf/jaas.config. Example: jaasclient { // Login Module to use for the example jaasclient.

//First, use a LoginModule for the authentication // Use the resource memrlm_1 org.objectweb.jonas.security.auth.spi.JResourceLoginModule required resourceName="memrlm_1" ;

// Use the login module to propagate security to the JOnAS server // globalCtx is set to true in order to set the security context // for all the threads of the client container instead of only // on the current thread. // Useful with multithread applications (like Swing Clients) org.objectweb.jonas.security.auth.spi.ClientLoginModule required globalCtx="true" ; };

This file is used when a java client is launched with jclient, as a result of the following property being set by jclient: −Djava.security.auth.login.config==$JONAS_ROOT/conf/jaas.config

For more information about the JAAS authentication, refer to the JAAS authentication tutorial.

Example of a client

• First, the CallbackHandler to use is declared. It can be a simple command line prompt, a dialog, or even a login/password to use. Example of CallbackHandler that can be used within JOnAS.

CallbackHandler handler1 = new LoginCallbackHandler(); CallbackHandler handler2 = new DialogCallbackHandler(); CallbackHandler handler3 = new NoInputCallbackHandler("jonas_user", "jonas_password");

Login Modules in a Java Client Guide 252 Login Modules in a Java Client Guide

• Next, the LoginContext method with the previously defined CallbackHandler and the entry to use from the JONAS_ROOT/conf/jaas.config file is called. This example uses the dialog callbackhandler.

LoginContext loginContext = new LoginContext("jaasclient", handler2);

• Finally, the login method on the LoginContext instance is called.

loginContext.login();

If there are no exceptions, the authentication is successful. Authentication can fail if the supplied password is incorrect.

Login Modules in a Java Client Guide 253 Web Services with JOnAS

Starting with JOnAS 3.3, Web Services can be used within EJBs and/or servlets/JSPs. This integration conforms to the JSR 921(Web Service for J2EE v1.1) specification.

1. Web Services

A. Some Definitions

WSDL: WSDL (Web Service Description Language v1.1) is an XML−based format for specifying the interface to a web service. The WSDL details the service's available methods and parameter types, as well as the actual SOAP endpoint for the service. In essence, WSDL is the "user's manual" for the web service. SOAP: SOAP (Simple Object Access Protocol v1.2) is an XML−based protocol for sending request and responses to and from web services. It consists of three parts: an envelope defining message contents and processing, encoding rules for application−defined data types, and a convention for representing remote procedure calls and responses. JAX−RPC: JAX−RPC (Java Api for XML RPC v1.1) is the Java API for XML−based RPC. RPC (Remote Procedure Call) allows a client to execute procedures on other systems. The RPC mechanism is often used in a distributed client/server model in which the server defines a service as a collection of procedures that may be called by remote clients. In the context of Web services, RPCs are represented by the XML− based protocol SOAP when transmitted across systems. In addition to defining envelope structure and encoding rules, the SOAP specification defines a convention for representing remote procedure calls and responses. An XML−based RPC server application can define, describe and export a web service as an RPC−based service. WSDL (Web Service Description Language) specifies an XML format for describing a service as a set of endpoints operating on messages. With the JAX−RPC API, developers can implement clients and services described by WSDL.

B. Overview of a Web Service

Strictly speaking, a Web Service is a well−defined, modular, encapsulated function used for loosely coupled integration between applications' or systems' components. It is based on standard technologies, such as XML, SOAP, and UDDI.

Web Services are generally exposed and discovered through a standard registry service. With these standards, Web Services consumers (whether they be users or other applications) can access a broad range of information −− personal financial data, news, weather, and enterprise documents −− through applications that reside on servers throughout the network.

Web Services use a WSDL Definition (refer to www.w3.org/TR/WSDL) as a contract between client and server (also called endpoint). WSDL defines the types to serialize through the network (described with XMLSchema), the messages to send and receive (composition, parameters), the portTypes (abstract view of a Port), the bindings (concrete description of PortType: SOAP, GET, POST, ...), the services (set of Ports), and the Port (the port is

Web Services with JOnAS 254 Web Services with JOnAS

associated with a unique endpoint URL that defines the location of the Web Service).

A Web Service for J2EE is a component with some methods exposed and accessible by HTTP (through servlet(s)). Web Services can be implemented as Stateless Session Beans or as JAXRPC classes (a simple Java class, no inheritance needed).

Figure 1. Web Services endpoints deployed within JOnAS (an external client code can access the endpoint via AxisServlet)

Web Services with JOnAS 255 Web Services with JOnAS

Figure 2. Web Services client deployed within JOnAS (can access external Web Services) The servlet is used to respond to a client request and dispatch the call to the designated instance of servant (the SSB or JAXRPC class exposed as Web Service). It handles the deserialization of incoming SOAP message to transform SOAP XML into a Java Object, perform the call, and serialize the call result (or the thrown exception) into SOAP XML before sending the response message to the client.

2. Exposing a J2EE Component as a Web Service

There are two types of J2EE components that can be exposed as Web Services endpoints: StateLess Session Beans and JAX−RPC classes. Web Services' Endpoints must not contain state information.

A new standard Deployment Descriptor has been created to describe Web Services endpoints. This Descriptor is named "webservices.xml" and can be used in a webapp (in WEB−INF/) or in an EjbJar (in META−INF/). This Descriptor has its JOnAS−specific Deployment Descriptor (jonas−webservices.xml is optional).

Refer to the webServices sample for example files.

A. JAX−RPC Endpoint

A JAX−RPC endpoint is a simple class running in the servlet container (Tomcat or Jetty). SOAP requests are dispatched to an instance of this class and the response is serialized and sent back to the client. A JAX−RPC endpoint must be in a WebApp (the WAR file must contain a "WEB−INF/webservices.xml").

B. Stateless Session Bean Endpoint

An SSB is an EJB that will be exposed (all or some of its methods) as a Web Service endpoint. In the ejb−jar.xml standard descriptor, a session bean, exposed as a web service, must now use the new service−endpoint tag. Here the developer defines the fully−qualified interface name of the web service. Notice that no other interfaces (home, remote, localhome, local) are needed with a session bean exposed as web service.

Typically, an SSB must be in an EjbJar, and a "META−INF/webservices.xml" is located in the EjbJar file.

C. Usage

In this Descriptor, the developer describes the components that will be exposed as Web Services' endpoints; these are called the port−component(s). A set of port−components defines a webservice−description, and a webservice−description uses a WSDL Definition file for a complete description of the Web Services' endpoints.

Each port−component is linked to the J2EE component that will respond to the request (service−impl−bean with a servlet−link or ejb−link child element) and to a WSDL port (wsdl−port defining the port's QName). A list of

2. Exposing a J2EE Component as a Web Service 256 Web Services with JOnAS

JAX−RPC Handlers is provided for each port−component. The optional service−endpoint−interface defines the methods of the J2EE components that will be exposed (no inheritance needed).

A JAX−RPC Handler is a class used to read and/or modify the SOAP Message before transmission and/or after reception (refer to the JAX−RPC v1.1 spec. chap#12 "SOAP Message Handlers").The Session Handler is a simple example that will read/write SOAP session information in the SOAP Headers. Handlers are identified with a unique name (within the application unit), are initialized with the init−param(s), and work on processing a list of SOAP Headers defined with soap−headers child elements. The Handler is run as the SOAP actor(s) defined in the list of soap−roles.

A webservice−description defines a set of port−components, a WSDL Definition (describing the Web Service) and a mapping file (WSDL−2−Java bindings). The wsdl−file element and the jaxrpc−mapping−file element must specify a path to a file contained in the module unit (i.e., the war/jar file). Note that a URL cannot be set here. The specification also requires that the WSDLs be placed in a wsdl subdirectory (i.e., WEB−INF/wsdl or META−INF/wsdl); there is no such requirement for the jaxrpc−mapping−file. All the ports defined in the WSDL must be linked to a port−component. This is essential because the WSDL is a contract between the endpoint and a client (if the client uses a port not implemented/linked with a component, the client call will systematically fail).

As for all other Deployment Descriptor, a standard XML Schema is used to constrain the XML.

D. Simple Example (expose a JAX−RPC Endpoint) of webservices.xml

Simple Web Service Endpoint DeploymentDesc

SimpleWebServiceEndpoint

WEB−INF/wsdl/warendpoint.wsdl

WEB−INF/warEndpointMapping.xml

2. Exposing a J2EE Component as a Web Service 257 Web Services with JOnAS

WebappPortComp1

ns:wsendpoint1

org.objectweb.ws.servlets.wsendpoint.WSEndpointSei

WSEndpoint

MyHandler org.objectweb.ws.handlers.SimpleHandler

param1 value1 param2 value2

2. Exposing a J2EE Component as a Web Service 258 Web Services with JOnAS

E. The optional jonas−webservices.xml

The jonas−webservices.xml file is an optional deployment descriptor that is used only for stateless session bean endpoints. This descriptor is used by WsGen to set some specifics for the generated webapp that is in charge of the SOAP request dispatching. Its role is to allow for the specifications of the webapp's name, context root, security settings and endpoint URL customization.

War Name: Specifies the name of the generated WAR. Setting the element is optional; if it is not specified, then the default naming convention is used to retrieve the WAR name from the ejbjar's name.

Default Naming: .jar will have an .war WebApp.

Context Root: Specifies the context root of the generated WAR. Setting the element is optional; if it is not specified, then the default naming convention is used and the context root will be the same as the WAR's name.

Default Naming: .war will have an context root.

Endpoint URL Customization: Specifies the endpoint URL of a given jonas−port−component. Setting the element is optional; if it is not specified, then the default naming convention is used and the URL will look like ///. Security: The security settings specify which security settings, if any, the generated webapp should use. Setting up security within this file is very similar to how security would be set up in a regular web.xml.

NOTE: When using the , , or

Security Constraint: the specifies the in the web.xml of the generated webapp.

Login Config: the specifies the in the web.xml of the generated webapp.

Security Role: the specifies the in the web.xml of the generated webapp.

Realm: the specifies the security realm for the generated webapp.

Realm Name: the specifies the name of the security realm for the generated webapp.

Example:

2. Exposing a J2EE Component as a Web Service 259 Web Services with JOnAS

dispatchingWebApp.war

endpoint

ssbEndpoint ://services1/webservice −−> /services1/webservice

Stateless Session Bean Endpoint /* admin

BASIC Endpoint Authentication Area

admin

memrlm_1

Endpoint Authentication Area

F. Changes to jonas−web.xml

JOnAS allows the developer to fully configure an application by setting the hostname, the context−root, and the port used to access the Web Services. This is done in the jonas−web.xml of the dispatching WebApp. host: configure the hostname to use in URL (must be an available web container host). port: configure the port number to use in URL (must be an available HTTP/HTTPS connector port number).

2. Exposing a J2EE Component as a Web Service 260 Web Services with JOnAS

When these values are not set, JOnAS will attempt to determine the default values for host and port. Limitations: − The host can only be determined when only one host is set for the web container. − The port can only be determined when only one connector is used by the web container.

3. The client of a Web Service

An EJB or a servlet that wants to use a Web Service (as client) must declare a dependency on the Web Service with a service−ref element (same principle as for all *−ref elements).

A. The service−ref element

The service−ref element declares reference to a Web Service used by a J2EE component in the web, EJB and Client application Deployment Descriptor. The component uses a logical name called a service−ref−name to lookup the service instance. Thus, any component that performs a lookup on a Web Service must declare a dependency (the service−ref element) in the standard deployment descriptor (web.xml, ejb−jar.xml or application−client.xml).

Example of service−ref:

Sample WebService Client

WebService Client 1

services/myService

javax.xml.rpc.Service

3. The client of a Web Service 261 Web Services with JOnAS

WEB−INF/wsdl/stockQuote.wsdl

WEB−INF/myMapping.xml

ns:MyWSDLService

org.objectweb.ws.beans.ssbendpoint.MyService

ejb_module.jar#PortComponentName

MyHandler

org.objectweb.ws.handlers.myHandler

3. The client of a Web Service 262 Web Services with JOnAS

param_1 value_1

ns:MyWSDLHeader

http://actor.soap.objectweb.org

myWSDLPort

B. The jonas−service−ref element

A jonas−service−ref must be specified for each service−ref declared in the standard Deployment Descriptor. The jonas−service−ref adds JOnAS−specific (and Web Service engine−specific) information to service−ref elements.

Example of jonas−service−ref:

services/myService

3. The client of a Web Service 263 Web Services with JOnAS

webservice_1

param name

4. WsGen

WsGen is a new JOnAS tool that works in the same way as GenIC. It takes archive files (EJB−JAR, WAR, JAR client, EAR) and generates all the necessay components related to web services:

• Creates vendor−specific web−services deployment files for the server side and, when needed, the client side (Axis will use its own wsdd format). • Creates a WebApp for each EJB−JAR exposing web services. • Generates and compiles client side artifacts (Services and Port Bindings implementations classes).

For example, to provide an EJB−exposing method as a web service, a developer creates a webservices.xml file packaged in EjbJar's META−INF directory. WsGen automatically creates a configured webapp (using an Axis servlet) and wraps it (ejbjar + webapp) in an EAR file.

With a JaxRpc class, WsGen adds a servlet (an Axis servlet) inside the existing web deployment descriptor and generates an Axis−specific configuration file.

When using service−ref (from ejbjars, web applications, or clients), WsGen automatically generates a Stub from WSDL (if a generated service interface name is provided).

Usage

WsGen is used typically from an ant build file. Simply add this taskdef under the ejbjar taskdef:

See the $JONAS_ROOT/examples/webservices samples for complete build scripts.

4. WsGen 264 Web Services with JOnAS

Note that the ejbjar/webapp/client archive must include WSDL, jax−rpc−mappings used in service−ref, or webservices.xml. When these files are used from a service−ref, they are added into the generic ejb−jar with the ejbjar ant task of JOnAS; you must ensure that they have been placed inside the srcdir given to the ejbjar task (otherwise, the ejbjar task cannot find them and will produce an error).

This task is a directory−based task and, as such, forms an implicit Fileset. This defines which files, relative to the srcdir, will be processed. The wsgen task supports all the attributes of Fileset to refine the set of files to be included in the implicit fileset.

Attribute Description Required

srcdir Directory where file archive (EjbJar, War, Client, Ear) is located Yes

destdir Directory where generated files will be placed No

verbose Verbose mode (Defaults to false) No

debug Debug mode (Defaults to false) No

javacopts List of options given to the java compiler No

jonasroot Directory where JOnAS is installed No

jonasbase Directory where JOnAS configuration is stored No

Wsgen is also usable from the command line with WsGen script (available on *nix and Windows). last update : 19 Oct 2005

4. WsGen 265 Working with Management Beans

The content of this guide is the following:

1. Target Audience and Rationale 2. About JOnAS MBeans and their use in JonaSAdmin 3. Using JOnAS MBeans in a Management Application 4. Registering User MBeans

Target Audience and Rationale

This chapter is intended for advanced JOnAS users who are interested in understanding management facilities that JOnAS provides, and possibly extending these facilities for their application needs.

JOnAS management facilities are based on Management Beans (MBeans) compliant to JMX Specification. Moreover, JOnAS implements JSR 77 specification, which defines the management model for J2EE platforms.

About JOnAS MBeans and their use in JonaSAdmin

MBeans provide access to management functions such as configuration, deployment/undeployment, monitoring of resources and application modules.

MBeans are created not only by the different JOnAS services, but also by the components integrated in JOnAS (Web server Tomcat or Jetty, JORAM MOM, etc.). They are registered in the current MBean Server, which is started by each JOnAS server instance. Remote access to the MBean Server is facilitated by JMX remote connectors compliant to the JSR 160 specification. See more information about connectors here.

JonasAdmin application implements the management functions listed above using the different MBeans registered in the MBeanServer of the JOnAS instance currently being managed. This is usually the server on which JonasAdmin is deployed, but it may be another server running in the same management domain.

JonasAdmin also presents, in a structured way, all the registered MBeans, their attributes and operations. In the future, JonasAdmin will probably be extended to allow setting attributes and invoking operations.

Using JOnAS MBeans in a Management Application

In order to invoke a management operation on a MBean, the caller must access to the MBean server.

Local MBean Server

When the caller is located in the same JVM as the MBean Server, it can use javax.management.MBeanServerFactory class to obtain a reference to the MBean Server:

Working with Management Beans 266 Working with Management Beans

List mbeanServers = MBeanServerFactory.findMBeanServer(null); if (mbeanServers != null && mbeanServers.size() > 0) { return (MBeanServer) mbeanServers.get(0); }

Using Remote Connectors

When the caller is remote, it can use a JMX remote connector to establish a connection with the MBean Server and obtain a javax.management.MBeanServerConnection object.

Suppose that the connector server has the following address: service:jmx:jrmp://host/jndi/jrmp://host:1099/jrmpconnector_jonas, which is the default for a JOnAS server called jonas.

JMXServiceURL connURL = new JMXServiceURL("service:jmx:jrmp://host/jndi/jrmp://host:1099/jrmpconnector_jonas"); JMXConnector connector = JMXConnectorFactory.newJMXConnector(connURL, null); connector.connect(null); MBeanServerConnection conn = connector.getMBeanServerConnection(); return conn;

Using a Management EJB

A remote caller can also use the MEJB provided by the JOnAS distribution. A Management EJB implementation, compliant to the JSR 77, is packed in the mejb.ear installed in the JONAS_ROOT/ejbjars/autoload directory. Thus, the MEJB is automatically deployed at JOnAS start−up. Its Home is registered in JNDI under the name ejb/mgmt/MEJB. JOnAS distribution also contains an example using the MEJB in a J2EE application, the j2eemanagement sample.

Using the Management Web Service Endpoint

A remote caller can use the Management Web Service endpoint packaged as a part of the mejb.ear installed in the JONAS_ROOT/ejbjars/autoload directory. Thus, the management endpoint is automatically deployed at JOnAS start−up. Check http://:/mejb/ManagementEndpoint/ManagementEndpoint?wsdl for the WSDL file on a running JOnAS instance. The endpoint allows light−weight clients to query JOnAS MBeans from virtually any platform by leveraging the platform−independant nature of Web Services.

Registering User MBeans

Application MBeans can be created and registered in the MBean server by calling registerMBean method on the MBeanServer object or createMBean method on the MBeanServerConnection object. Also, MBeans can be loaded using the m−let service, a dynamic loading mechanism provided by the JMX implementation. This mechanism allows loading MBeans from a remote URL. The information on the MBeans to load is provided in a m−let text file. Refer to JMX implementation documentation for details concerning this file. In addition, the howto

Using JOnAS MBeans in a Management Application 267 Working with Management Beans

document JOnAS and JMX, registering and manipulating MBeans illustrates the use of this m−let mechanism. In order to make an m−let text file accessible to JOnAS applications, it can be installed in the JONAS_ROOT/conf directory.

Using JOnAS MBeans in a Management Application 268 Domain Management in JOnAS

The content of this guide is the following:

1. Target Audience and Rationale 2. Domain Management Goals 3. Mechanisms used by Domain Management 4. How to start Servers in a Domain

Target Audience and Rationale

This guide is intended for JOnAS administrators responsible for the configuration and administration of JOnAS servers running within a management domain.

Domain Management Goals

A JOnAS management domain is composed of a set of JOnAS servers that are running under the same management authority and are identified by a domain name.

The servers in a domain can be administered by a management application running on one server (or several) in the domain; this is the role of administrator or master. The managed servers play the role of slaves.

Typically, when deploying the JonasAdmin application on a slave, the administrator can manage only the server on which the application is running. When deploying JonasAdmin on a master server, the administrator can manage all the servers in the domain.

Mechanisms used by Domain Management

Basically, domain management in JOnAS relies on JSR 160 specification. When a JOnAS server is started, it creates at least one JSR 160 connector server as explained in JSR 160 support in JOnAS.

A connector server makes it possible for a JMX remote API client to access and manage the MBeans exposed through the MBean server running in a remote JVM. In order to establish a connection, the remote client needs to know the address of the connector server. JSR 160 does not provide any specific API that would make it possible for a client to find the address of a connector server. The standard suggests using existing discovery and lookup infrastructures; for instance, JNDI API with a LDAP back end.

Currently, a new service added to JOnAS, the Discovery Service, allows JOnAS servers running over a LAN within the same management domain to communicate to each other the connector−server addresses they create at start−up. All the servers in the domain having the discovery service in the services list, will publish their connector−server address at start−up. The goal is to allow master servers to discover which servers are running in their domain, and to establish connections allowing them to remotely manage the slave servers by a management application deployed on a master server.

Domain Management in JOnAS 269 Domain Management in JOnAS

In the future, the discovery service will evolve towards a more standard implementation in order to allow remote management of servers running on hosts connected to a WAN.

The current discovery service implementation is based on MBeans (called discovery MBeans) which use:

• IP Multicast protocol to communicate their connector−server addresses and state transitions to each other. • JMX notifications to update domain management information within a master server.

Domain management information can be retrieved from J2EEDomain MBean and from the JMX service implementation object. Indeed, both J2EEDomain MBean and JmxServiceImpl instances are listeners of JMX notifications sent by discovery MBeans.

J2EEDomain MBean

The J2EEDomain MBean has the following JMX ObjectName:

domainName:j2eeType=J2EEDomain,name=domainName

Where domainName is the name of the domain.

A J2EEDomain MBean contains the following management attributes and operations:

• If the J2EEDomain is registered in a master server's MBean server, the servers attribute keeps the list of the servers running in the domain. Otherwise, it contains only one element corresponding to itself. The elements in the servers list are Strings representing J2EEServer ObjectNames associated to the running servers. By iterating over the servers list, a management application can determine the name of the servers in the domain. • The getConnectorServerURLs operation returns the connector server addresses for a server in the list.

In order to administer a given server in the domain, any management application has to create a MBeanServerConnection object using one of the connector−server addresses corresponding to that server (see the j2eemanagement sample).

Domain management information in JMX service

The JMX service, as the J2EEDomain MBean, implements mechanisms that update information about the servers running in the current domain, and creates ready−to−use MBeanServerConnection connection objects. The JonasAdmin application, for example, uses these connection objects via the JonasManagementRepr helper class.

How to start manageable servers in a Domain

The servers must obey these rules:

• The servers must be started on hosts connected by a LAN.

Mechanisms used by Domain Management 270 Domain Management in JOnAS

• The servers must be configured with the discovery service activated (see Configuring Discovery Service). • There must be at least one master server in the domain. The role of a server, slave or master, is determined by the discovery service configuration. • The servers must have different names, but the same domain name.

Also note the following:

• Servers may be started in any order. • Servers may join or leave the domain at any time. Domain management information is updated on the master server(s). • A slave server may become master by invoking the startDiscoveryMaster management operation exposed by the discovery service. This operation can be invoked using the JonasAdmin management console deployed on a master.

Example

Consider a scenario in which there are three JOnAS servers named jonas, j1 and j2. Assume that they have discovery service configured with at least one of the servers playing the role of master.

• Start the server named jonas in domain jonas (by default, the domain name is given by the server's name)

jonas start

• Start the server named j1 in domain jonas

jonas start −n j1 −Ddomain.name=jonas

• Start the server named j2 in domain jonas

jonas start −n j2 −Ddomain.name=jonas

How to start manageable servers in a Domain 271 Howto: JOnAS Versions Migration Guide

The content of this guide is the following:

• JOnAS 4.3.x to JOnAS 4.4.1 • JOnAS 4.1 to JOnAS 4.3.2 • JOnAS 3.3.x to JOnAS 4.1 • JOnAS 3.1 to JOnAS 3.1.4 • JOnAS 3.0 to JOnAS 3.1 • JOnAS 2.6.4 to JOnAS 3.0 1. Application with entity beans CMP 1.1 • JOnAS 2.6 to JOnAS 2.6.1 1. Installation procedure 2. EJB container creation • JOnAS 2.5 to JOnAS 2.6 1. Use of Make discontinued for building 2. Building with Ant 1.5 3. New jonas command 4. EJB container creation 5. Tomcat 4.0.x Support 6. Tomcat Service and Web Container Service • JOnAS 2.4.4 to JOnAS 2.5 1. Tomcat 4.0.x Support 2. trace.properties • JOnAS 2.4.3 to JOnAS 2.4.4 • JOnAS 2.3 to JOnAS 2.4 1. Introduction 2. Upgrading the jonas.properties file 3. Upgrading the Jonathan configuration file

JOnAS 4.3.x to JOnAS 4.4.1

Applications developed for JOnAS 4.3.x do not require changes; The main changes occur within the JOnAS configuration files, and it is recommended that you report your customizations in the new JOnAS 4.4.1 configuration files, especially for the ones mentioned below.

Applications redeployment

This JOnAS's version offers a new mechanism to ensure application redeployment during the migration. At the deployment time, GenIC is automatically launched by the server whether a version change is detected.

Howto: JOnAS Versions Migration Guide 272 Howto: JOnAS Versions Migration Guide

Configuration changes

The most visible configuration changes are the following:

1. Tomcat 5.0 −> Tomcat 5.5. See the wiki about tomcat here.

Update your $JONAS_BASE

• If starting from an existing JONAS_BASE, it must be updated in order to upgrade to the lastest ear/war/jar/rar files provided (e.g. new versions of the JORAM or JDBC rars).

cd $JONAS_ROOT ant update_jonasbase

• mejb is packaged as an ear in the new version, while it was delivered in an ejbjar in the previous version. Thus the old ejbjar must be deleted.

cd $JONAS_BASE/ejbjars/autoload rm mejb.jar

JORAM 4.3.0

JOnAS 4.4.1 integrates the new JORAM 4.3.0 which contains:

• performance optimizations • new feature: SSL for client−server communications • new feature of SoftReference Messages allowing swap out: ability to send large messages, destinations can store more and more messages, the messages are not held in memory.

The lastest implementation required changes to the message persistance module. Therefore, JORAM's stored messages from the previous versions are not compliant with this new version; you must delete JORAM's persistance directory (s0 by default) before the migration.

JOnAS 4.1 to JOnAS 4.3.x

Applications developed for JOnAS 4.1 do not require changes; however, they should be redeployed (GenIC). The main changes occur within the JOnAS configuration files, and it is recommended that you report your customizations in the new JOnAS 4.3.2 configuration files, especially for the ones mentioned below.

Configuration changes

The most visible configuration changes are the following:

1. JORAM's rar usage is set by default instead of the jms service

JOnAS 4.3.x to JOnAS 4.4.1 273 Howto: JOnAS Versions Migration Guide

2. JOnAS no longer uses the JRE ORB implementation; it uses the JacORB implementation. The default iiop model now used is the POA model. Thus, GenIC should be relaunched on all previously generated beans.

Configuration files with significant changes:

• conf/jonas.properties: the jms service is removed from the jonas.services property. • conf/joram−admin.cfg: this file is used for specifying the creation of JMS−administered objects when using the JORAM connector. The JMS destinations previously defined in the jonas.properties file (jonas.service.jms.queues and jonas.service.jms.topics) must be moved into this file. • The configuration file of JacORB is the $JONAS_BASE/conf/jacorb.properties file.

Update your $JONAS_BASE

• If starting from an existing JONAS_BASE, it must be updated in order to upgrade to the last built−in provided ear/war/jar/rar files(e.g. new versions of the JORAM or JDBC rars).

cd $JONAS_ROOT ant update_jonasbase

• If you want to keep the jms service and not use the JORAM's rar, you have to remove the $JONAS_BASE/rars/autoload/joram_for_jonas_ra.rar.

JOnAS 3.3.x to JOnAS 4.1

Applications developed for JOnAS 3.3.x do not require changes; however, they should be redeployed (GenIC). The main changes occur within the JOnAS configuration files, and it is recommended to report your customizations in the new JOnAS 4.1 configuration files, especially for the ones mentioned below.

Configuration changes

The two most visible configuration changes are the following:

1. HTTP port numbers have moved from the 8000 range to the 9000 range, e.g. the JOnAS server index page with default configuration on a given host is now http://localhost:9000/index.jsp 2. the three RMI communication protocols, jrmp, jeremie and iiop can now be used simultaneously, the incompatibility between Jeremie and rmi/iiop and the "ant installiiop" step have been suppressed. In any case, the "ant install" phase (in JONAS_ROOT) is no longer needed.

Configuration files with significant changes:

• conf/server.xml: this file is a customized Tomcat 5 configuration file, while in JOnAS 3.3.x it was a Tomcat 4 configuration file. Moreover, package names of JOnAS−related security files have changed, e.g. org.objectweb.jonas.security.realm.web.catalina50.JACC replaces org.objectweb.jonas.security.realm.JRealmCatalina41. The JAAS classname realm is

JOnAS 4.1 to JOnAS 4.3.x 274 Howto: JOnAS Versions Migration Guide

org.objectweb.jonas.security.realm.web.catalina50.JAAS. • conf/jetty5.xml replaces conf/jetty.xml. In the web−jetty.xml files (in war), the package name of the Realm class has changed, e.g. org.objectweb.jonas.security.realm.web.jetty50.Standard replaces org.objectweb.jonas.security.realm.JRealmJetty42 class. The JAAS classname realm is org.objectweb.jonas.security.realm.web.jetty50.JAAS. • conf/jonas.properties: many changes ♦ some properties for web services ♦ some package names have changed (e.g. for the Web JOnAS service) ♦ the XML validation is activated by default for EJBs ♦ new properties for the service 'db' (by default it uses HSQL as java database) • conf/joram−admin.cfg: this is a new configuration file used for specifying the creation of JMS− administered objects when using the JORAM connector (J2EE CA 1.5 JMS resource adapter). The default file corresponds to the default−administered objects created when using the JOnAS JMS service.

Running EJB 2.1 Message−driven Beans

The use of EJB 2.1 Message−driven beans (MDBs) requires changing the JOnAS configuration. While for EJB 2.0 MDBs the JOnAS JMS service was required, EJB 2.1 MDBs can only be used through a JMS Connector (J2EE CA 1.5 resource adapter). Currently the JOnAS JMS service and the JMS connector cannot work at the same time. Therefore, it is necessary to suppress the "jms" service from the list of JOnAS services (jonas.services in jonas.properties) and to add the JORAM connector in the list of resource adapters to be deployed by the JOnAS resource service (jonas.service.resource.resources in jonas.properties). Note that it is currently not possible to run EJB 2.0 MDBs and EJB 2.1 MDBs simultaneously in the same server. It is anticipated that a JMS connector able to handle both EJB 2.0 and EJB 2.1 MDBs will be available soon, at which time the JOnAS JMS service will become deprecated. For more details, refer to the Configuring JMS Service and Configuring JMS Resource Adapters sections of the Configuration Guide.

Deploying Resource Adapters

The RAConfig Resource Adapter configuration tool did not generate the DOCTYPE information in JOnAS 3.3.x versions. If you are using resource adapters that were customized through RAConfig, it is recommended that the tool be run again on these Resource Adapters.

JOnAS 3.1 to JOnAS 3.1.4

Applications developed for JOnAS 3.1 do not require changes; however, they should be redeployed (GenIC). The migration affects only certain customized configuration files and build.xml files.

The main changes are in the area of communication protocols support, due to the integration of CAROL. This implies the following configuration changes:

• The jndi.properties file is replaced by a carol.properties file (in JONAS_BASE/conf or JONAS_ROOT/conf) and is no longer searched for within the classpath. • The OBJECTWEB_ORB environment variable no longer exists.

JOnAS 3.3.x to JOnAS 4.1 275 Howto: JOnAS Versions Migration Guide

• Security context propagation is specified in the jonas.properties file, which replaces the −secpropag option of GenIC or the secpropag attribute of the JOnAS ejb−jar ANT task. • EJBs can be deployed for several protocols, which is specified by the new option −protocols of GenIC or new attribute protocols of the JOnAS ejb−jar ANT task; previously, the protocol was chosen through the OBJECTWEB_ORB environment variable. • The ${OBJECTWEB_ORB}_jonas.jar files, i.e. RMI_jonas.jar or JEREMIE_jonas.jar, no longer exist; there is only one jonas.jar file. • The previous items involve changes in application build.xml files.

Refer to the JOnAS Configuration Guide for details about Communication Protocols configuration.

Other configuration changes are due to security enhancements:

• The files tomcat−users.xml, jonas−users.properties, and jettyRealm.properties, are suppressed and replaced by a jonas−realm.xml file. This file contains the list of users/password/roles for the Memory realm, as well as the access configuration for Database and LDAP realms. Realms declared in this file have corresponding resources bound in the registry, and MBeans to be managed. • The security service should be launched after the dbm service (order in the jonas.services property). • A new realm with a reference to the JOnAS resource specified in the jonas−realm.xml file is used in the server.xml file (Tomcat) or in the web−jetty.xml file (Jetty). • The jonas.properties file contains a new line specifying the jndi name of a resource (ejbrealm) that provides Java access to the user identification repository (memory, ldap, or database) of the corresponding realm (specified in the jonas−realm.xml file). This is primarily used by Java clients that intend to build their SecurityContext.

Refer to the JOnAS Configuration Guide for details about Security configuration.

The preferred steps for migrating from JOnAS 3.1 are the following:

1. Create a new JOnAS_BASE (e.g. through the ANT create_jonasbase target). 2. Copy the new as well as any customized files from the old JONAS_BASE to the new one, conforming to the new configuration rules (jndi.properties replaced by carol.properties, security context propagation and realm specified in jonas.properties, new realm specification in server.xml, changes in your build.xml files, content of tomcat−users.xml, jonas−users.properties or jettyRealm.properties should migrate into jonas−realm.xml).

Details for migrating a configuration are provided in the following sections. carol.properties

Modify this file according to the content of the old jndi.properties file. If the OBJECTWEB_ORB was RMI, set carol.protocols to jrmp; if the OBJECTWEB_ORB was JEREMIE, set carol.protocols to jeremie. Then, configure the URL with host name and port number. Example:

carol.protocols=jrmp carol.jrmp.url=rmi://localhost:1099

JOnAS 3.1 to JOnAS 3.1.4 276 Howto: JOnAS Versions Migration Guide

jonas.properties

If EJB security was used, the security context propagation should be activated. A realm resource can be chosen to be accessed from Java; this is now specified in the jonas.properties file:

jonas.security.propagation true jonas.service.security.ejbrealm memrlm_1 jonas.services registry,jmx,jtm,dbm,security,jms,ejb,web,ear server.xml

Choose the memory, database, or ldap realm resource for Tomcat authentication.

web−jetty.xml

This file is located in the WEB−INF directory of a WAR file and contains a reference to the JOnAS Realm to be used for authentication.

Example Basic Authentication Area Example Basic Authentication Area memrlm_1

Deployment

For existing scripts that call GenIC for deploying EJBs, the −secpropag option no longer exists (security propagation is activated from the jonas.properties file as illustrated previously), and a new option −protocols specifies a comma−separated list of protocols (chosen within jeremie, jrmp, iiop, cmi) for which stubs will be generated. The default value is jrmp,jeremie.

GenIC −protocols jrmp,jeremie,iiop

Refer to the following for the deployment ANT task.

JOnAS 3.1 to JOnAS 3.1.4 277 Howto: JOnAS Versions Migration Guide

build.xml files

The build.xml files for building JOnAS examples have been upgraded according to the new configuration scheme. Existing build.xml files must be updated the same way:

• is no longer used and must be suppressed. • In the target building the classpath, replace ${orb}_jonas.jar by jonas.jar. • In the jonas deployment task, suppress the attributes orb="${orb}" secpropag="yes," and add the attribute protocols="${protocols.names}." The build.properties file of the JOnAS examples now contains protocols.names=jrmp,jeremie.

JOnAS 3.0 to JOnAS 3.1

Applications developed for JOnAS 3.0 can be redeployed without any changes.

The differences in the execution environment are the following:

• JOnAS is available under three different packagings. • The location and the JOnAS configuring policy has changed. • The location and the policy to deploy applications has changed.

JOnAS is still available as a "single ejb container" as before. Additionally, two new packagings as "J2EE server" are available:

• jonas3.1−tomcat4.1.24 package • jonas3.1−jetty4.2.9 package.

For these two new packagings, it is no longer necessary to set the environment variable CATALINA_HOME or JETTY_HOME. These packagings have JOnAS examples compiled for use with RMI.

The location and the policy for JOnAS configuration has changed:

• Configuration files are located under $JONAS_ROOT/conf (in previous versions they were located under $JONAS_ROOT/config). • The old policy used to search for configuration files (working directory, home directory, $JONAS_ROOT/config) is no longer used. The new policy is the following: If the environment variable JONAS_BASE is set, configuration files are searched for in $JONAS_BASE/conf, if not, under $JONAS_ROOT/con.

The location and the policy for deploying applications has changed:

• If the environment variable JONAS_BASE is set, the application to be deployed with jadmin or jonas admin are searched for in $JONAS_BASE/(ejbjars|apps|webapps), if not, under

JOnAS 3.1 to JOnAS 3.1.4 278 Howto: JOnAS Versions Migration Guide

$JONAS_ROOT/(ejbjars|apps|webapps).

JOnAS 2.6.4 to JOnAS 3.0

Application with entity beans CMP 1.1

The standard deployment descriptor must be updated for applications deployed in previous versions of JOnAS using entity beans that have container−managed persistence CMP 1.1. For such entity beans, a tag with value 1.x must be added. For example a deployment descriptor that looks like the following:

container fieldOne fieldTwo must be changed as follows:

container 1.x fieldOne fieldTwo

The EJB 2.0 specification states that the default value of the tag is 2.x.

JOnAS 2.6 to JOnAS 2.6.1

Installation procedure

Before using JOnAS when it is installed on a host, the ant install must be run in the JOnAS_ROOT directory to rebuild global libraries based on your environment (RMI/JEREMIE, web environment). This must be run again if the orb (i.e. from RMI to JEREMIE) is switched, or if the web environment (i.e. switching from CATALINA to JETTY) changes.

EJB container creation

It is still possible to create an EJB container from an EJB deployment descriptor identified by its xml file name in JOnAS version 2.6.1 (as required by JOnAS users with versions prior to JOnAS 2.6).

JOnAS 2.6.4 to JOnAS 3.0 279 Howto: JOnAS Versions Migration Guide

JOnAS 2.5 to JOnAS 2.6

Use of Make discontinued for building

The make tool is no longer used to build JOnAS and the JOnAS examples. Common makefiles previously used to build the JOnAS examples via make are no longer delivered in $JONAS_ROOT/gmk. Ant is the only build tool used in JOnAS 2.6.

Building with Ant 1.5

In JOnAS 2.6, the required version of Ant is 1.5 (instead of Ant 1.4). In addition, starting with this version, an ant task ejbjar for JOnAS is delivered in the JOnAS distribution. Refer to the JOnAS example to see how this new task is used.

New jonas command

A new jonas command is delivered that provides the capability to:

• start a JOnASserver, • stop a JOnASserver, • administrate a JOnASserver, • check the JOnASenvironment, • print the JOnASversion.

The EJBServer, JonasAdmin and CheckEnv commands are now deprecated. Refer to the JOnAS Commands Reference Guide in the JOnAS documentation for details.

EJB container creation

In previous versions of JOnAS, an EJB container could be created from an ejb−jar file or from an EJB deployment descriptor identified by its xml file name. In JOnAS version 2.6, an EJB container can only be created from an ejb−jar file. This means that an xml file name can no longer be specified as:

• a value of the jonas.service.ejb.descriptors jonas property, • or an argument of the −a option of the jonas admin command.

Tomcat 4.0.x Support

Tomcat version 4.0.1 is no longer supported. The current supported versions are Tomcat 4.0.3 and Tomcat 4.0.4.

JOnAS 2.5 to JOnAS 2.6 280 Howto: JOnAS Versions Migration Guide

Tomcat Service and Web Container Service

JOnAS 2.6 is a full−featured J2EE application server, thus Tomcat can be used with JOnAS as the Web container. This functionality is set up via the JOnAS service web. In earlier version of JOnAS, a service tomcat was provided. This service tomcat is now deprecated because it was not compliant with J2EE specification. Note that if the tomcat service was used previously and the web container service is now being used, the war files (and expanded directories) that were deployed here (they are now deployed in JONAS_ROOT/webapps) should be suppressed from the CATALINA_HOME/webapps directory.

Refer to the section "Integrating Tomcat and JOnAS" for details.

JOnAS 2.4.4 to JOnAS 2.5

Tomcat 4.0.x Support

JOnAS 2.5 supports two versions of Tomcat for the tomcat service: Tomcat 3.3.x (as in JOnAS 2.4.4) and Tomcat 4.0.x. The default support of JOnAS 2.4.4 is for Tomcat 3.3.x, therefore nothing needs to be changed if the tomcat service was being used with JOnAS 2.4.4. For Tomcat 4.0.x, the jonas.service.tomcat.class property of jonas.properties file to org.objectweb.jonas.tomcat.EmbeddedTomcatImpl40 must be set. Refer to the How to use Tomcat with JOnAS document for more details. trace.properties

Starting with JOnAS 2.5, the Objectweb Monolog logging API is used for JOnAS traces. The JOnAS traces configuration file JONAS_ROOT/conf/trace.properties has changed. Refer to the Configuration Guide in the JOnAS documentation for details.

JOnAS 2.4.3 to JOnAS 2.4.4

The main differences between these two versions are the two new services provided in JOnAS 2.4.4: registry and tomcat.

JOnAS 2.4.3 from JOnAS 2.4.4 − jonas.services − jonas.services jonas services jmx,security,jtm,dbm,resource, registry,tomcat,jmx,security,jtm,dbm, jms,ejb resource,jms,ejb − jonas.service.registry.class Registry service org.objectweb.jonas.registry.RegistryServiceImpl − configuration − jonas.service.registry.mode automatic − jonas.service.tomcat.class Tomcat service − org.objectweb.jonas.tomcat.EmbeddedTomcatImpl33 configuration − jonas.service.tomcat.args

JOnAS 2.5 to JOnAS 2.6 281 Howto: JOnAS Versions Migration Guide

JOnAS 2.3 to JOnAS 2.4

Introduction

This chapter is intended for JOnAS users migrating applications from JOnAS 2.3 to JOnAS 2.4 and later versions. This migration does not affect EJB components' files. However, two configuration files are slightly different: the jonas.properties file and the jonathan.xml file.

• jonas.properties: due to the new JOnAS architecture regarding services (refer to the advanced topic chapter on JOnAS services in the JOnAS documentation), the structure of the properties defined in this file has changed. It is necessary to upgrade a jonas.properties file written for a version 2.x (x<4) to reuse it for JOnAS 2.4. • jonathan.xml: for applications using the JEREMIE distribution mechanism, it is necessary to upgrade this configuration file, since JOnAS has embedded a new version of Jonathan.

Upgrading the jonas.properties file

JOnAS EJB servers are configured via the jonas.properties file. This configuration file may be located in three different places:

1. $JONAS_ROOT/config/jonas.properties 2. $HOME/jonas.properties: the home directory 3. ./jonas.properties: the directory from which the EJB server is launched.

An EJB server reads the three potential files in this order listed (1, 2, 3), each one possibly overwriting properties defined in a previous file. Therefore, existing jonas.properties files from previous JOnAS versions must be upgraded in order to retain the configuration settings, by making the following structural changes:

before JOnAS 2.4 from JOnAS 2.4 jonas services − jonas.services − (new) jmx,security,jtm,dbm,resource,jms,ejb JMX service − jonas.service.jmx.class − configuration org.objectweb.jonas.jmx.JmxServiceImpl JOnAS EJB service − jonas.service.ejb.class configuration − jonas.beans.descriptors ... org.objectweb.jonas.container.EJBServiceImpl (beans to be − jonas.service.ejb.descriptors ... loaded) JOnAS DBM − jonas.service.dbm.class service − jonas.datasources ... org.objectweb.jonas.dbm.DataBaseServiceImpl configuration − jonas.service.dbm.datasources ... JOnAS JTM − jonas.tm.remote false − jonas.service.jtm.class service − jonas.tm.timeout 60 org.objectweb.jonas.jtm.TransactionServiceImpl

JOnAS 2.3 to JOnAS 2.4 282 Howto: JOnAS Versions Migration Guide

configuration − jonas.service.jtm.remote false − jonas.service.jtm.timeout 60 JOnAS SECURITY − jonas.service.security.class − service org.objectweb.jonas.security.JonasSecurityServiceImpl configuration − jonas.service.jms.class − jonas.jms.mom org.objectweb.jonas.jms.JmsServiceImpl org.objectweb.jonas_jms.JmsAdminForJoram − jonas.service.jms.mom JOnAS JMS − jonas.jms.collocated true org.objectweb.jonas_jms.JmsAdminForJoram service − jonas.jms.url joram://localhost:16010 − jonas.service.jms.collocated true configuration − jonas.jms.threadpoolsize 10 − jonas.service.jms.url joram://localhost:16010 − jonas.jms.topics sampleTopic − jonas.service.ejb.mdbthreadpoolsize 10 − jonas.jms.queues ... − jonas.service.jms.topics sampleTopic − jonas.service.jms.queues ... JOnAS RESOURCE service − jonas.service.resource.class configuration − org.objectweb.jonas.resource.ResourceServiceImpl (Resource − jonas.service.resource.resources ... Adapters to be installed)

The main transformation rule is that most of the properties are now part of a JOnAS service. For each service XXX, the class property jonas.service.XXX.class containing the name of the service class (all these class properties are set in the $JONAS_ROOT/config/jonas.properties file) must be specified, and each additional property p related to the service is named jonas.service.XXX.p. The list of services to be launched with the server is specified in the jonas.services property. These services are EJB (in which are defined the beans to be loaded), JTM (in which are defined the transaction monitor properties), DBM (in which are defined the datasources), SECURITY, JMS (the messaging service), and JMX (a new service for management).

Upgrading the Jonathan configuration file

In the new version of Jonathan, the jonathan.prop has been replaced by jonathan.xml.

JOnAS 2.3 to JOnAS 2.4 283 Howto: Installing JOnAS from scratch

This guide provides instructions for installing JOnAS from scratch on Unix−compatible systems.

The content is organized into the following steps

1. J2SE SDK 1.4 installation 2. Ant 1.6 installation 3. Tomcat 5.5.x installation 4. Jetty 5.1.x installation 5. JOnAS installation 6. Setup

J2SE SDK 1.4 installation

Download the binary version of J2SE SDK 1.4 from the java Sun web site into the appropriate directory. Launch the executable file:

./j2sdk−1_−.bin for Unix ./j2sdk−1_−.sh for Linux j2sdk−1_−windows−i586.exe for Windows

Set the JAVA_HOME environment variable and update the path: export JAVA_HOME= PATH=$JAVA_HOME/bin:$PATH (on Windows: PATH=%JAVA_HOME%/bin;%PATH%)

Ant 1.6 installation

Download the binary version of Ant 1.6 from the Ant Apache web site. Untar or Unzip it into the appropriate directory: tar −jxvf apache−ant−1.6.x−bin.tar.bz2 (or unzip apache−ant−1.6.x−bin.zip)

Set the ANT_HOME environment variable and update the path: export ANT_HOME= PATH=$PATH;$ANT_HOME/bin (on Windows: PATH=%ANT_HOME%/bin;%PATH%)

Download bcel−5.x.tar.gz from the Jakarta web site and install bcel−5.x.jar in the directory $ANT_HOME/lib.

Howto: Installing JOnAS from scratch 284 Howto: Installing JOnAS from scratch

Tomcat 5.5.x installation

Download the binary version of Tomcat 5.5.x from the Jakarta Tomcat web site. Untar it into the appropriate directory: tar −xvf jakarta−tomcat−5.5.x.tar.gz

Set the CATALINA_HOME environment variable: export CATALINA_HOME= JONAS_BASE directory can be used as CATALINA_BASE: export CATALINA_BASE=$JONAS_BASE Configuration information for the Realm and users is provided at the Setup process.

Jetty 5.1.x installation

Download the binary version of Jetty 5.1.x from the Jetty web site. Untar it into the appropriate directory: tar −xvf jetty−5.1.x−all.tar.gz

Set the JETTY_HOME environment variable: export JETTY_HOME=

JOnAS installation

Download the binary version of JOnAS from the ObjectWeb web site. Choose a location for the JOnAS installation. Be aware that if you have already installed a previous version of JOnAS in this location, the new installation will overwrite existing files, thus customized configuration files may be lost. Therefore, it is prudent to save these files before starting the installation process. The installation process consists of untaring the downloaded file. Change to the directory in which JOnAS is to be installed and untar this file, using the tar −zxvf jonas.tgz command. After installing the JOnAS product, set the following environment variable: export JONAS_ROOT = PATH = $JONAS_ROOT/bin/unix:$PATH

Do an ant install in the JONAS_ROOT directory to unpack the jar files necessary to build jonas.jar and client.jar.

Tomcat 5.5.x installation 285 Howto: Installing JOnAS from scratch

Setup

Before using JOnAS, the following setup activities must be completed:

• Based on the data source being used, create a file .properties (templates are located in the directory $JONAS_ROOT/conf). Then, add the data source file name (without the extension .properties) to the jonas.properties file: jonas.service.dbm.datasource Add the JDBC driver in $JONAS_ROOT/lib/ext or in $JONAS_BASE/lib/ext directory. • JONAS_BASE directory can be used as CATALINA_BASE: export CATALINA_BASE=$JONAS_BASE so it will use the JOnAS realms. • If required, configure the Mail service (for PetStore or the example mailsb for instance). Two types of files that can be adapted to fit your installation are located in the directory $JONAS_ROOT/conf: MailSession1.properties and MailMimePartDS1.properties. Then, in the jonas.properties file, define the jonas.service.mail.factories property: jonas.service.mail.factories MailSession1,MailMimePartDS1

Compile the examples as follows: ant install in the directory $JONAS_ROOT/examples

Setup 286 Howto: Installing the packaging JOnAS with a web container (JOnAS/Tomcat or JOnAS/Jetty) from scratch

This guide provides instructions for installing JOnAS (with a web container already included) from scratch.

The content is organized into the following steps:

1. J2SE SDK 1.4 installation 2. ANT 1.6 installation 3. JOnAS/ Web Container installation 4. Setup 5. Starting JOnAS and running examples

J2SE SDK 1.4 installation

Download the binary version of a J2SE SDK 1.4 from the java Sun web site into the appropriate directory. Launch the executable file:

./j2sdk−1_−.bin for Unix ./j2sdk−1_−.sh for Linux j2sdk−1_−windows−i586.exe for Windows

Set the JAVA_HOME environment variable and update the path: export JAVA_HOME= PATH=$JAVA_HOME/bin:$PATH (on Windows : PATH=%JAVA_HOME%/bin;%PATH%)

ANT 1.6 installation

Download the binary version of Ant 1.6 from the Ant Apache web site. Untar or Unzip it into the appropriate directory: tar −jxvf apache−ant−1.6.1−bin.tar.bz2 (or unzip apache−ant−1.6.1−bin.zip)

Set the ANT_HOME environment variable and update the path: export ANT_HOME= PATH=$PATH;$ANT_HOME/bin (on Windows : PATH=%ANT_HOME%/bin;%PATH%)

Howto: Installing the packaging JOnAS with a web container (JOnAS/Tomcat or JOnAS/Jetty) from scratch287 Howto: Installing the packaging JOnAS with a web container (JOnAS/Tomcat or JOnAS/Jetty) from scratch

Download bcel−5.1.tar.gz from the Jakarta web site and install bcel−5.1.jar in the directory $ANT_HOME/lib.

JOnAS/Web Container installation

Download the binary version of JOnAS with Tomcat or Jetty from the ObjectWeb forge web site. Choose a location for the JOnAS installation. Be aware that if you have already installed a previous version of JOnAS in this location, the new installation will overwrite the existing files, thus customized configuration files may be lost. Therefore, it is prudent to save these files before starting the installation process. The installation process consists of untaring the downloaded file. Change to the directory in which JOnAS will be installed and untar this file, using the tar −zxvf jonas.tgz command. Note that this file can be opened with winzip on Windows. After installing the JOnAS product, set the following environment variable: export JONAS_ROOT = PATH = $JONAS_ROOT/bin/unix:$PATH (on Windows: PATH=%JONAS_ROOT%/bin/nt;%PATH%)

Setup

Before using JOnAS, complete the following setup activities:

• If a CATALINA_HOME or CATALINA_BASE or JETTY_HOME environment variable has already been set, it should be unset. JOnAS will set these variables, without requiring any modifications. • Based on the data source being used, create a file .properties (templates are located in the directory $JONAS_ROOT/conf). Then add the data source file name (without the extension .properties) to the jonas.properties file: jonas.service.dbm.datasource Add the JDBC driver in $JONAS_ROOT/lib/ext or in $JONAS_BASE/lib/ext directory. • If required, configure the Mail service (for PetStore or the example mailsb, for example). JOnAS provides two types of mail factories: javax.mail.Session and javax.mail.internet.MimePartDataSource. Two types of files that can be adapted to fit your installation are located in the directory $JONAS_ROOT/conf: MailSession1.properties and MailMimePartDS1.properties. Then, in the jonas.properties file, define the jonas.service.mail.factories property: jonas.service.mail.factories MailSession1,MailMimePartDS1

Starting JOnAS and running some examples

If the Setup step has not been completed as described, JOnAS may not work. Use the command jonas check to verify that the environment is correct.

If the environment is correct, JOnAS is ready to use.

JOnAS/Web Container installation 288 Howto: Installing the packaging JOnAS with a web container (JOnAS/Tomcat or JOnAS/Jetty) from scratch

Do a jonas start, then use a browser to go http://localhost:9000/. (Modify this url with the appropriate hostname.) From the root context in which JOnAS was deployed, you can execute the earsample, access the JOnAS administration application, as well as perform other functions.

JOnAS/Web Container installation 289 Howto: How to compile JOnAS

The content of this guide is the following:

1. Target Audience and Rationale 2. Getting the JOnAS Source 3. Recompiling JOnAS from the Source 4. Recompiling the package JOnAS/Jetty/Axis from the Source 5. Recompiling the package JOnAS/Tomcat/Axis from the Source

Target Audience and Rationale

The target audience for this chapter is the JOnAS user who wants to build a JOnAS version from the source code obtained from CVS.

Getting the JOnAS Source

CVS (Concurrent Version System) provides network−transparent source control for groups of developers. It runs on most UNIX systems and on Windows NT systems. Refer to http://www.cyclic.com for more information

CVS provides many read−only cvs commands, such as cvs status or cvs diff. However, because it is read only, an individual user cannot commit changes. To start working with CVS on JOnAS, make a checkout of the jonas module, using the following command:

cvs −d :pserver:[email protected]:/JOnAS login (hit enter key when prompted for password) cvs −d :pserver:[email protected]:/JOnAS co jonas

The CVSROOT variable can be set, instead of using the −d option.

Recompiling JOnAS from the Source

1. Download Ant from the Ant project site.

The build.xml file used for building JOnAS is located in the objectweb/jonas directory. 2. The JDK and ANT must have been successfully configured. (JAVA_HOME, ANT_HOME, PATH environment variables) 3. Set the following environment variables with the appropriate value: ♦ JONAS_ROOT: directory where jonas will be installed ♦ CATALINA_HOME: optional (mandatory for using the web container Tomcat) ♦ JETTY_HOME: optional (mandatory for using the web container Jetty) 4. Perform the following:

Howto: How to compile JOnAS 290 Howto: How to compile JOnAS

cd $OBJECTWEB_HOME/jonas and choose a target:

♦ ant install to install a JOnAS binary distribution version in the JONAS_ROOT directory. ♦ ant all to build JOnAS and keep the files in the output directory. ♦ ant archive to build a JOnAS archive (.tgz extension) that contains a binary version of JOnAS. The archive is built in the HOME directory.

Recompiling the package JOnAS/Jetty/Axis from the Source

1. Download Ant from the Ant project site.

The build.xml file used for building JOnAS is located in the objectweb/jonas directory. 2. Place the bcel.jar in the ANT_HOME/lib directory. It is available for downloading from the Jakarta web site. 3. The JDK and ANT must have been successfully configured. (JAVA_HOME, ANT_HOME, PATH environment variables) 4. Set the following environment variables with the appropriate value: ♦ JONAS_ROOT: directory where jonas will be installed ♦ JETTY_HOME: mandatory 5. Perform the following:

cd $OBJECTWEB_HOME/jonas and choose a target:

♦ ant install_jetty to install a JOnAS/Jetty/Axis binary distribution version into your JONAS_ROOT directory. ♦ ant all_jetty to build JOnAS/Jetty/Axis and keep the files in the output directory. ♦ ant archive_jetty to build a JOnAS/Jetty/Axis archive (.tgz extension) that contains a binary version of JOnAS/Jetty/Axis. The archive is built into the HOME directory.

Recompiling the package JOnAS/Tomcat/Axis from the Source

1. Download Ant from the Ant project site.

The build.xml file used for building JOnAS is located in the objectweb/jonas directory. 2. Place the bcel.jar in the ANT_HOME/lib directory. It is available for downloading from the Jakarta web site. 3. The JDK and ANT must have been successfully configured. (JAVA_HOME, ANT_HOME, PATH environment variables) 4. Set the following environment variables with the appropriate value: ♦ JONAS_ROOT: directory where jonas will be installed ♦ CATALINA_HOME: mandatory 5. Perform the following:

cd $OBJECTWEB_HOME/jonas and choose a target:

Recompiling the package JOnAS/Jetty/Axis from the Source 291 Howto: How to compile JOnAS

♦ ant install_tomcat to install a JOnAS/Tomcat/Axis binary distribution version into the JONAS_ROOT directory. ♦ ant all_tomcat to build JOnAS/Tomcat/Axis and keep the files in the output directory. ♦ ant archive_tomcat to build a JOnAs/Tomcat/Axis archive (.tgz extension) that contains a binary version of JOnAS/Tomcat/Axis. The archive is built in the HOME directory.

Recompiling the package JOnAS/Jetty/Axis from the Source 292 Howto: Clustering with JOnAS

By Georges Goebel and Marc Calvisi 03 March 2005 Version : 2.2

This guide describes how to configure Apache, Tomcat, and JOnAS to install a cluster.

This configuration uses the Apache/Tomcat plug−in mod_jk. This plug−in allows use of the Apache HTTP server in front of one or several Tomcat JSP/Servlet engines, and provides the capability of forwarding some of the HTTP requests (typically those concerning the dynamic pages, i.e. JSP and Servlet requests) to Tomcat instances.

It also uses the In−Memory−Session−Replication technique based on the group communication protocol JavaGroups to provide failover at servlet/JSP level.

For the load balancing at EJB level, a clustered JNDI called cmi is used.

This document describes one architecture with all the clustering functionalities available in JOnAS, the configuration of architectures integrating one of those functionalities, and other possible configurations.

The content of this guide is the following:

• Architecture • Products Installation ♦ Installing Apache ♦ Installing the package JOnAS/Tomcat • Load Balancing at web level with mod_jk or Enhydra Director ♦ Configuring the JK Module ♦ Configuring JOnAS ♦ Running a Web Application • Session Replication at web level ♦ Running your application • Load Balancing at EJB level ♦ CMI Principles ♦ CMI Configuration • Clustering databases with C−JDBC • Preview of a coming version • Used symbols • References

Architecture

The architecture with all the clustering functionality available in JOnAS is: Apache as the front−end HTTP server, JOnAS/Tomcat as J2EE Container, and a shared database.

Howto: Clustering with JOnAS 293 Howto: Clustering with JOnAS

At the Servlet / JSP level, the mod_jk plug−in provides Load Balancing / High Availability and the Tomcat−Replication module provides Failover. At the EJB level, the clustered JNDI cmi provides Load Balancing / High Availability. The database is shared by the JOnAS servers.

The versions assumed here are: Apache 2.0, Mod_jk 1.2.8, JOnAS 4.4..x/Tomcat 5.5.x package.

The architecture presented in this document is shown in the following illustration:

This architecture provides:

• Load balancing: Requests can be dispatched over a set of servers to distribute the load. This improves the

Howto: Clustering with JOnAS 294 Howto: Clustering with JOnAS

"scalability" by allowing more requests to be processed concurrently. • High Availability (HA): having several servers able to fulfill a request makes it possible to ensure that, if a server dies, the request can be sent to an available server (thus the load−balancing algorithm ensures that the server to which the request will be sent is available). Therefore, "Service Availability" is achieved. • Failover at Servlet / JSP Level: This feature ensures that, if one JSP/servlet server goes down, another server is able to transparently take over, i.e. the request will be switched to another server without service disruption. This means that it will not be necessary to start over, thus achieving Continuity.

However, failover at EJB level is not available. This means that no State Replication is provided. The mechanism to provide failover at EJB level is under development and will be available in a coming version of JOnAS.

Products Installation

This chapter provides information about installing Apache, mod_jk and JOnAS / Tomcat. The versions assumed here are: Apache 2.0, mod_jk 1.2.8 and the package JOnAS 4.4.x /Tomcat 5.0.x.

Installing Apache

Install Apache HTTP server from scratch :

1. Download Apache HTTP server source code from the Apache site. 2. Extract the source code. gunzip httpd−2_0_XX.tar.gz tar xvf httpd−2_0_XX.tar 3. Compile and Install. ./configure make make install

Note: A binary version is also available for installation at the Apache site.

Run and Stop Apache HTTP server:

1. Run Apache HTTP server. /usr/local/apache2/apachectl start 2. Stop Apache HTTP server. /usr/local/apache2/apachectl stop

For further information about installing Apache HTTP server please refer to Apache Site.

Products Installation 295 Howto: Clustering with JOnAS

Installing the package JOnAS / Tomcat

Refer to Installing JOnAS with a web container from scratch.

Load balancing at web level with mod_jk or Enhydra Director

This chapter describes how to configure Apache, Tomcat, mod_jk, and JOnAS to run the architecture shown in the following illustration:

This example uses mod_jk, but an alternative configuration using Enhydra Director is also possible. (see config)

Configuring the JK Module

JK module principles

Mod_jk is a plug−in that handles the communication between Apache and Tomcat. Mod_jk uses the concept of worker. A worker is a Tomcat instance that is running to perform servlet requests coming from the web server. Each worker is identified to the web server by the host on which it is located, the port where it listens, and the communication protocol used to exchange messages. In this configuration there is one worker for each Tomcat instance and one worker that will handle the load balancing (this is a specific worker with no host and no port number). All workers are defined in a file called worker.properties.

Note: this module can also be used for site partitioning.

Products Installation 296 Howto: Clustering with JOnAS

Install Mod_jk

The easiest way to obtain this plug−in is to download the binary from the Tomcat Site and place it in the directory libexec (for unix) or modules (for windows or Mandrake) of the Apache installation directory. For further installion information, refer to the Tomcat Site.

Configure Mod_jk

This depends on the distribution being used. Create a file tomcat_jk.conf and workers.properties in "$APACHE_HOME/conf/jk/".

• tomcat_jk.conf:

# Location of the worker file JkWorkersFile "$APACHE_HOME/conf/jk/workers.properties"

# Location of the log file JkLogFile "$APACHE_HOME/conf/jk/logs/mod_jk.log"

# Log level : debug, info, error or emerg JkLogLevel emerg

# Shared Memory Filename ( Only for Unix platform ) # required by loadbalancer JkShmFile $APACHE_HOME/conf/jk/logs/jk.shm

# Assign specific URL to Tomcat workers # A mount point from a context to a Tomcat worker JkMount /admin loadbalancer JkMount /admin/* loadbalancer JkMount /examples loadbalancer JkMount /examples/* loadbalancer

# A mount point to the status worker JkMount /jkmanager jkstatus JkMount /jkmanager/* jkstatus

# Enable the Jk manager access only from localhost > JkMount jkstatus Order deny,allow Deny from all Allow from 127.0.0.1

Load balancing at web level with mod_jk or Enhydra Director 297 Howto: Clustering with JOnAS

workers.properties This file should contain the list of workers first: worker.list= then the properties of each worker: worker..=

The following is an example of a worker.properties file:

# List the workers' names worker.list=loadbalancer,jkstatus

# −−−−−−−−−−−−−−−− # First worker # −−−−−−−−−−−−−−−− worker.worker1.port=9009 worker.worker1.host=server1 worker.worker1.type=ajp13 # Load balance factor worker.worker1.lbfactor=1 # Define preferred failover node for worker 1 #worker.worker1.redirect=worker2

# −−−−−−−−−−−−−−−− # Second worker # −−−−−−−−−−−−−−−− worker.worker2.port=9010 worker.worker2.host=server2 worker.worker2.type=ajp13 worker.worker2.lbfactor=1 # Disable worker2 for all requests except failover #worker.worker2.disabled=True

# −−−−−−−−−−−−−−−−−−−−−− # Load Balancer worker # −−−−−−−−−−−−−−−−−−−−−− worker.loadbalancer.type=lb worker.loadbalancer.balanced_workers=worker1,worker2 #Specifies whether requests with session's id should be routed to the same worker #worker.loadbalancer.sticky_session=false

# −−−−−−−−−−−−−−−−−−−−−− # jkstatus worker # −−−−−−−−−−−−−−−−−−−−−− worker.jkstatus.type=status

Load balancing at web level with mod_jk or Enhydra Director 298 Howto: Clustering with JOnAS

• Explanations: port: Port number of the remote Tomcat instance listening for defined protocol requests host: Host name or IP address of the backend Tomcat instance type: Type of the worker (can be one of ajp13, ajp14, jni, status or lb) The status worker makes it possible to manage loadbalancing parameters and status through a web interface. In the above example, use URL http://localhost/jkmanager lbfactor: An integer number indicating how much a worker has to work example: worker1.lbfactor = 2 worker2.lbfactor = 1 worker1 receives 2 times more requests than worker2 sticky_session Round robin where the mod_jk sends the request to a server. When session replication is : activated in JOnAS, the session will not be lost. redirect: worker name to use when the current worker is in error state disabled: True/False − default status of the current worker the redirect/disabled parameters makes it possible to define a failover configuration between 2 workers. In the above example, the lb redirects the requests to worker 2 if worker 1 is in error state. In other cases, worker 2 will not receive any requests, thus acting as a hot standby.

Note: Refer to the workers.properties and workers howto documentation.

Other possible mod_jk configurations (includes mod_jk2, mod_jk, migration mod_jk2 to mod_jk) Attention: mod_jk2 is deprecated.

Configure Apache

• httpd.conf

This depends on the distribution being used. This file should load the module mod_jk:

LoadModule jk_module modules/mod_jk.so (for windows) LoadModule jk_module libexec/mod_jk.so (for Unix) AddModule mod_jk.c Include $APACHE_HOME/conf/jk/tomcat_jk.conf

Configure Tomcat

To configure Tomcat, perform the following configuration steps for each Tomcat server.

1. Configure Tomcat for the connector AJP13. In the file conf/server.xml of the JOnAS installation directory, add (if not already there):

Load balancing at web level with mod_jk or Enhydra Director 299 Howto: Clustering with JOnAS

Explanations: port: The TCP port number on which this Connector will create a server socket and await incoming connections. minProcessor: The minimum number of processors to start at intialization time. If not specified, this attribute is set to 5. maxProcessor: The maximum number of processors allowed. acceptCount: The maximum queue length for incoming connection requests when all possible requests processing threads are in use. Any requests received when the queue is full will be refused. debug: The debugging detail level of log messages generated by this component, with higher numbers creating more detailed output. protocol: This attribute must be AJP/1.3 to use the AJP handler.

Note: Refer to the AJP Connector documentation. 2. Define the jvmRoute. In the file conf/server.xml of the JOnAS installation directory, add a unique route to the Catalina engine. Replace the line: with:

Explanations: name: Logical name of this Engine, used in log and error messages jvmRoute: Uniquely identifies the Tomcat server to the Apache server Name has been specified in the workers.properties defaultHost: Identifies the Host that will process requests directed to host names on this server debug: The level of debugging detail logged by this Engine Note: The jvmRoute name should be the same as the name of the associated worker defined in worker.properties. This will ensure the Session affinity. Refer to the Engine Container documentation.

Configuring JOnAS

In the JOnAS−specific deployment descriptor, add the tag shared for the entity beans involved and set it to true. When this flag is set to true, multiple instances of the same entity bean in different JOnAS servers can access a common database concurrently.

Load balancing at web level with mod_jk or Enhydra Director 300 Howto: Clustering with JOnAS

The following is an example of a deployment descriptor with the flag shared:

Id_1 clusterId_1 true jdbc_1 clusterIdentityEC name c_name number c_number findByNumber where c_number = ? findAll

Running a Web Application

The web application is now ready to run, be sure to follow the launching order:

1. Start the jonas servers: jonas start. 2. Restart Apache: /usr/local/apache2/bin/apachectl restart. 3. Use a browser to access the welcome page, usually index.html.

Note: It is mportant to adhere to the launching order; otherwise, it will not work correctly.

Load balancing at web level with mod_jk or Enhydra Director 301 Howto: Clustering with JOnAS

Session Replication at web level

The intent of this chapter is to configure Apache, Tomcat, and JOnAS to run the following architecture:

The term session replication is used when the current service state is being replicated across multiple application instances. Session replication occurs when the information stored in an HttpSession is replicated from, in this example, one servlet engine instance to another. This could be data such as items contained in a shopping cart or information being entered on an insurance application. Anything being stored in the session must be replicated for the service to failover without a disruption.

The solution chosen for achieving Session replication is called all−to−all replication. Tomcat uses a proprietary protocol based on TCP for the all−to−all replication.

The follow describes the steps for achieving Session replication with JOnAS.

• The mod_jk is used to illustrate the Session Replication. Therefore, first perform the configuration steps presented in the chapter Load Balancing at Web level with mod_jk. • On the JOnAS servers, open the /conf/server.xml file and configure the as described:

Session Replication at web level 302 Howto: Clustering with JOnAS

mcastAddr="228.0.0.4" mcastPort="45564" mcastFrequency="500" mcastDropTime="3000" debug = "9" />

Note: The multicast address and port must be identically configured for all JOnAS/Tomcat instances.

Running your Web Application

The web application is now ready to run in the cluster:

1. Start the JOnAS servers: jonas start. 2. Restart Apache: /usr/local/apache2/bin/apachectl restart. 3. Use a browser to access the welcome page, usually index.html.

Session Replication at web level 303 Howto: Clustering with JOnAS

Load Balancing at EJB level

The intent of this chapter is to configure JOnAS to run the following architecture:

CMI Principles

CMI is a new ORB used by JOnAS to provide clustering for load balancing and high availability. Several instances of JOnAS can be started together in a cluster to share their EJBs. It is possible to start the same EJB on each JOnAS, or to distribute their load. A URL referencing several JOnAS instances can be provided to the clients. At lookup time, a client randomly chooses one of the available servers to request the required bean. Each JOnAS instance has the knowledge (through Javagroups) of the distribution of the Beans in the cluster. An answer to a lookup is a special clustered stub, containing stubs to each instance known in the cluster. Each method call on the Home of the bean can be issued by the stub to a new instance, to balance the load on the cluster. The default algorithm used for load distribution is currently a weighted round robin.

CMI Configuration

In the case of EJB level clustering (CMI), the client may be either a fat Java client (e.g. a Swing application), or a Web application (i.e. Servlets/JSPs running within JOnAS). In the second case, the JOnAS server running the Web client should be configured in the same way as the other nodes of the cluster.

• In the build.properties of the application, set the protocol name to cmi before compilation: protocols.names=cmi • In the file carol.properties of each server (in the directory $JONAS_BASE/conf) and of a fat Java client, set

Load Balancing at EJB level 304 Howto: Clustering with JOnAS

the protocol to cmi: carol.protocols=cmi • In the file carol.properties of each server of the cluster, configure the multicast address, the group name, the round−robin weight factor, etc. The following is a configuration example: # java.naming.provider.url property carol.cmi.url=cmi://localhost:2002

# Multicast address used by the registries in the cluster carol.cmi.multicast.address=224.0.0.35:35467

# Groupname for Javagroups carol.cmi.multicast.groupname=G1

# Factor used for this server in weighted round robin algorithms carol.cmi.rr.factor=100 • For a fat Java client, specify the list of registries available in the carol.properties file: carol.cmi.url=cmi://server1:port1[,server2:port2...]

Note 1: The multicast address and group name must be the same for all JOnAS servers in the cluster.

Note 2: If Tomcat Replication associated to cmi is used, the multicast addresses of the two configurations must be different.

Clustering databases with C−JDBC

With C−JDBC it is possible to cluster databases. Refer to HowTo setup a C−JDBC Database.

Preview of a coming version

A solution that enables failover at EJB level is currently under development. This signifies state replication for stateful session beans and entity beans. This will enable the following architecture:

Clustering databases with C−JDBC 305 Howto: Clustering with JOnAS

Used symbols

A node (computer) that hosts one or more servers

A web container An ejb container

A JOnAS instance that A JOnAS instance that hosts a web container hosts an ejb container

A JOnAS instance that hosts a web container and an ejb container

An Apache server with the mod_jk module

Used symbols 306 Howto: Clustering with JOnAS

References

• Working with mod_jk • Tomcat workers Howto • Apache JServ Protocol version 1.3 (ajp13) • Apache − Tomcat HOWTO • Apache 1.3.23 + Tomcat 4.0.2 + Load Balancing • Tomcat 5 Clustering

References 307 Howto: Usage of AXIS in JOnAS

This guide describes basic Axis use within JOnAS. It assumes that the reader does not require any explanation about Axis−specific tasks (e.g., axis deployment with WSDD). Before deployment in Axis, the user must verify that the deploy.wsdd file matches the site machine configuration (jndiURL parameter in particular:).

This document describes two ways to make an EJB (stateless SB) available as a Web Service with JOnAS:

1. Axis runs in a unique Webapp, the stateless SB (Session Bean) is packaged in a separate ejb−jar (or even EAR). The intent of this approach is to make EJBs from differents packages that are already deployed accessible as Web Services via a single Axis Webapp deployment. The drawback is that Web Services are centralized in one Webapp only and the only way to distinguish between them for access is by the , not by the /. In addition, the ejb−jar files that contain the Web Services must be included in the Webapp. 2. The accessed EJB(s) are packaged with the Axis Webapp in an EAR archive. With this approach, the ejb−jar files do not have to be included in the Webapp WEB−INF/lib directory; different Applications that contain Web Services can be hosted, providing the capability of distinguishing between Web Services of different applications.

Libraries

JOnAS incorporates all the necessary libraries, including:

• JAX−R: Reference Implementation from Sun • JAX−M: Reference Implementation from Sun • JAX−P: Xerces XML parser (version 2.4.0) • AXIS: Soap implementation from Apache (with all dependent libs : jaxrpc.jar, ...)

(JAX−M and JAX−R are parts of the Web Services Development Pack from Sun.)

1. Unique Axis Webapp

Constraints:

• The EJBs exposed as WebServices must have remote interfaces. • The Axis Webapp must have in its WEB−INF/lib directory all the ejb−jar files containing Beans exposed as Web Services.

Usage:

• Deploy the ejb−jars or EARs containing Web Services. • Deploy the Axis Webapp (containing the ejb−jar files).

Howto: Usage of AXIS in JOnAS 308 Howto: Usage of AXIS in JOnAS

• Use the AdminClient tool to deploy the Web Services (with a .wsdd file). • Example: jclient org.apache.axis.client.AdminClient −hjonasServerHostname −p9000 deploy.wsdd

Example: Refer to the separate_axis example (in the $JONAS_ROOT/examples directory).

2. Embedded Axis Webapp

Constraints:

• The EJBs exposed as Web Services can have either local or remote interfaces. • The EAR must contain a Webapp including a web.xml with Axis servlet mapping.

Usage:

• Deploy the application archive (EAR) : • Use the AdminClient tool to deploy the webservices (with a .wsdd file) • Example: jclient org.apache.axis.client.AdminClient −lhttp://localhost:9000/hello/servlet/AxisServlet deploy.wsdd • Be careful to use a good URL to reach the AxisServlet.

Example: Refer to the embedded_axis example (in the $JONAS_ROOT/examples directory).

3. Tests

When everything is deployed and running, use the following URL to view the deployed Web Services: http://://servlet/AxisServlet This page will display a link for each Web Service with the WSDL file (automatically generated by Axis from the Java Interfaces). Use the following URL to access your Web Service (add ?WSDL for the associated WSDL file): http://://services/

A client class can now be run against the Web Service. Note that any language (with Web Services capabilities) can be used for the client (C#, Java, etc.).

Tools:

Use jclient to deploy your Web Services (in the Axis way): jclient org.apache.axis.client.AdminClient [OPTIONS] [OPTIONS] : −l: the location of the AxisServlet servlet (default : http://localhost:9000/axis/servlet/AxisServlet) −p: the port of the listening http daemon (default : 9000)

2. Embedded Axis Webapp 309 Howto: Usage of AXIS in JOnAS

−h: the hostname of the server running the JOnAS server (default : localhost)

2. Embedded Axis Webapp 310 Howto: Using WebSphere MQ JMS guide

This document explains how WebSphere MQ (formerly MQSeries) can be used as JMS provider within a JOnAS application server.

WebSphere MQ is the messaging platform developed by IBM. It provides Java and JMS interfaces. Documentation is located at http://www−3.ibm.com/software/integration/mqfamily/library/manualsa/.

This document was written after integration work done with JOnAS 3.3 and 3.3.1 and WebSphere MQ 5.3.

The content of this guide is the following:

• Architectural rules • Setting the JOnAS environment ♦ Configuring the "Registry" server ♦ Configuring the "EJB" server • Configuring WebSphere MQ • Starting the application • Limitations

Architectural rules

WebSphere MQ, contrary to JORAM or SwiftMQ, cannot run collocated with JOnAS. WebSphere MQ is an external software which must be independently administered and configured.

Administering WebSphere MQ consists of the following:

• Creating and configuring resources (such as queues) through the WebSphere MQ Explorer tool. • Creating the corresponding JMS objects (javax.jms.Queue, javax.jms.Topic, javax.jms.QueueConnectionFactory, etc.), and binding them to a registry.

The link between JOnAS and WebSphere MQ is established via the registry. WebSphere MQ JMS objects are bound to the JOnAS registry. JMS lookups will then return the WebSphere MQ JMS objects, and messaging will take place through these objects.

Given the complex configuration of WebSphere MQ JMS objects, it is not possible to create these objects from JOnAS. Therefore, during the starting phase, a JOnAS server expects that WebSphere MQ JMS objects have already been bound to the registry. Thus it is necessary to start an independent registry to which WebSphere MQ can bind its JMS objects, and which can also be used by the starting JOnAS server. The start−up sequence looks like the following:

1. Starting a registry. 2. Creating and binding WebSphere MQ JMS objects. 3. Launching the JOnAS server.

Howto: Using WebSphere MQ JMS guide 311 Howto: Using WebSphere MQ JMS guide

The following architecture is proposed:

• A JOnAS server (e.g., called "Registry") providing only a registry. • A JOnAS server (e.g., called "EJB") using the registry service of server "Registry." • A WebSphere MQ server running locally.

Setting the JOnAS Environment

The proposed architecture requires running two JOnAS server instances. For this, the following steps are proposed:

1. Create two base directories: e.g., JONAS_REGISTRY and JONAS_EJB. 2. Set the JONAS_BASE environment variable so that it points to the JONAS_REGISTRY directory. 3. In the $JONAS_ROOT directory, type: ant create_jonasbase. 4. Set the JONAS_BASE environment variable so that it points to the JONAS_EJB directory. 5. In the $JONAS_ROOT directory, type: ant create_jonasbase.

The JOnAS servers can now be configured independently.

Configuring the "Registry" server

The "Registry" server is the JOnAS server that will host the registry service. Its configuration files are in JONAS_REGISTRY/conf.

In the jonas.properties files, declare only the registry and jmx services: jonas.services registry,jmx

In the carol.properties file, declare the jeremie protocol: carol.protocols=jeremie

Its port can also be configured: carol.jeremie.url=jrmi://localhost:2000

Configuring the "EJB" server

The "EJB" server is the JOnAS server that will be used as the application server. Its configuration files are in JONAS_EJB/conf. Libraries must be added in JONAS_EJB/lib/ext.

In the jonas.properties files, set the registry service as remote: jonas.service.registry.mode remote

Setting the JOnAS Environment 312 Howto: Using WebSphere MQ JMS guide

... and the JMS service as WebSphere MQ: jonas.service.jms.mom org.objectweb.jonas_jms.JmsAdminForWSMQ

In the carol.properties file, declare the jeremie protocol and set the correct port: carol.protocols=jeremie carol.jeremie.url=jrmi://localhost:2000

In lib/ext, the following libraries must be added:

• com.ibm.mqjms.jar, including WebSphere MQ JMS classes. • com.ibm.mq.jar, also a WebSphere MQ library.

Configuring WebSphere MQ

WebSphere MQ JMS administration is documented in chapter 5 of the "WebSphere MQ Using Java" document.

The configuration file of the JMS administration tool must be edited so that the JOnAS registry is used for binding the JMS objects. This file is the JMSAdmin.config file located in WebSphereMQ's Java/bin directory. Set the factory and provider URL as follows:

INITIAL_CONTEXT_FACTORY=org.objectweb.jeremie.libs.services.registry. jndi.JRMIInitialContextFactory PROVIDER_URL=jrmi://localhost:2000

The JOnAS's client.jar library must also be added to the classpath for WebSphere MQ.

When starting, JOnAS expects JMS objects to have been created and bound to the registry. Those objects are connection factories, needed for connecting to WebSphere MQ destinations, and destinations.

JOnAS automatically tries to access the following factories:

• An XAConnectionFactory, bound with name "wsmqXACF". • An XAQueueConnectionFactory, bound with name "wsmqXAQCF". • An XATopicConnectionFactory, bound with name "wsmqXATCF". • A ConnectionFactory, bound with name "JCF". • A QueueConnectionFactory, bound with name "JQCF". • A TopicConnectionFactory, bound with name "JTCF".

If one of these objects cannot be found, JOnAS will print a message that looks like the following:

JmsAdminForWSMQ.start : WebSphere MQ XAConnectionFactory could not be retrieved from JNDI

Configuring WebSphere MQ 313 Howto: Using WebSphere MQ JMS guide

This does not prevent JOnAS from working. However, if there is no connection factory available, no JMS operations will be possible from JOnAS.

If destinations have been declared in the jonas.properties file, JOnAS will also expect to find them. For example, if the following destinations are declared: jonas.service.jms.topics sampleTopic jonas.service.jms.queues sampleQueue

The server expects to find the following JMS objects in the registry:

• A Queue, bound with name "sampleQueue". • A Topic, bound with name "sampleTopic".

If one of the declared destination cannot be retrieved, the following message appears and the server stops:

JOnAS error: org.objectweb.jonas.service.ServiceException : Cannot init/start service jms': org.objectweb.jonas.service.ServiceException : JMS Service Cannot create administered object: java.lang.Exception: WebSphere MQ Queue creation impossible from JOnAS

Contrary to connection factories, the JOnAS administration tool allows destinations to be created. Since it is not possible to create WebSphere MQ JMS objects from JOnAS, this will work only if the destinations are previously created and bound to the registry.

For example, if you want to create a queue named "myQueue" through the JonasAdmin tool, this will only work if:

• A queue has been created through the WebSphere MQ Explorer tool. • The corresponding JMS Queue has been created and bound to the registry with the name "myQueue".

To launch WebSphere MQ administration tool, type: JMSAdmin

The following prompt appears: InitCtx>

To create a QueueConnectionFactory and binding it with name "JQCF", type:

InitCtx> DEF QCF(JQCF)

More parameters can be entered (for example for specifying the queue manager).

To create a Queue that represents a WebSphere MQ queue named "myWSMQqueue", and to bind it with name "sampleQueue", type:

InitCtx> DEF Q(sampleQueue) QUEUE(myWSMQqueue)

Objects bound in the registry can be viewed by typing:

Configuring WebSphere MQ 314 Howto: Using WebSphere MQ JMS guide

InitCtx> DIS CTX

Starting the application

To start the registry server:

1. Clean the local CLASSPATH: set/export CLASSPATH="". 2. Set the JONAS_BASE variable so that it points to JONAS_REGISTRY. 3. Start the JOnAS server: jonas start −n Registry.

To administer WebSphere MQ:

1. In WebSphere MQ's Java/bin directory, launch the JMSAdmin tool: JMSAdmin. 2. Create the needed JMS objects.

To start the EJB server:

1. Clean the local CLASSPATH: set/export CLASSPATH="". 2. Set the JONAS_BASE variable so that it points to JONAS_EJB. 3. Start the JOnAS server: jonas start −n EJB.

To start an EJB client:

1. Add in the jclient classpath the ibm.com.mq.jar and ibm.com.mqjms.jar libraries. 2. Launch the client: jclient ...

Limitations

Using WebSphere MQ as JMS transport within JOnAS has some limitations, as compared with using JORAM or SwiftMQ.

First of all, WebSphere MQ is compliant with the old 1.0.2b JMS specifications. Code that is written following the JMS 1.1 latest spec (such as the jms samples provided with JOnAS) will not work with WebSphere MQ.

Depending on the WebSphere MQ distribution, JMS Publish/Subscribe may not be available. In this case, the message−driven bean samples provided with JOnAS will not work. For this reason, a specific sample is provided.

Finally, for an unknown reason, asynchronous consumption of messages (through message−driven beans) does not work in transactional mode. Further inquiry is needed to resolve this issue.

Starting the application 315 Howto: Web Service Interoperability between JOnAS and Weblogic

This guide describes the basic use of web services between JOnAS and Weblogic server. It assumes that the reader does not require any explanation about Axis−specific tasks (axis deployment with WSDD, etc.).

This document describes the following two aspects:

1. Access a web service deployed on JOnAS from an EJB deployed on Weblogic server. 2. Access a web service deployed on Weblogic server from an EJB deployed on JOnAS.

Libraries

JOnAS incorporates all the necessary libraries, including:

• JAX−R: Reference Implementation from Sun • JAX−M: Reference Implementation from Sun • JAX−P: Xerces XML parser (version 2.4.0) • AXIS: Soap implementation from Apache (with all dependent libs: jaxrpc.jar, etc.)

(JAX−M and JAX−R are parts of the Web Services Development Pack from Sun.)

Weblogic incorporates all the necessary libraries, including:

• All libraries for using webservice are contained in webserviceclient.jar.

Access a web service deployed on JOnAS from an EJB deployed on Weblogic server

Web Service Development on JOnAS

Also refer to the document How to use Axis with JOnAS, which describes how to develop and deploy web services on JOnAS.

EJB Creation on JOnAS

To create a web service based on an EJB, first create a stateless EJB. Then, create a web application (.war) or an application (.ear) with this EJB that will define a URL with access to the Web Service.

Howto: Web Service Interoperability between JOnAS and Weblogic 316 Howto: Web Service Interoperability between JOnAS and Weblogic

WebService Deployment Descriptor (WSDD)

This section describes the deployment descriptor of the web service. To deploy a web service based on an EJB, specify the various elements in the WSDD. This WSDD enables the web service to be mapped on an EJB, by specifying the different EJB classes used.

The various tags allow mapping of the web service on different java classes. If a web service uses a complex type, this complex type must be mapped with a java class. To do this, two tags can be used:

This maps the QName [someNameSpace]:[local] with the class my.class.

Where QName [someNamespace]:[local] is mapped with my.class. The serializer used is the class my.java.SerializerFactory, and the deserializer used is my.java.DeserializerFactory.

Access a web service deployed on JOnAS from an EJB deployed onWeblogic server 317 Howto: Web Service Interoperability between JOnAS and Weblogic

Web Service Deployment on JOnAS

First, deploy the web application or the application containing the EJB. Then, deploy the web service using the Axis client tool: jclient org.apache.axis.client.AdminClient −hjonasServerHostname −p9000 deploy.wsdd Note: from JOnAS 3.3, jclient no more include WebServices libraries in the CLASSPATH. So you have to manually add this jar in your CLASSPATH: export CLASSPATH=$CLASSPATH:$JONAS_ROOT/lib/webservices_axis.jar

The web service WSDL is accessible from the url: http://://?wsdl.

EJB proxy development for Weblogic Server

This EJB provides access to the web service deployed on JOnAS from Weblogic server.

Generation of web service client class

To access the web service, generate the client class using the ant task clientgen. For example:

This command creates four classes:

• Service implementation • Java Interface • Stub class • Service interface corresponding web service

The tool can also generate the java classes corresponding to future complex types of web service.

Build the EJB

Then, call the web service in the EJB proxy code using these generated classes. For example:

try { WSNAME_Impl tsl=new WSNAME_Impl(); // access web service impl EJB_endpoint tsp = tsl.getEJB_endpoint(); // access WS endpoint interface ComplexType tr=tsp.method(param); } catch (Exception e) { e.printStackTrace(System.err); };

Access a web service deployed on JOnAS from an EJB deployed onWeblogic server 318 Howto: Web Service Interoperability between JOnAS and Weblogic

Deploy the EJB on Weblogic Server

Deploy this EJB using the weblogic administration console.

Access a web service deployed on Weblogic server from an EJB deployed on JOnAS

Web Service Development for Weblogic Server

Creation of an application

To create a web service, first develop the corresponding EJB application. Compile the EJB classes and create a jar file. To create the EJB's container, apply the ant task wlappc to the jar file. For example:

THE ANT USED IS PROVIDED BY WEBLOGIC

WebService Deployment

Deploy the webservice using the Weblogic administration console, and deploy the corresponding application. The WSDL is accessible at http://:/webservice/web_services?WSDL.

EJB proxy development for JOnAS

This EJB provides access to the web service deployed on Weblogic from JOnAS.

Access a web service deployed on JOnAS from an EJB deployed onWeblogic server 319 Howto: Web Service Interoperability between JOnAS and Weblogic

Generation of web service client class

To access a web service, generate a client class using the axis tool WSDL2Java . This command creates four classes:

• ${WSNAME}Locator.java: Service implementation • ${WSNAME}Port.java: Java Interface • ${WSNAME}PortStub.java: Stub class • ${WSNAME}.java: Service interface corresponding web service

The tool also generates the java class corresponding to future complex types of web service.

Build the EJB

Then, use this generated class to call the web service in the EJB proxy code. For example:

try { WSNAMELocator tsl=new WSNAMELocator(); WSNAMEPort tsp = tsl.getWSNAMEPort(); ComplexType tr=tsp.method(param); ... } catch (Exception e) { e.printStackTrace(System.err); };

Deploy the EJB on JOnAS

Deploy the EJB using the JOnAS administration console or command.

Access a web service deployed on Weblogic server from an EJBdeployed on JOnAS 320 Howto: RMI−IIOP interoperability between JOnAS and Weblogic

This guide describes the basic interoperability between JOnAS and Weblogic Server using RMI−IIOP (the examples in this document assume that the Sun rmi/iiop of the JDK is used).

The content of this guide is the following:

1. Accessing an EJB deployed on JOnAS from an EJB deployed on Weblogic server using RMI−IIOP. 2. Accessing an EJB deployed on Weblogic Server from an EJB deployed on JOnAS using RMI−IIOP.

Accessing an EJB deployed on JOnAS from an EJB deployed on Weblogic server using RMI−IIOP

JOnAS Configuration

No modification to the EJB code is necessary. However, to deploy it for use with the iiop protocol, add the tag protocols and indicate iiop when creating the build.xml. For example:

If GenIC is being used for deployment, the −protocols option can be used. Note also that an EJB can be deployed for several protocols. For more details about configuring the communication protocol, refer to the JOnAS Configuration Guide.

For the JOnAS server to use RMI−IIOP, the JOnAS configuration requires modification. The iiop protocol must be selected in the file carol.properties. Refer also to the JOnAS Configuration Guide for details about configuring the communication protocol. This modification will allow an EJB to be created using the RMI−IIOP protocol.

EJB proxy on Weblogic

To call an EJB deployed on JOnAS that is accessible through RMI−IIOP, load the class com.sun.jndi.cosnaming.CNCtxFactory as the initial context factory. In addition, specify the JNDI url of the server name containing the EJB to call: "iiop://:port." For example:

Howto: RMI−IIOP interoperability between JOnAS and Weblogic 321 Howto: RMI−IIOP interoperability between JOnAS and Weblogic

try { Properties h = new Properties(); h.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory"); h.put(Context.PROVIDER_URL, "iiop://:"); ctx=new InitialContext(h); } catch (Exception e) { ... }

Then, the JOnAS EJB is accessed in the standard way.

Access an EJB deployed on Weblogic Server by an EJB deployed on JOnAS using RMI−IIOP

Weblogic Configuration

No modification to the EJB code is necessary. However, to deploy the EJB for use with the iiop protocol, add the element iiop="true" on the wlappc task when creating the build.xml. For example:

wlappc debug="${debug}" source="ejb.jar" iiop="true" classpath="${class.path}"

EJB proxy on JOnAS

To call an EJB deployed on Weblogic Server that is accessible through RMI−IIOP, specify the JNDI url of the server name containing the EJB to call. This url is of type: "iiop://:port." For example:

try { Properties h = new Properties(); h.put(Context.PROVIDER_URL, "iiop://:"); ctx=new InitialContext(h); } catch (Exception e) { ... }

Then, the EJB deployed on Weblogic server is accessed in the standard way.

Access an EJB deployed on Weblogic Server by an EJB deployed on JOnAS using RMI−IIOP 322 Howto: Interoperability between JOnAS and CORBA

This guide describes the basic interoperability between JOnAS and CORBA using RMI−IIOP (the examples in this document assume that the Sun rmi/iiop of the JDK 1.4 is used on the remote side, JOnAS using JacORB).

The content of this guide is the following:

1. Accessing an EJB deployed on JOnAS server by a CORBA client 2. Accessing a CORBA service by an EJB deployed on JOnAS server

Accessing an EJB deployed a on JOnAS server by a CORBA client

JOnAS Configuration

No modification to the EJB code is necessary. However, the EJB should be deployed for the iiop protocol (e.g. when the build.xml is created, add the tag "protocols" and specify "iiop"). For example:

If GenIC is used for deployment, the −protocols option can be used. Note also that an EJB can be deployed for several protocols. Refer to the JOnAS Configuration Guide for more details about configuring the communication protocol.

The JOnAS configuration must be modified for the JOnAS server to use RMI−IIOP. Choose the iiop protocol in the file carol.properties. Refer also to the JOnAS Configuration Guide for details about configuring the communication protocol. These modifications will make it possible to create an EJB using the RMI−IIOP protocol.

RMIC to create IDL files used by the Corba Client

To call an EJB deployed on JOnAS that is accessible through RMI−IIOP, use the rmic tool on the EJB Remote interface and EJB Home interface to create the idl files. Example: rmic −classpath $JONAS_ROOT/lib/common/j2ee/ejb.jar −idl package1.Hello

This action generates several idl files: package1/Hello.idl package1/HelloHome.idl java/io/FilterOutputStream.idl java/io/IOException.idl java/io/IOEx.idl

Howto: Interoperability between JOnAS and CORBA 323 Howto: Interoperability between JOnAS and CORBA

java/io/OutputStream.idl java/io/PrintStream.idl java/io/Writer.idl java/io/PrintWriter.idl java/lang/Exception.idl java/lang/Ex.idl java/lang/Object.idl java/lang/StackTraceElement.idl java/lang/ThrowableEx.idl java/lang/Throwable.idl javax/ejb/EJBHome.idl javax/ejb/EJBMetaData.idl javax/ejb/EJBObject.idl javax/ejb/Handle.idl javax/ejb/HomeHandle.idl javax/ejb/RemoveException.idl javax/ejb/RemoveEx.idl org/omg/boxedRMI/seq1_octet.idl org/omg/boxedRMI/seq1_wchar.idl org/javax/rmi/CORBA/ClassDesc.idl org/omg/boxedRMI/java/lang/seq1_StackTraceElement.idl

Copy these files to the directory in which CORBA client development is being done.

CORBA Client Development

1. idlj

Once idl files are generated, apply the idlj tool to build java files corresponding to the idl files (idlj = idl to java). To do this, apply the idlj tool to the Remote interface idl file and the Home interface idl file. Example: idlj −fclient −emitAll package1/Hello.idl

The idlj tool also generates bugged classes. Be sure to put the _read and _write method in comment in the class _Exception.java, CreateException.java, RemoveException.java.

Additionally, the class OutputStream.java, PrintStream.java, PrintWriter.java, Writer.java, FilterOuputStream.java must extend Serializable and then replace

((org.omg.CORBA_2_3.portable.OutputStream) ostream).write_value(value,id()); with

((org.omg.CORBA_2_3.portable.OutputStream) ostream).write_value((Serializable) value,id());

Accessing an EJB deployed a on JOnAS server by a CORBA client 324 Howto: Interoperability between JOnAS and CORBA

in the write method.

2. Client

Create the Corba client. import org.omg.CosNaming.*; import org.omg.CORBA.*; public class Client { public static void main(String args[]) { try { //Create and initialize the ORB ORB orb=ORB.init(args,null); //Get the root naming context org.omg.CORBA.Object objRef=orb.resolve_initial_references("NameService"); NamingContext ncRef= NamingContextHelper.narrow(objRef);

//Resolve the object reference in naming //make sure there are no spaces between "" NameComponent nc= new NameComponent("HelloHome",""); NameComponent path[] = {nc}; HelloHome tradeRef=HelloHomeHelper.narrow(ncRef.resolve(path));

//Call the Trader EJB and print results Hello hello=tradeRef.create(); String tr=hello.say(); System.out.println("Result = "+tr); } catch (Exception e) { System.out.println("ERROR / "+e); e.printStackTrace(System.out); } } }

3. Compilation

Compile the generated files.

WARNING: Compile the file corresponding to the client parts, the files Hello.java, HelloHome.java, _Exception.java, ..., and _*Stub.java, *Helper.java, *ValueFactory.java, *Operation.java (* represents the name of the interface).

Accessing a CORBA service by an EJB deployed on JOnAS server

Accessing a CORBA service by an EJB deployed on JOnAS server 325 Howto: Interoperability between JOnAS and CORBA

CORBA Service

Create the CORBA service.

Create the idl file corresponding to this service (e.g. the interface name, which is "Hello").

Generate the java file corresponding to the idl service with the idlj −fall Hello.idl tool.

Files used on this example can be found on the Sun tutorial web site available at http://java.sun.com/j2se/1.4.2/docs/guide/idl/tutorial/GSIDL.html.

Implement the java interface (in this example, the service will be bound with the name "Hello" in the server implementation).

Start the orb.

Start the CORBA service.

EJB on JOnAS

To call the CORBA service, generate the java file corresponding to the idl file.

For this, apply the idlj tool on the idl file corresponding to the CORBA service description:. idlj −fclient Hello.idl

Then, create an EJB.

For calling the CORBA service, use the InitialContext object (by running JOnAS in iiop mode).

Get the java object corresponding to the CORBA service with the environment.

Call the method on this object.

Example code: try {

// Get the reference on the object // Here the remote ORBd is running on localhost with the port 1050 // and the remote object is bound with the name "Hello". org.omg.CORBA.Object o = (org.omg.CORBA.Object) initialContext.lookup("corbaname:iiop:1.2@localhost:1050#Hello");

// Do the narrow Hello hello = (Hello) HelloHelper.narrow(o);

// Call the method

Accessing a CORBA service by an EJB deployed on JOnAS server 326 Howto: Interoperability between JOnAS and CORBA

System.out.println(hello.sayHello()); return hello.sayHello(); } catch (Exception e) { ... }

Accessing a CORBA service by an EJB deployed on JOnAS server 327 Howto: Migrate the New World Cruises application to JOnAS

This guide describes the modifications required for migrating the J2EE application New World Cruise to JOnAS server.

The content of this guide is the following:

1. JOnAS configuration 2. New World Cruise Application 3. SUN Web service 4. JOnAS Web service

JOnAS configuration

The first step is to configure the database used for this application. Copy the file .properties to the directory $JONAS_BASE/conf. Edit this file to complete the database connection.

Then, modify the JOnAS DBM Database service configurations in the file $JONAS_BASE/conf/jonas.properties, to specify the file containing the database connection.

New World Cruise Application

EJB modification code

To be EJB2.0−compliant, add the exceptions RemoveException and CreateException for EJB's methods ejbRemove and ejbCreate.

Additionally, the GlueBean class uses a local object in GlueBean constructor. However, it must use a remote object because it is a class calling an EJB. Therefore, modify the comment in this class with the following:

// If using the remote interface, the call would look like this cruiseManagerHome = (CruiseManagerHome) javax.rmi.PortableRemoteObject.narrow(result, CruiseManagerHome.class); // Using the local interface, the call looks like this //cruiseManagerHome = (CruiseManagerHome) result;

EJB's Deployment descriptor

There are three EJBs, thus there must be three ejb−jar.xml files that correspond to the EJB's deployment descriptors and three jonas−ejb−jar.xml files that correspond to the JOnAS deployment descriptors.

Howto: Migrate the New World Cruises application to JOnAS 328 Howto: Migrate the New World Cruises application to JOnAS

First, rename the files .ejbdd with .xml; these files contain the EJB deployment descriptors.

Create the three jonas−.xml files corresponding to the EJBs.

For the two entity Beans (Cruise and CruiseManager), describe the mapping between:

− the EJB name and jndi name (jndi name =ejb/),

− the jdbc and the table name,

− the EJB field and the table field, (the version of CMP is not specify in ejb−jar and JOnAS by default uses CMP1.1).

For the session Bean, describe the mapping between:

− the EJB name and jndi name (jndi name =ejb/)

Web Application

Create the jonas−web.xml that corresponds to the deployment descriptor of the New World Cruise application. Package the jonas−web.xml and the files under the directory Cruises/cruise_WebModule in the war file.

Build Application

Build the ear corresponding to the application.

This ear contains the three files corresponding to the three EJBs, as well as the web application.

SUN web service

Axis classes generation

To call a web service, first generate axis classes. The generated classes will allow a web service to be called using the static method.

For this step, download the file AirService.wsdl that corresponds to the SUN web service description or use the URL containing this file.

Then use the command: java org.apache.axis.wsdl.WSDL2java

This command generates four java files:

New World Cruise Application 329 Howto: Migrate the New World Cruises application to JOnAS

* AirService.java: the service interface.

* AirServiceLocator.java: the service implementation

* AirServiceServantInterface: the endpoint interface

* AirServiceServantInterfaceBindingStub.java: the stub class

To call the SUN web service, instantiate the service implementation. Then call the method getAirService() to get the end point, and call the appropriate method.

AirService airService=new AirServiceLocator(); AirServiceServantInterface interface=airService.getAirService(); Object result=interface.;

JSP files

The file Part2_site.zip contains the web application that uses the SUN web service.

It includes several jsp files that must be modified to use the axis classes.

As an example, make the following replacements in the index.jsp file:

// Get our port interface AirPack.AirClientGenClient.AirService service = new AirPack.AirClientGenClient.AirService_Impl(); AirPack.AirClientGenClient.AirServiceServantInterface port = service.getAirServiceServantInterfacePort();

// Get the stub and set it to save the HTTP log. AirPack.AirClientGenClient.AirServiceServantInterface_Stub stub = (AirPack.AirClientGenClient.AirServiceServantInterface_Stub) port; java.io.ByteArrayOutputStream httpLog = new java.io.ByteArrayOutputStream(); stub._setTransportFactory (new com.sun.xml.rpc.client.http.HttpClientTransportFactory(httpLog));

// Get the end point address and save it for the error page. String endPointAddress = (String) stub._getProperty(stub.ENDPOINT_ADDRESS_PROPERTY); request.setAttribute("ENDPOINT_ADDRESS_PROPERTY", endPointAddress); by

// Get our port interface AirService_pkg.AirService service = new AirService_pkg.AirServiceLocator(); AirService_pkg.AirServiceServantInterface port = service.getAirServiceServantInterfacePort();

SUN web service 330 Howto: Migrate the New World Cruises application to JOnAS

Additionally, the Exception throw new com.sun.xml.rpc.client.ClientTransportException(null, new Object[] {e}); is replaced by

throw new Exception(e);.

Web Application

Finally, create the web application (jonas−web.xml) and reuse the web.xml that is in Part2_site.zip. Then, build the web application, which contains:

META−INF/ META−INF/MANIFEST.MF WEB−INF/ WEB−INF/jonas−web.xml WEB−INF/lib/ WEB−INF/lib/CruiseManager.jar WEB−INF/classes/ WEB−INF/classes/AirService_pkg/ WEB−INF/classes/AirService_pkg/AirServiceServantInterface.class WEB−INF/classes/AirService_pkg/AirServiceServantInterfaceBindingStub.class WEB−INF/classes/AirService_pkg/AirService.class WEB−INF/classes/AirService_pkg/AirServiceLocator.class PalmTree.jpg aboutus.jsp air_icon.gif airbook.jsp airclient.jsp airdates.jsp airdone.jsp airlist.jsp clear.gif crubook.jsp crudone.jsp cruise_icon.gif cruises.jsp flights.jsp index.jsp nwcl_banner.gif nwcl_banner_a.gif nwcl_styles.css WEB−INF/web.xml

JOnAS web service

SUN web service 331 Howto: Migrate the New World Cruises application to JOnAS

Deployment

This web service uses the EJB stateless CruiseManager. To deploy this web service, create the web service deployment descriptor:

To deploy this web service, first deploy the web application axis.war and the EJB corresponding to the web service (CruiseManager.jar).

Then, deploy the web service using the axis client:

jclient org.apache.axis.client.AdminClient −lhttp://localhost://servlet/AxisServlet

JOnAS web service 332 Howto: Migrate the New World Cruises application to JOnAS

Axis classes generation

To call a web service, first generate axis classes. The generated classes will allow a web service to be called using the static method.

For this step, download the file AirService.wsdl corresponding to the SUN web service description or use the URL containing this file.

The use of the command is as follows: java org.apache.axis.wsdl.WSDL2java

This command generates four java files:

* CruiseManagerService.java: the service interface

* CruiseManagerServiceLocator.java: the service implementation

* CruiseManager.java: the endpoint interface

* AirServiceSoapBindingStub.java: the stub class

To call the JOnAS web service, instantiate the service implementation. Then, call the method getAirService() to get the end point interface, and call the appropriate method.

AirService_JOnAS.Client.CruiseManagerService cms= new AirService_JOnAS.Client.CruiseManagerServiceLocator();

AirService_JOnAS.Client.CruiseManager cmi=cms.getAirService();

Object result=cmi.;

JSP files

To access the JOnAS web service, copy the jsp files contained in the EJB's web application (Cruises/cruise_WebModule).

The JOnAS web service call must replace the call for each EJB.

Web Application

Finally, create the web application: the jonas−web.xml. Then, build the web application, which contains:

META−INF/ META−INF/MANIFEST.MF WEB−INF/

JOnAS web service 333 Howto: Migrate the New World Cruises application to JOnAS

WEB−INF/jonas−web.xml WEB−INF/lib/ WEB−INF/lib/CruiseManager.jar WEB−INF/classes/ WEB−INF/classes/AirService_pkg/ WEB−INF/classes/AirService_JOnAS/Client/CruiseManagerService.class WEB−INF/classes/AirService_JOnAS/Client/AirServiceSoapBindingStub.class WEB−INF/classes/AirService_JOnAS/Client/CruiseManager.class WEB−INF/classes/AirService_JOnAS/Client/CruiseManagerServiceLocator/AirServiceLocator.class PalmTree.jpg aboutus.jsp air_icon.gif airbook.jsp airclient.jsp airdates.jsp airdone.jsp airlist.jsp clear.gif crubook.jsp crudone.jsp cruise_icon.gif cruises.jsp flights.jsp index.jsp nwcl_banner.gif nwcl_banner_a.gif nwcl_styles.css WEB−INF/web.xml

JOnAS web service 334 Howto: Execute JOnAS as a WIN32 Service

This document describes the procedures necessary to run JOnAS as a system service on Microsoft Windows platforms. This applies starting from JOnAS 3.3.2.

Instructions

This procedure uses ANT targets that are introduced in JOnAS 3.3.2. The procedure also uses the Java Service Wrapper open source project which must be downloaded and installed separately.

Download and install Java Service Wrapper

1. Download Java Service Wrapper version 3.0.5 or later, and unzip the package to a directory in the local filesystem. 2. Set WRAPPER_HOME environment variable to the root directory for Java Service Wrapper.

For example, if the package for Wrapper version 3.0.5 is unzipped into c:\jsw, then SET WRAPPER_HOME=c:\jsw\wrapper_win32_3.0.5 create_win32service

Before JOnAS can be run as a WIN32 service, it is necessary to copy Java Service Wrapper executable files to the %JONAS_BASE% directory and create a Java Service Wrapper configuration file. Prior to executing the steps in this section, it is necessary to create a JONAS_BASE directory as described in the JOnAS Configuration Guide.

1. Verify that JONAS_BASE and WRAPPER_HOME environment variables are set. 2. Set %JONAS_ROOT% as the current directory. 3. Execute ant [−Djonas.name=] create_win32service.

The −Djonas.name= parameter is optional. If not specified, the default server name is 'jonas'.

NOTE: it is necessary to execute create_win32service to regenerate wrapper configuration files whenever the JOnAS configuration is modified. Refer to the Modify JOnAS Configuration section for more information. install_win32service

After the %JONAS_BASE% directory has been updated for use with Java Service Wrapper, JOnAS can be installed as a WIN32 service using the install_win32service ant target. Prior to installing the configuration as a WIN32 service, the configuration can be tested as a standard console application. Refer to the Testing configuration section for more information. The following steps will install the service.

Howto: Execute JOnAS as a WIN32 Service 335 Howto: Execute JOnAS as a WIN32 Service

1. Verify that JONAS_BASE and WRAPPER_HOME environment variables are set. 2. Set %JONAS_ROOT% as the current directory. 3. Execute ant install_win32service.

By default, the service is configured to start automatically each time Windows starts. If the administrator would prefer to start the service manually, modify the wrapper.ntservice.starttype parameter in the %JONAS_BASE%\conf\wrapper.conf file. Set the value as described in the comments found in the wrapper.conf file. uninstall_win32service

When it is no longer desirable to run JOnAS as a Windows service, the service can be uninstalled using the uninstall_win32service ant target.

1. Verify that JONAS_BASE and WRAPPER_HOME environment variables are set. 2. Set %JONAS_ROOT% as the current directory. 3. Verify that the service has been stopped. 4. Execute ant uninstall_win32service. start JOnAS service

To start the JOnAS service, open the Service Control Manager (Control Panel Services) window, select the JOnAS service and start the service.

By default, JOnAS will be started automatically each time Windows is started. After installing the service, it can be started manually to avoid the need to reboot Windows. stop JOnAS service

To stop the JOnAS service, open the Service Control Manager window, select the JOnAS service and stop the service.

Files managed by create_win32service

The create_win32service ant target copies executable files from the Java Service Wrapper installation directory and generates a configuration file in the %JONAS_BASE% directory. The following files are managed by the create_win32service ant target.

• bin\Wrapper.exe • bin\server.bat • bin\InstallService−NT.bat • bin\UninstallService−NT.bat

• lib\wrapper.jar • lib\wrapper.dll

Instructions 336 Howto: Execute JOnAS as a WIN32 Service

• conf\wrapper.conf • conf\wrapper_ext.conf

NOTE: wrapper_ext.conf contains Java Service Wrapper configuration properties specific to the JOnAS service. This file is generated by the create_win32service ant target. Any changes made to this file will be lost when the create_win32service target is executed.

Modify JOnAS Configuration

Most of the JOnAS configuration is specified using property and XML files in the %JONAS_BASE%\conf directory. Changes to the files located in the %JONAS_BASE%\conf directory take effect the next time the service is started. It is only necessary to stop the service and restart the service for the changes to take effect.

In addition to the files located in the conf directory, JOnAS configuration is affected by the contents of %JONAS_ROOT%\bin\nt\config_env.bat, and by the CLASSPATH and JAVA_OPTS environment variables. If changes are made to config_env.bat, or to the CLASSPATH or JAVA_OPTS environment variables, it is necessary to update the Java Service Wrapper configuration files.

1. Using the Windows Service Control Manager, stop the JOnAS service. 2. Update the Java Service Wrapper configuration. Refer to the create_win32service section for details. 3. Test the updated configuration. Refer to the Testing configuration section for more information. 4. Using the Windows Service Control Manager, start the JOnAS service.

Testing configuration

After the Java Service Wrapper configuration files have been generated, it is possible to test the configuration in a console window before installing the configuration as a WIN32 service.

1. Verify that JONAS_BASE environment variable is set. 2. Execute %JONAS_BASE%\bin\server.

The Java Service Wrapper will start as a console application and load JOnAS using the configuration generated by the create_win32service ant target.

Enter CTRL−C to terminate JOnAS. After pressing Ctrl−C, the Java Service Wrapper displays the following messages to the execution report, and/or log file. wrapper | CTRL−C trapped. Shutting down. jvm 1 | 2003−12−02 15:25:20,578 : AbsJWebContainerServiceImpl.unRegisterWar : War /G:/w32svc/webapps/autoload/ctxroot.war no longer available jvm 1 | Stopping service Tomcat−JOnAS. wrapper | JVM exited unexpectedly while stopping the application. wrapper | <−− Wrapper Stopped.

Modify JOnAS Configuration 337 Howto: Getting Started with WebServices and JOnAS 3.X

• WebServices and J2EE • Early Integration of Axis in JOnAS 3.X series • How to use WebServices ♦ Endpoint Creation ◊ Exposing Stateless Session Bean ◊ Exposing Simple class (JAX−RPC Class) ♦ Client Creation ◊ WSDL Knowledge ◊ no WSDL Knowledge ♦ Using Axis WSDD Configuration file ◊ Service ◊ Parameter ◊ Optional ◊ Mappings ◊ Deployment ♦ Deploy Created Web Service

WebServices and J2EE

WebServices are fully integrated in J2EE 1.4 compliant Application Servers. Web services technologies can be seen as another communication protocol used to interoperate heterogeneous systems. Web services are based on the SOAP protocol. The SOAP messages can be transported with various transport mode (JMS, HTTP, mail, ...) but the focus of this document is the HTTP transport (because Web Services for J2EE v1.1 use only SOAP/HTTP).

Early Integration of Axis in JOnAS 3.X series

JOnAS hosts Apache Axis starting with version 3.0. This means that the user no longer must add Axis jars in its webapp. To use an Axis class (AdminClient, WSDL2Java, ...) from the command line, simply use the jclient script in place of the common java executable (jclient will create the appropriate classpath).

How to use WebServices

Howto: Getting Started with WebServices and JOnAS 3.X 338 Howto: Getting Started with WebServices and JOnAS 3.X

Endpoint Creation

When it is desirable to expose some business methods as web services, a servlet container such as Tomcat or Jetty should be used to hold the Axis servlet where the SOAP messages of clients will ultimately end up. To configure Axis, the developer must write a .wsdd file holding Axis−specific configuration parameters. This can be in one of two different forms: a simple wsdd containing only information about the web services the developer wants to expose (see an example here), or a complete wsdd containing exposed web services information AND Axis base configuration (see an example here). The first form is preferred for development purposes, because the developer can easily change configuration values and submit them again to the Axis servlet (the Axis servlet will merge the current WEB−INF/server−config.wsdd with this new configuration file). It is usually named deploy.wsdd (its location is user−defined). The second form is appropriate when used in a production environment where configuration changes are minor (ultimately, both forms results in the same Axis wsdd file). It MUST be named server−config.wsdd and located in the WEB−INF directory of the servlet.

Exposing Stateless Session Bean

1. Create a simple WebApp containing minimal Axis information, such as a WEB−INF/web.xml declaring the Axis servlet and servlet mapping (sample here). 2. Create a wsdd file (use the form you prefer)

• add a service with a unique name (used to find the appropriate service to invoke from the URL String) • set a provider for the service: java:EJB

3. Add mandatory parameters for EJB exposition:

• beanJndiName: name used in Axis lookup. (a java:comp/env name can be set here if ejb−ref or ejb−local−ref is added in the web−app descriptor) • homeInterfaceName: EJB Home interface fully−qualified class name • remoteInterfaceName: EJB Remote interface fully−qualified class name • localHomeInterfaceName: Local EJB Home interface fully−qualified class name • localInterfaceName: Local EJB interface fully−qualified class name • allowedMethods: comma−separated list of method names accessible via the web service

The developer must set AT LEAST local OR remote interface names. If local AND remote interfaces are specified, Axis will use the REMOTE interface, even if the interfaces are different.

Refer to "Using Axis WSDD configuration files" for more information.

Exposing Simple class (JAX−RPC class)

JAX−RPC classes are normal classes with no particular inheritance requirements, exposed as a web service. 1. Add the Axis servlet declaration in the web−app descriptor (sample here) with a servlet mapping. 2. Create a wsdd file (use whichever form you prefer).

How to use WebServices 339 Howto: Getting Started with WebServices and JOnAS 3.X

• add a service with a unique name (used to find the appropriate service to invoke from the URL String) • set a provider for the service: java:RPC

3. Add mandatory parameters to expose JAX−RPC classes:

• className: the fully−qualified name of the class to be exposed as a web service. • allowedMethods: comma−separated list of method names accessible via the web service.

Client Creation

Creation of a web services client is heavily based on WSDL knowledge, even if it is not mandatory.

WSDL Knowledge

WSDL is the easiest way to create a web service client. All that is necessary is to generate the files needed to access the web service, then compile them and add them into your component archive. This can be done from the command line using the org.apache.axis.wsdl.WSDL2Java tool. example: jclient org.apache.axis.wsdl.WSDL2Java −−output −−NStoPkg = The −−NStoPkg option is used to place generated classes in a convenient package according to the namespace of the WSDL Definition and the namespace(s) of the XML Schema(s).

Axis provides an Ant Task for automated build:

code :

import path.to.your.generated.classes.*; [...] service = new Locator();

How to use WebServices 340 Howto: Getting Started with WebServices and JOnAS 3.X

port = service.get(); result = port.();

No WSDL Knowledge

When the client does not have the WSDL of the service to access, the developer must use Service agnostic interfaces. With Axis, you must instantiate an org.apache.axis.client.Service class (implementation of javax.xml.rpc.Service), create a javax.xml.rpc.Call instance from the Service, configure it manually, and invoke the Call.

Refer to the following example:

import javax.xml.rpc.Call; import javax.xml.rpc.Service; import javax.xml.namespace.QName; import javax.xml.rpc.encoding.TypeMappingRegistry; import javax.xml.rpc.encoding.TypeMapping; import org.apache.axis.encoding.ser.BeanSerializerFactory; import org.apache.axis.encoding.ser.BeanDeserializerFactory; [...] // create a Service instance (other constructor usable, see the doc) Service service = new org.apache.axis.client.Service();

// configure mappings if web service use Complex types // first get the mapping registry instance TypeMappingRegistry tmr = service.getTypeMappingRegistry();

// create a QName representing the fully qualified name of the // XML type to serialize/deserialize (namespace+locapart pair) QName xmlType = new QName("namespace−of−complex−type", "complex−type−name");

// get a TypeMapping (default for axis is SOAP encoding TypeMapping) TypeMapping tm = tmr.getDefaultTypeMapping();

// register the XML type with a Java class by specifying // Serializer/Deserializer factories to use. tm.register(your.java.Type.class, xmlType, new BeanSerializerFactory(your.java.Type.class, xmlType), new BeanDeserializerFactory(your.java.Type.class, xmlType));

// get a Call instance from the Service

How to use WebServices 341 Howto: Getting Started with WebServices and JOnAS 3.X

// specify port to use and operation name to be invoked // see the doc for other createCall methods usage Call call = service.createCall(new QName("port−name", new QName("operation−name")));

// where is the web service ? call.setTargetEndpointAddress("url−address−of−the−endpoint");

// now, we can invoke the web service with its parameters String result = call.invoke(new Object[] {"Hello, World!"}); Using Axis WSDD Configuration file

This section covers the basic functionality of wsdd configuration files. For detailed information refer to the Axis User Guide and Reference Guide.

Service

is the tag used to declare a web service. Attributes:

• name: unique name of the service • provider: bridge used by Axis to invoke different objects: EJB, normal classes, CORBA objects, ... • style: defines global format of the SOAP Message • use: SOAP encoded message or message enclosing classic XML Elements (depends on the style attributes)

Provider possible values: java:EJB (used to expose EJB Stateless Session Bean), java:RPC (used to expose Simple classes), java:MSG (used to ???) Style possible values: document, rpc With RPC, SOAP Messages must have an element named as the operation to be invoked as their first soap:body element. With Document, SOAP Messages cannot have a first element with the operation name. Use possible values: encoded, literal With encoded, SOAP refs can be used in the SOAP Message. With literal, no SOAP refs can be used in the SOAP Message. Note: a SOAP ref is similar to a pointer in an XML SOAP Message: an Element is defined with an ID that can be referenced from somewhere else in the SOAP Message.

Refer to the following snippet of Axis javadoc for style and use combinations:

Description of the different styles style=rpc, use=encoded

How to use WebServices 342 Howto: Getting Started with WebServices and JOnAS 3.X

First element of the SOAP body is the operation. The operation contains elements describing the parameters, which are serialized as encoded (possibly multi−ref)

... ...

style=RPC, use=literal First element of the SOAP body is the operation. The operation contains elements describing the parameters, which are serialized as encoded (no multi−ref)\

... ...

style=document, use=literal Elements of the SOAP body are the names of the parameters (there is no wrapper operation...no multi−ref)

... ...

style=wrapped Special case of DOCLIT where there is only one parameter and it has the same qname as the operation. In such cases, there is no actual type with the name...the elements are treated as parameters to the operation.

... ...

style=document, use=encoded There is no enclosing operation name element, but the parameters are encoded using SOAP encoding This mode is not (well?) supported by Axis.

How to use WebServices 343 Howto: Getting Started with WebServices and JOnAS 3.X

Parameter

is the tag used to configure a service. It is basically a name−value pair. Attributes:

• name: parameter name (key) • value: parameter value

Common parameter:

• className: fully−qualified class name of service class (only used for provider RPC & MSG) • beanJndiName: name used in Axis lookup. (a java:comp/env name can be set here if ejb−ref or ejb−local−ref is added in the web−app descriptor) • localHomeInterfaceName: Local EJB Home interface fully−qualified class name • localInterfaceName: Local EJB interface fully−qualified class name • homeInterfaceName: EJB Home interface fully−qualified class name • remoteInterfaceName: Remote EJB interface fully−qualified class name • allowedMethods: comma−separated list of method names accessible via the web service (for all providers) • scope: scope of the web service (Request: create a new Object for each request, Session: keep the same Object for a given Session ID, Application: keep the same Object for the entire application run)

Optional

Other options can be specified to a service without parameter tags:

• wsdlFile: specify the static wsdl file to be served when a ?WSDL request comes to the endpoint • namespace: specify the web service namespace (override default namespace created from URL location of the service). The developer can handle the namespace value with this tag.

By default a namespace will look like like the following: http://ws.servlets.wssample.objectweb.org (for a JAX−RPC class named org.objectweb.wssample.servlets.ws). The developer can write a more concise namespace as desired: for example, urn:JaxRpcWsSample.

♦ operation: used to describe the operation exposed (avoid Axis to use reflection to discover the service interface). Refer to the Axis doc for details.

Mappings

Mappings in WSDD can be set at different levels: mappings commons for all services are direct children of the deployment tag, and mappings specific for a given web service are children of the service tag. The developer can specify the type of mappings in the WSDD configuration file: beanMapping and typeMapping. beanMapping is a write shortcut for typeMapping when mapping bean types. Mapping is used to register a java type, with an XML QName and a serializer/deserializer pair.

How to use WebServices 344 Howto: Getting Started with WebServices and JOnAS 3.X

examples: Notes : type value must be a qname in java prefixed namespace (java:XXX.YYY) by default encodingStyle is set to http://schemas.xmlsoap.org/soap/encoding/ (SOAP 1.1 Encoding) When Arrays of Complex Types are serialized and/or deserailized the factories to be used are : org.apache.axis.encoding.ser.ArraySerializerFactory org.apache.axis.encoding.ser.ArrayDeserializerFactory

Notes : serializer and deserializer are automatically set to BeanSerializerFactory and BeanDeserializerFactory encodingStyle is automatically set to null (cannot be overridden)

Deployment

A deployment Element is the root Element of any Axis WSDD file. It holds commons namespace definitions.

A normal deployment Element looks like the following:

Deploy Created Web Service

Deployment of the web service in JOnAS depends on the form of the wsdd file: For full wsdd configuration files, simply add the wsdd file in the WEB−INF/ directory of the servlet with the name server−config.wsdd. Deployment will be performed automatically by Axis when the first client attempts to connect. For simpler wsdd configuration files, deploy the web−app (or ear) into JOnAS (normal process). Then, use the Axis AdminClient tool: jclient org.apache.axis.client.AdminClient −lhttp://://

How to use WebServices 345 Howto: Getting Started with WebServices and JOnAS 3.X

.wsdd

Apache−Axis org.apache.axis.transport.http.AxisHTTPSessionListener AxisServlet Apache−Axis Servlet org.apache.axis.transport.http.AxisServlet AxisServlet /servlet/AxisServlet AxisServlet /services/* 5 wsdl text/xml xsd text/xml index.html index.jsp index.jws

How to use WebServices 346 Howto: Distributed Message Beans in JOnAS 4.x

JOnAS release 4.1 dramatically simplifies the use of a distributed JORAM platform from within JOnAS servers. For example, such a configuration allows a bean hosted by JOnAS instance "A" to send messages on a JORAM queue, to which a MDB hosted by JOnAS instance "B" listens.

This advancement is due to the following:

• JORAM Resource Adapter allows a much more refined configuration than the JMS service did. • JORAM provides a distributed JNDI server which allows JOnAS instances to share information.

Before going through this chapter, it is highly recommended that the JORAM Resource Adapter configuration guide be reviewed.

Scenario and general architecture

The following scenario and general settings are proposed:

• Two instances of JOnAS are run (JOnAS "A" and JOnAS "B"). JOnAS A hosts a simple bean providing a method for sending a message on a JORAM queue. JOnAS B hosts a message−driven bean listening on the same JORAM queue. • Each JOnAS instance has a dedicated collocated JORAM server: server "s0" for JOnAS A, "s1" for JOnAS B. Those two servers are aware of each other. • The queue is hosted by JORAM server s1. • An additional JNDI service is provided by the JORAM servers that will be used for storing the shared information (basically, the queue's naming reference).

Common configuration

The JORAM servers are part of the same JORAM platform described by the following a3servers.xml configuration file:

Howto: Distributed Message Beans in JOnAS 4.x 347 Howto: Distributed Message Beans in JOnAS 4.x

This configuration describes a platform made up of two servers, "s0" and "s1", hosted by machines "hostA" and "hostB", listening on ports 16010, providing a distributed JNDI service (more info on JORAM's JNDI may be found here).

Each JOnAS server must hold a copy of this file in its conf/ directory. In its jonas.properties file, each must declare the joram_for_jonas_ra.rar as a resource to be deployed (and each should remove jms from its list of services).

Specific configuration

JOnAS A embeds JORAM server s0. The jonas−ra.xml descriptor packaged in the joram_for_jonas_ra.rar archive file must provide the following information:

HostName hostA

The other default settings do not need to be changed.

JOnAS B embedds JORAM server s1. The jonas−ra.xml descriptor packaged in the joram_for_jonas_ra.rar archive file must provide the following properties values:

ServerId 1 ServerName s1 HostName hostB

The other default settings do not need to be changed.

Specific configuration 348 Howto: Distributed Message Beans in JOnAS 4.x

The shared queue will be hosted by JORAM server s1. It must then be declared in the JOnAS B's joramAdmin.xml file as follows:

The scn:comp/ prefix is a standard way to specify which JNDI provider should be used. In this case, the shared queue will be bound to JORAM's distributed JNDI server, and may be retrieved from both JOnAS A and JOnAS B. To provide this mechanism, both JOnAS servers must provide access to a standard jndi.properties file. For JOnAS A, the file looks as follows, and should be placed in its conf/ directory: java.naming.factory.url.pkgs org.objectweb.jonas.naming:fr.dyade.aaa.jndi2 scn.naming.factory.host hostA scn.naming.factory.port 16400

For JOnAS B, the file looks as follows, and should be placed in the right conf/ directory: java.naming.factory.url.pkgs org.objectweb.jonas.naming:fr.dyade.aaa.jndi2 scn.naming.factory.host hostB scn.naming.factory.port 16400

And now, the beans!

The simple bean on JOnAS A needs to connect to its local JORAM server and access the remote queue. The following is an example of consistent resource definitions in the deployment descriptors:

Standard deployment descriptor:

jms/factory javax.jms.ConnectionFactory Container jms/sharedQueue javax.jms.Queue

Specific deployment descriptor:

jms/factory CF jms/sharedQueue

And now, the beans! 349 Howto: Distributed Message Beans in JOnAS 4.x

scn:comp/sharedQueue

The ConnectionFactory is retrieved from the local JNDI registry of the bean. However, the Queue is retrieved from the distributed JORAM JNDI server, because its name starts with the scn:comp/ prefix. It is the same queue to which the message−driven bean on JOnAS B listens. For doing so, its activation properties should be set as follows:

destination scn:comp/sharedQueue destinationType javax.jms.Queue

And now, the beans! 350 Howto: install jUDDI server on JOnAS

• I. UDDI Servers • II. jUDDI Overview • III. How to Find the Latest Version • IV. Install Steps ♦ A. Create the jUDDI webapp ◊ 1. Compilation ◊ 2. Customization ♦ B. Create the Database ◊ 1. Retrieve the sql scripts for your database ◊ 2. Setup the database ♦ C. Configure JOnAS Datasource ♦ D. Deploy and test jUDDI • V. Links

I. UDDI Server

A UDDI server is basically a web services registry. Providers of web services put technical information (such as the WSDL definition used to access the web service, description, ...) inside these registries. Web service Consumers can browse these registries to choose a web services that fits their needs.

II. jUDDI Overview jUDDI (pronounced "Judy") is a Java−based implementation of the Universal Description, Discovery, and Integration (UDDI) specification (v2.0) for Web services. It is implemented as a pure Java web application and can be deployed with a minimum amount of work inside JOnAS.

Refer to http://ws.apache.org/juddi for more information.

III. How to Find the Latest Version

JOnAS already includes jUDDI as a preconfigured webapp (CVS Snapshot (21−Jan−2005) + 2 patchs). For the latest jUDDI version, refer to http://ws.apache.org/juddi.

Howto: install jUDDI server on JOnAS 351 Howto: install jUDDI server on JOnAS

IV. Install Steps jUDDI requires a minimum of configuration steps to be successfully deployed inside JOnAS. If you use the JOnAS provided juddi.war, skip step 1., "Compilation," and start with Step 2., "Customization."

A. Create the juddi webapp

1. Compilation

Go to the directory where the jUDDI sources are located (JUDDI_HOME). Customize the JUDDI_HOME/conf/juddi.properties configuration file.

# jUDDI Proxy Properties (used by RegistryProxy) juddi.proxy.adminURL = http://localhost:9000/juddi/admin juddi.proxy.inquiryURL = http://localhost:9000/juddi/inquiry juddi.proxy.publishURL = http://localhost:9000/juddi/publish juddi.proxy.transportClass = org.apache.juddi.proxy.AxisTransport juddi.proxy.securityProvider = com.sun.net.ssl.internal.ssl.Provider juddi.proxy.protocolHandler = com.sun.net.ssl.internal.www.protocol

# jUDDI HTTP Proxy Properties juddi.httpProxySet = true juddi.httpProxyHost = proxy.viens.net juddi.httpProxyPort = 8000 juddi.httpProxyUserName = sviens juddi.httpProxyPassword = password

Launch compilation with ant war. That will produce a juddi.war inside JUDDI_HOME/build/ directory.

2. Customization

JOnAS provide a lightweight juddi.war file from which all unnecessary libraries have been removed.

The original juddi.war (created from JUDDI_HOME) has a lot of libraries inside its WEB−INF/lib that are already provided by JOnAS. These files, listed below, can safely be removed:

• axis.jar • commons−discovery.jar • commons−logging.jar • jaxrpc.jar • saaj.jar • wsdl4j.jar

IV. Install Steps 352 Howto: install jUDDI server on JOnAS

By default, jUDDI includes a jonas−web.xml descriptor (in JUDDI_HOME/conf). This descriptor specifies the jndi name of the DataSource used in jUDDI; its default value is: jdbc/juddiDB. This value will be used in the .properties of JOnAS.

B. Create the Database

1. Retrieve the SQL scripts for your database jUDDI comes with SQL files for many databases (MySQL, DB2, HSQL, Sybase, PostgreSQL, Oracle, TotalXML, JDataStore). SQL Scripts are different for each version of jUDDI:

• MySQL ♦ create_database.sql insert_publishers.sql • DB2 ♦ create_database.sql insert_publishers.sql • HSQL ♦ create_database.sql insert_publishers.sql • Sybase ♦ create_database.sql insert_publishers.sql • PostgreSQL ♦ create_database.sql insert_publishers.sql • Oracle ♦ create_database.sql insert_publishers.sql • TotalXML ♦ create_database.sql insert_publishers.sql • JDataStore ♦ create_database.sql insert_publishers.sql

2. Setup the database

Execute the given scripts (table creation, tmodels insertions and publishers insertions). Then, a publisher (the user who has the rights to modify the UDDI server) must be added manually. This is currently the only way to add a publisher for jUDDI.

C. Configure JOnAS Datasource

As jUDDI uses a DataSource to connect to the database, JOnAS must be configured to create this DataSource. This is done as usual in JOnAS: Create a file (named ws−juddi−datasource.properties for example) and populate it with the appropriate database configuration information.

IV. Install Steps 353 Howto: install jUDDI server on JOnAS

###################### MySQL DataSource configuration example # datasource.name is the jndi−name set in the jonas−web.xml datasource.name jdbc/juddiDB # datasource.url is the URL where database can be accessed datasource.url jdbc:mysql://localhost/db_juddi # datasource.classname is the JDBC Driver classname datasource.classname com.mysql.Driver # Set here DB username and password datasource.username XXX datasource.password XXX # available values : rdb,rdb.postgres,rdb.oracle,rdb.oracle8,rdb.mckoi,rdb.mysql datasource.mapper rdb.mysql

Add the datasource properties filename (without the suffix .properties) in your ($JONAS_BASE|$JONAS_ROOT)/conf/jonas.properties jonas.service.dbm.datasources .

D. Deploy and test jUDDI

Deploy jUDDI on JOnAS with a command line similar to the following: $ jonas admin −a ~/juddi/juddi.war

The following output should display: 11:53:57,984 : RegistryServlet.init : jUDDI Starting: Initializing resources and subsystems. 11:53:58,282 : AbsJWebContainerServiceImpl.registerWar : War /home/sauthieg/sandboxes/ws−projects/ws−juddi/build/juddi.war available at the context /juddi.

Open your web browser and go to the URL http://localhost:9000/juddi/happyjuddi.jsp to confirm that the jUDDI setup is successful.

If setup is successful, then your UDDI server can be accessed through any UDDIv2.0−compliant browser. inquiryURL = http://localhost:9000/juddi/inquiry publishURL = http://localhost:9000/juddi/publish

V. Links

• UDDI web site (http://uddi.org/) • jUDDI web site (http://ws.apache.org/juddi) • UDDI4J Java implementation (http://www.uddi4j.org)

IV. Install Steps 354 Howto: install jUDDI server on JOnAS

• IBM UDDI Test Registry (https://uddi.ibm.com/testregistry/registry.html) • Microsoft UDDI Test Registry (http://uddi.microsoft.com/) • methods web Site (http://www.xmethods.net/) • UDDI Browser (http://www.uddibrowser.org/)

IV. Install Steps 355 Howto: JOnAS and JORAM: Distributed Message Beans

A How−To Document for JOnAS version 3.3

By Rob Jellinghaus, robj at nimblefish dot com 16 February 2004

We are developing an enterprise application which uses messaging to provide scalable data processing. Our application includes the following components:

• A servlet which provides a web user interface. • Stateless session beans which implement our core business logic. • Message beans which implement data processing tasks.

We wanted to arrange the application as follows:

• A front−end server, server1, running the servlet and session beans. • Two back−end servers, server2 and server3, running the message beans.

We wanted to use JOnAS and JORAM as the platform for developing this system. We encountered a number of configuration challenges in developing the prototype. This document describes those challenges and provides solutions.

We constructed our system using JOnAS 3.3.1 −− many of these issues will be addressed and simplified in future JOnAS and JORAM releases. In the meantime we hope this document is helpful.

Thanks to Frederic Maistre (frederic.maistre at objectweb dot org) without whom we would never have figured it out!

JOnAS and JORAM: Configuration Basics

The JORAM runtime by default is launched collocated with the JOnAS server (see http://jonas.objectweb.org/current/doc/PG_JmsGuide.html#Running). However, in this configuration the JORAM lifetime is bound to the JOnAS lifetime. If the local JOnAS process terminates, so will the local JORAM. For reliability it is preferable to separate the JOnAS and JORAM processes, moreover given that a collocated JORAM server is by default non persistent.

The simplest configuration to separate JOnAS and JORAM, once they are non−collocated, is to create one JORAM instance on one machine in the system, and to couple all JOnAS instances to that one JORAM. However, this also is failure−prone as if that one JORAM instance quits, all the JOnAS instances will lose their connection −− and will not afterwards reconnect!

Hence, the preferred solution is to have one JOnAS instance and one JORAM instance on each participating server. The JORAM instances must then be configured to communicate with each other. Then each JOnAS instance must

Howto: JOnAS and JORAM: Distributed Message Beans 356 Howto: JOnAS and JORAM: Distributed Message Beans

be configured to connect to its local JORAM instance. This provides the greatest degree of recoverability, given that the JORAM instances are run in persistent mode (mode providing message persistence and thus, guarantee of delivery even in case of a server crash).

JORAM Topics and JOnAS Administration

The default configuration done by JOnAS is to create all queues and topics specified in jonas.properties when the JOnAS server starts up. In a multi−server configuration, this is not desired. JORAM topics and queues are hosted on one specific JORAM server. Other JORAM servers wishing to use those topics and queues must use JNDI lookups to retrieve remote instances of those topics and queues, and must bind them locally.

Moreover, each JORAM server must be launched with knowledge of its identity in the system, and each JOnAS instance must take different configuration actions depending on its role in the system. Hence, the configuration of each machine must be customized.

Finally, the default permissions for running a distributed JORAM environment are not compatible with JOnAS:

• Each JORAM instance must be launched with a "root" administration user whose password is "root", or the local JOnAS instance will not be able to establish its JORAM connection. • Each JORAM instance must have an "anonymous" user created for it, or JOnAS message beans (which are anonymous users as far as JORAM is concerned) will be unable to receive messages. The JOnAS instance which creates the application's topics and queues will create its anonymous user as part of the topic and queue creation. The other JOnAS instances will not have any anonymous user, and must have one created for them. • Each JORAM topic or queue used by the system must have its permissions set to allow all users to read and write to it, or the JOnAS anonymous message beans will be unauthorized to receive messages.

All this configuration is not part of JOnAS's or JORAM'S default administration logic. So it must be performed specifically by application code, which must perform this lookup and binding before any application JOnAS message operations can succeed.

The Solution

All these challenges can be addressed with the following set of configurations and supporting mechanisms.

Many variations are possible; we provide just the configuration that we have proved to work for us. It is possible to rearrange the configuration significantly (to have some queues hosted on some machines, and other queues on other machines; to use a distributed JNDI lookup rather than a centralized one; etc.), but we have not as yet done so.

Throughout we use our server1,server2, and server3 names as concrete examples of the configuration.

1. JORAM must be configured for distributed operation, roughly as described in section 3.2 of the JORAM adminstration guide (http://joram.objectweb.org/current/doc/joram3_7_ADMIN.pdf). 2. Each separate server machine must have its own instance of JORAM and its own instance of JOnAS. 3. Each JOnAS instance must be configured (via jonas.properties) to connect to its local JORAM.

JORAM Topics and JOnAS Administration 357 Howto: JOnAS and JORAM: Distributed Message Beans

4. The "server 0" JORAM instance must be launched first, followed by its associated JOnAS. This JOnAS instance, and this JOnAS instance only, is configured to create the queues and topics used in the system. 5. The second and third servers must then launch their JORAM and JOnAS (first JORAM, then JOnAS, then on to the next server) instances. 6. Each JOnAS server must implement a custom service (see http://jonas.objectweb.org/current/doc/Services.html) which, on startup, will perform the appropriate configuration for that specific server. We name this service the JoramDistributionService and provide source code for it below. This performs all the customized configuration described in the permission section above. 7. Since the configuration varies from server to server, the JoramDistributionService must read configuration information from a local configuration file. We place this file in the $JONAS_BASE/conf directory, from where it is loadable as a classloader resource. (This is a little−known JOnAS technique and it is not clear that it is guaranteed to work! −− if you know otherwise, please let me know: robj at nimblefish dot com.)

Summing up, the total configuration elements involved are:

1. $JONAS_BASE/conf/a3servers.xml −− the JORAM configuration file which specifies the distributed JORAM configuration. This file is identical on all participating servers. 2. $JONAS_ROOT/bin//JmsServer −− the JORAM launch script which starts up JORAM. This varies on each server, the startup arguments (i.e. "0 ./s0", "1 ./s1", etc.) initialize the local JORAM instance with knowledge of its role in the JORAM configuration. 3. $JONAS_BASE/conf/jonas.properties −− the JOnAS configuration file. On all servers, this is extended to include the initialization of the JoramDistributionService, which must happen after the initialization of the "jms" service, but before the initialization of all deployment services (since application deployment involves subscribing message beans to queues and topics, which must be bound before the deployment can succeed). On the server which is to host the application's topics and queues, the jonas.properties file also specifies those topics and queues; on all other servers, no topics or queues are created. Finally, the jms service is configured as non−collocated on all servers, though customized to use the local JORAM instance's URL. 4. $JONAS_BASE/conf/joramdist.properties−− the configuration file for the JoramDistributionService. This contains properties specifying the local JORAM's port number, which server is hosting the application's topics and queues, and which topics and queues should be bound locally.

Note that the JoramDistributionService must be built and installed in $JONAS_BASE before JOnAS itself can be launched!

The Full Configuration

Here we provide examples of the relevant portions of the configuration for our system, to provide completely specific detail. Our application uses only queues (at the moment). a3servers.xml:

The Full Configuration 358 Howto: JOnAS and JORAM: Distributed Message Beans

JmsServer: (the "export" is required for the script to work with the bash shell which we use on our Linux machines) server 1: export JAVA_OPTS="$JAVA_OPTS −DTransaction=fr.dyade.aaa.util.ATransaction −Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient −cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 0 ./s0 "$@" server 2: export JAVA_OPTS="$JAVA_OPTS −DTransaction=fr.dyade.aaa.util.ATransaction −Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient −cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 1 ./s1 "$@" server 3: export JAVA_OPTS="$JAVA_OPTS −DTransaction=fr.dyade.aaa.util.ATransaction −Dfr.dyade.aaa.agent.A3CONF_DIR=$JONAS_BASE/conf" jclient −cp "$JONAS_ROOT/lib/jonas.jar:$JONAS_ROOT/lib/common/xml/xerces.jar" fr.dyade.aaa.agent.AgentServer 2 ./s2 "$@"

The Transaction argument specifies the persistence mode of the started JORAM server. The fr.dyade.aaa.util.ATransaction mode provides persistence, when starting a server (server "s1" for example) a persistence root (./s1) is created. If re−starting s1 after a crash, the info contained in this directory is used to retrieve the pre−crash state. For starting a bright new platform, all servers' persistence roots should be removed.

For starting non persistent servers (which provided better performances), the mode to set is fr.dyade.aaa.util.NullTransaction. jonas.properties: (we show only the portions which vary from the default)

The Full Configuration 359 Howto: JOnAS and JORAM: Distributed Message Beans

server 1: jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16010 jonas.service.jms.topics jonas.service.jms.queues ApplicationQueue1,ApplicationQueue2,ApplicationQueue3 server 2: jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16011 #jonas.service.jms.topics #jonas.service.jms.queues server 3: jonas.services registry,jmx,jtm,dbm,security,jms,resource,joramdist,ejb,web,ear jonas.service.joramdist.class com.nimblefish.sdk.jonas.JoramDistributionService jonas.service.jms.collocated false jonas.service.jms.url joram://localhost:16012 #jonas.service.jms.topics #jonas.service.jms.queues joramdist.properties: server 1: joram.createanonuser=false joram.port=16010 joram.bindremotehost=localhost joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue,InternalWorkQueue,ExternalWorkQueue server 2: joram.createanonuser=true joram.port=16011 joram.bindremotehost=server1 joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue,InternalWorkQueue,ExternalWorkQueue server 3: joram.createanonuser=true joram.port=16012 joram.bindremotehost=server1

The Full Configuration 360 Howto: JOnAS and JORAM: Distributed Message Beans

joram.bindremotequeues=WorkManagerQueue,StatusManagerQueue,InternalWorkQueue,ExternalWorkQueue

It is a bit odd that server 1, which hosts the queues locally, has a "bindremotequeues" property. In practice, the code which reads "bindremotequeues" actually also sets permissions, and then only binds the queues locally if bindremotehost is other than "localhost". In other words, the code was originally written before the permissions issue came to light, and so the names are a bit stale :−) The JoramDistributionService

The only remaining piece to describe is the JoramDistributionService itself. Here it is. As mentioned, we do not use topics in our system; adding code to handle topic permission and binding would be completely straightforward.

package com.nimblefish.sdk.jonas; import org.objectweb.jonas.service.Service; import org.objectweb.jonas.service.ServiceException; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import java.util.Enumeration; import java.util.Properties; import java.io.InputStream; import java.io.IOException; import javax.naming.Context; import javax.jms.Destination; import fr.dyade.aaa.joram.admin.AdminItf;

/** * This class implements the JOnAS service interface and performs * JOnAS−startup−time configuration actions relating to distributed JORAM servers. * * It uses a properties file named "joramdist.properties" to configure its activity; * this configuration file must be in $JONAS_BASE/conf (which is part of the JOnAS * classpath, and hence is reachable as a classloader resource from this class.) * This of course can be changed at your discretion. * * See http://jonas.objectweb.org/current/doc/Services.html * * Written by Rob Jellinghaus (robj at nimblefish dot com) on 11 February 2004. * Thanks very much to Frederic Maistre (frederic.maistre at objectweb dot org) * for his indispensable and voluminous help. * This file is hereby placed into the public domain for use by JOnAS users at their * sole discretion; please include this comment text in your uses of this code. */ public class JoramDistributionService implements Service { private static Log log = LogFactory.getLog(JoramDistributionService.class);

private boolean createAnonUser = false; private int joramPort = −1;

The JoramDistributionService 361 Howto: JOnAS and JORAM: Distributed Message Beans

private int joramInstance = −1; private String joramBindHost = null; private String[] joramBindQueues = null;

public void init(Context context) throws ServiceException { log.info("JoramDistributionService initializing"); try { InputStream propStream = JoramDistributionService.class.getClassLoader() .getResourceAsStream("joramdist.properties"); Properties joramProperties = null; joramProperties = new Properties(); joramProperties.load(propStream); Enumeration props2 = joramProperties.propertyNames(); while (props2.hasMoreElements()) { String s = (String) props2.nextElement(); log.info("joram.properties property: "+s+": "+joramProperties.getProperty(s)); }

if (joramProperties.containsKey("joram.createanonuser") && joramProperties.get("joram.createanonuser").equals("true")) { createAnonUser = true; }

if (joramProperties.containsKey("joram.port")) { joramPort = Integer.parseInt(joramProperties.getProperty("joram.port")); }

if (joramProperties.containsKey("joram.instance")) { joramInstance = Integer.parseInt(joramProperties.getProperty("joram.instance")); }

if (joramProperties.containsKey("joram.bindremotehost")) { joramBindHost = joramProperties.getProperty("joram.bindremotehost"); }

if (joramProperties.containsKey("joram.bindremotequeues")) { joramBindQueues = joramProperties.getProperty("joram.bindremotequeues").split(","); }

} catch (IOException e) { throw new ServiceException("Could not initialize JoramDistributionService", e); }

}

public void start() throws ServiceException { started = true;

if (joramPort == −1 && joramInstance == −1) { log.info("No joram.port and/or joram.instance defined; performing no JORAM configuration."); return; }

try {

The JoramDistributionService 362 Howto: JOnAS and JORAM: Distributed Message Beans

if (joramPort != −1) { AdminItf admin = new fr.dyade.aaa.joram.admin.AdminImpl(); admin.connect("localhost", joramPort, "root", "root", 60);

if (createAnonUser) { log.info("Creating JORAM anonymous user on localhost:"+joramPort+ " for instance "+joramInstance+"..."); admin.createUser("anonymous", "anonymous", joramInstance); }

log.info("Created JORAM anonymous user.");

if (joramBindHost != null && joramBindQueues != null) { log.info("Looking up JNDI queues from rmi://"+joramBindHost+":1099"); javax.naming.Context jndiCtx;

java.util.Hashtable env = new java.util.Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.rmi.registry.RegistryContextFactory"); env.put(Context.PROVIDER_URL, "rmi://"+joramBindHost+":1099"); jndiCtx = new javax.naming.InitialContext(env);

Object[] remoteTopics = new Object[joramBindQueues.length]; for (int i = 0; i < joramBindQueues.length; i++) { String joramBindQueue = joramBindQueues[i]; remoteTopics[i] = jndiCtx.lookup(joramBindQueue); log.debug("Got queue "+joramBindQueue+": "+remoteTopics[i]);

// open up all topics to everyone admin.setFreeReading((Destination)remoteTopics[i]); admin.setFreeWriting((Destination)remoteTopics[i]); }

// if we are on local host, don't rebind if (!joramBindHost.equals("localhost")) { env.put(Context.PROVIDER_URL, "rmi://localhost:1099"); jndiCtx = new javax.naming.InitialContext(env);

for (int i = 0; i < joramBindQueues.length; i++) { jndiCtx.bind(joramBindQueues[i], remoteTopics[i]); log.debug("Bound "+joramBindQueues[i]+" in localhost context"); } } }

// Disconnecting the administrator. admin.disconnect(); }

log.info("Completed JoramDistributionService startup successfully."); } catch (Exception e) { throw new ServiceException("Could not start JoramDistributionService", e); }

The JoramDistributionService 363 Howto: JOnAS and JORAM: Distributed Message Beans

}

private boolean started = false; private String name;

public void stop() throws ServiceException { started = false; log.info("JoramDistributionService stopped"); }

public boolean isStarted() { return started; }

public void setName(String s) { name = s; }

public String getName() { return name; } }

This needs to be built with a simple task that just compiles the class and places it in a JAR file, which then must be placed in the $JONAS_ROOT/lib/ext or $JONAS_BASE/lib/ext directories on each server before launching JOnAS.

Maintaining the configuration

This is clearly a fairly large number of small configuration files on each server. We have automated the process of deploying the servers and their configuration via Ant. Ant 1.6 includes native support for scp and ssh operations, as Ant tasks. We have used these to build Ant tasks which can literally:

1. install JOnAS on all our servers. 2. create JONAS_BASE directories on each server, 3. copy the server−specific configuration over to each server, 4. build the JoramDistributionService and deploy it to each server, 5. launch JORAM and JOnAS on each server in the proper order, 6. build a customized version of our application for each type of server (i.e. a "frontend" version containing no message beans, and a "backend" version containing only message beans), 7. deploy the appropriate application version to each of the three servers, 8. and test the entire system using our system integration test suite.

In fact, we can do all of the above with a single Ant command.

Doing this with Ant is actually quite straightforward. Without support for automating this deployment process, we would be quite concerned with the complexity of the configuration. With automation, it is easy to place the whole configuration process under source code control, and it is easy to make controlled changes to the configuration of

Maintaining the configuration 364 Howto: JOnAS and JORAM: Distributed Message Beans

multiple machines.

Conclusion

Sorting out all these details was a long job (all the longer as we are located in San Francisco and Frederic, our lifeline, is in France, time−shifted by half a day!). However, the whole system does work now, and works well. JOnAS and JORAM are very impressive pieces of work, and the 4.0 releases of both promise to be even more so.

We look forward to continued use of the ObjectWeb platform, and we hope to continue to contribute constructively to the ObjectWeb community. You may also be interested in our description of using JOnAS with Hibernate, at http://www.hibernate.org/166.html.

Sincerely, Rob Jellinghaus (robj at nimblefish dot com)

Conclusion 365 Howto: JSR 160 support in JOnAS

The content of this document is the following:

1. Target Audience and Rationale 2. What is JSR 160 ? 3. Connector servers created by JOnAS

Target Audience and Rationale

Starting with version 4.1.4 JOnAS provides support for remote connection to the MBean server in a standard way.

The target audience for this document is the management application developer or the administrator, intending to use standard JMX RMI connectors to access the MBean Server running in a JOnAS server.

What is JSR 160 ?

The JSR 160 is a JMX Remoting specification which extends the JSR 3 specification by providing a standard API to connect to remote JMX−enabled applications.

Currently, JSR 160 has defined a mandatory connector based on RMI (that supports both RMI/JRMP and RMI/IIOP).

Support for JSR 160 connectors in JOnAS is based on the MX4J JMX implementation.

Connector servers created by JOnAS

Previous and current JOnAS versions implement a proprietary remote object allowing connection to the MBean server. This object is registered in JNDI under the name 'RMIConnector_jonasServerName'. It can be accessed using any of the communication protocols support by JOnAS (RMI/JRMP, RMI/IIOP, JEREMIE − see Choosing the Protocol).

JSR 160 support implies providing standard connector server objects. The JMX service creates at start−up one or several such objects, depending on the JOnAS configuration (in this case, depending on the content of carol.properties file). To create a client connector, the client side needs to know the URL of the connector server. Below we present the URLs that can be used by the clients depending on the protocol they choose.

Currently only 2 protocols can be used by JSR−160 connectors: RMI/JRMP and RMI/IIOP.

Using a RMI/JRMP Connector

This connector can be used if the jrmp protocol is set in the carol.protocols list.

Howto: JSR 160 support in JOnAS 366 Howto: JSR 160 support in JOnAS

The client has to construct a JMXServiceURL using the following String, possibly modified according to the JOnAS−specific configuration: service:jmx:rmi:///jndi/rmi://host:port/jrmpconnector_jonasServerName where host is the host on which is running the JOnAS server to be managed. The port number is given in the carol.properties file.

Then, a JMXConnector has to be created and connected to the connector server using the JMX Remote API.

Example 1:

Hashtable environment = null; JMXServiceURL address = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://host:1099/jrmpconnector_jonas"); JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment); connector.connect(environment);

Using a RMI/IIOP Connector

This connector can be used if the iiop protocol is set in the carol.protocols list.

The client code is similar to the JRMP case, but the String to be used to construct the JMXServiceURL must adhere to the following model: "service:jmx:iiop:///jndi/iiop://host:port/iiopconnector_jonasServerName"

Example 2:

Hashtable environment = null; JMXServiceURL address = new JMXServiceURL("service:jmx:iiop:///jndi/iiop://host:2001/iiopconnector_jonas"); JMXConnector connector = JMXConnectorFactory.newJMXConnector(address, environment); connector.connect(environment);

Connector servers created by JOnAS 367 Howto: Using the MC4J JMX Console

This guide describes how to connect the MC4J JMX Console to the JMX server running in a JOnAS server.

Recall that the current JMX implementation used by JOnAS is MX4J, and that JOnAS supports JSR 160 for remote connections to the JMX server (see the corresponding Howto document).

Connecting to the JMX server

Launch the MC4J console and create a JSR160 connection using the connection wizard.

• Choose JSR160 connector type • Provide a name for your connection • Change the server URL. The URL to use depends on the following configuration parameters of JOnAS: ♦ JONAS server name ♦ The host on which JOnAS is running ♦ The protocol used by the JOnAS name service (use only jrmp or iiop) ♦ The port number used by the JOnAS name service for that protocol For example, in the case of a JOnAS server having a default configuration and default name, you would use the following URL: service:jmx:rmi:///jndi/rmi://host:1099/jrmpconnector_jonas.

See the JSR 160 Support in JOnAS Howto document for specific JOnAS configurations.

Once connected, you can manage the connection (delete, disconnect or reconnect) and browse the MBeans registered in the JMX server.

Howto: Using the MC4J JMX Console 368 Howto: JOnAS and JMX, registering and manipulating MBeans

By Jonny Way.

Introduction

JMX (Java Management eXtensions) is an API for managing, among other things, J2EE applications. JOnAS (version 4 and above) integrates the MX4J open−source JMX server and registers a number of MBeans. The web−based JonasAdmin application acts as a JMX client, enabling viewing and manipulation of these MBeans.

It maybe desirable for an application to expose its own MBeans via the JMX server to allow application management (using, for example, MC4J). JOnAS currently does not provide a prebuilt method for registering MBeans with its JMX server. The intent of this document is to illustrate one method of registering application−specific MBeans with the JOnAS JMX server based on the m−let service.

ServletContextListener

The basic task of registering an MBean with the JOnAS JMX server is accomplished by the following implementation of the ServletContextListener interface. This implementation reads a number of MLet files, which specify the MBeans to be registered, and attempts to register those beans during the web application context initialization. import java.net.MalformedURLException; import java.net.URL; import java.util.Iterator; import java.util.ArrayList; import java.util.List; import java.util.Set; import java.util.StringTokenizer; import javax.management.InstanceAlreadyExistsException; import javax.management.InstanceNotFoundException; import javax.management.ReflectionException; import javax.management.MBeanServer; import javax.management.MBeanException; import javax.management.MBeanRegistrationException; import javax.management.MBeanServerFactory; import javax.management.MalformedObjectNameException; import javax.management.NotCompliantMBeanException; import javax.management.ObjectInstance; import javax.management.ObjectName; import javax.management.loading.MLet; import javax.management.loading.MLetMBean; import javax.servlet.ServletContextEvent; import javax.servlet.ServletContext; import javax.servlet.ServletContextListener;

Howto: JOnAS and JMX, registering and manipulating MBeans 369 Howto: JOnAS and JMX, registering and manipulating MBeans

import org.apache.log4j.Logger;

/** * ServletContextListener designed to register JMX MBeans into * an existing JMX server when the application starts up. The * MBeans to be loaded are specified in the MLet files whose * names are given in the servlet context parameter with the name mletFiles, * in a semi−colon delminated list (although this is not really * needed as multiple mlets can be specifyed in one file, it might * be useful). Note that the filename are relative to the WEB−INF * directory of the servlet context being listened to. * * Note, that this listener should precede (in web.xml) any other that depend * on the MBeans being registered. * * Note that the MBean registration is sensitive to classloader issues. For * example, when registering the MBeans in the JMX server provided by * the Jonas application server any libraries required by the MBeans need * to be in the central lib directory (lib/ext). * * * @author Jonny Wray * */ public class MBeanRegistrationListener implements ServletContextListener {

private static final String MLET_DOMAIN = "MBeanRegistrationListener"; private static final String MLET_BEAN_NAME = MLET_DOMAIN+":Name=MLet"; private static final String MLETFILE_INITPARAM_NAME = "mletFiles"; private static final Logger log = Logger.getLogger(MBeanRegistrationListener.class);

private MBeanServer lookForExistingServer(){ List mbeanServers = MBeanServerFactory.findMBeanServer(null); if(mbeanServers != null && mbeanServers.size() > 0){ return (MBeanServer)mbeanServers.get(0); } return null; }

private MBeanServer getMBeanServer(){ MBeanServer server = lookForExistingServer(); if(server == null){ server = MBeanServerFactory.createMBeanServer(MLET_DOMAIN); } return server; }

public void contextDestroyed(ServletContextEvent arg0) { log.info("Destroy event"); // Anything that needs to be done here on deregistering of the // web application?

Howto: JOnAS and JMX, registering and manipulating MBeans 370 Howto: JOnAS and JMX, registering and manipulating MBeans

}

private List getMLetURLs(String filenames){ List urls = new ArrayList(); StringTokenizer tok = new StringTokenizer(filenames, ";"); while(tok.hasMoreTokens()){ String filename = tok.nextToken(); URL configURL = Thread.currentThread().getContextClassLoader().getResource(filename); if(configURL == null){ log.error("Cound not load MLet file resource from "+filename+" using current thread context classloader"); } else{ urls.add(configURL); } } return urls; }

private List getMLetURLs(ServletContext context, String filenames){ List urls = new ArrayList(); StringTokenizer tok = new StringTokenizer(filenames, ";"); while(tok.hasMoreTokens()){ String filename = "/WEB−INF/"+tok.nextToken(); URL configURL = null; try { configURL = context.getResource(filename); } catch (MalformedURLException e) { log.error("URL for "+filename+" is malformed", e); } if(configURL == null){ log.error("Cound not find MLet file resource from "+filename+" in servlet context"); } else{ urls.add(configURL); } } return urls; }

/** * Dynamically register the MBeans specified in the list * of MLet files (relative to /WEB−INF/) specified in servlet context parameter * mletFiles as a semi−colon deliminated list of file names. * * The algorithm looks for already running JMX servers and uses * the first it comes across. If no servers are running, then * it creates one. * * Note, the interface does not define any exceptions to be * thrown. Currently, any exceptions thrown during registration

Howto: JOnAS and JMX, registering and manipulating MBeans 371 Howto: JOnAS and JMX, registering and manipulating MBeans

* are logged at error level and then ignored. This seems * reasonable, as these may or may not be a fatal event. In * this way the registration process reports its failure and * the application context initialization continues. */ public void contextInitialized(ServletContextEvent arg0) { log.info("Initializing event"); String filenames = arg0.getServletContext().getInitParameter(MLETFILE_INITPARAM_NAME); if(filenames != null && filenames.length() > 0){ MBeanServer server = getMBeanServer(); if(server != null){ try{ ObjectName name = new ObjectName(MLET_BEAN_NAME); if(!server.isRegistered(name)){ log.info("Creating new MLetMBean for dynamic registration"); MLetMBean mletService = new MLet(); server.registerMBean(mletService, name); } List urls = getMLetURLs(arg0.getServletContext(), filenames); for(int i=0;i < urls.size();i++){ URL url = (URL)urls.get(i); try { log.info("Registering MBeans from MLet file "+url); Set loadedMBeans = (Set)server.invoke(name, "getMBeansFromURL", new Object[]{url}, new String[]{URL.class.getName()});

processRegisteredMBeans(loadedMBeans); } catch (InstanceNotFoundException e) { log.error("Unable to register MBeans from MLet file "+url, e); } catch (MBeanException e) { log.error("Unable to register MBeans from MLet file "+url, e); } catch (ReflectionException e) { log.error("Unable to register MBeans from MLet file "+url, e); } } } catch(MalformedObjectNameException e){ log.error("Unable to register the MLetMBean", e); } catch(NotCompliantMBeanException e){ log.error("Unable to register the MLetMBean", e); } catch(MBeanRegistrationException e){ log.error("Unable to register the MLetMBean", e); } catch(InstanceAlreadyExistsException e){ log.error("Unable to register the MLetMBean", e); } } else{ log.error("MBeanServer not found and could not be created. Not registering MBeans.");

Howto: JOnAS and JMX, registering and manipulating MBeans 372 Howto: JOnAS and JMX, registering and manipulating MBeans

} } else{ log.error("No mletFiles servlet context parameter found."); } }

private void processRegisteredMBeans(Set loadedMBeans) { log.debug("Loaded beans: "+loadedMBeans.size()); Iterator it = loadedMBeans.iterator(); while(it.hasNext()){ Object o = it.next(); if(o instanceof ObjectInstance){ ObjectInstance inst = (ObjectInstance)o; log.info("Registered: "+inst.getObjectName()); } else if(o instanceof Throwable){ Throwable err = (Throwable)o; log.error("Error registering MBeans", err); } } }

}

Configuration

In order to use the above ServletContextListener, it must be configured in the web.xml of the web application that wants to register the MBeans. For example, the following lines added to the web.xml will result in the registeration of the MBeans specified in the application.mlet file under the WEB−INF directory. Multiple MLet files can be specified in a comma−separated list.

mletFiles application.mlet

net.fiveprime.jmx.MBeanRegistrationListener

An example MLet file to load an extension (detailed below) of the HibernateService MBean is:

Configuration 373 Howto: JOnAS and JMX, registering and manipulating MBeans

Library Dependences

Registration of MBeans results in their construction by the JMX server. As such, any classes the MBean is dependent on must be available to the JMX server, in lib/ext.

HibernateService Extension

The Hibernate distribution provides an implementation of HibernateServiceMBean in the class HibernateService. In the MLet file above, an extension of this class is specified that allows the HibernateService to be configured from an external file, such as the standard hibernate.cfg.xml file. There are a number of situations where it is desirable to use the Hibernate mapped classes outside of Jonas running a JMX server. This allows the Hibernate mapping files and properties to be specified in one place and used in multiple situations. If this is not needed, then the HibernateService class can be used directly. import java.io.IOException; import java.net.URL; import java.util.ArrayList; import java.util.HashMap; import java.util.Iterator; import java.util.List; import java.util.Map; import net.sf.hibernate.HibernateException; import net.sf.hibernate.jmx.HibernateService; import org.apache.commons.digester.Digester; import org.apache.commons.logging.Log; import org.apache.commons.logging.LogFactory; import org.xml.sax.SAXException; /** * Extension of the HibernateService class to add configuration * ability from a Hibernate XML configuration file. * * @author Jonny Wray * */ public class ConfigurableHibernateService extends HibernateService {

private static Log log = LogFactory.getLog(ConfigurableHibernateService.class);

/** * Configure this HibernateService from an XML file * * @param filename The Hibernate XML configuration file, for example hibernate.cfg.xml * @param jndiName The JNDI name that the session factory will be registered under

Library Dependences 374 Howto: JOnAS and JMX, registering and manipulating MBeans

* @param datasourceName The name of the datasource used by the session factory * @throws HibernateException If there's a problem reading the configuration file */ public ConfigurableHibernateService(String filename, String jndiName, String datasourceName) throws HibernateException{

init(filename, jndiName, datasourceName); start(); }

private void init(String filename, String jndiName, String datasourceName) throws HibernateException { if(log.isDebugEnabled()){ log.debug("Configuring Hibernate JMX MBean with filename "+filename+ ", JNDI name "+jndiName+" and datasource "+datasourceName); } try{ URL url = this.getClass().getClassLoader().getResource(filename); Digester mappingDigester = configureMappingDigester(); List results = (List)mappingDigester.parse(url.openStream()); Iterator it = results.iterator(); while(it.hasNext()){ StringBuffer buffer = (StringBuffer)it.next(); addMapResource(buffer.toString()); log.debug("Adding mapping resource "+buffer.toString()); }

Digester propertyDigester = configurePropertyDigester(); Map resultMap = (Map)propertyDigester.parse(url.openStream()); it = resultMap.keySet().iterator(); while(it.hasNext()){ String key = (String)it.next(); String value = (String)resultMap.get(key); setProperty("hibernate."+key, value); log.debug("Adding property ("+key+","+value+")"); } setJndiName(jndiName); setDatasource(datasourceName); } catch(IOException e){ throw new HibernateException(e); } catch(SAXException e){ throw new HibernateException(e); } }

private Digester configureMappingDigester(){ Digester digester = new Digester(); digester.setClassLoader(this.getClass().getClassLoader()); digester.setValidating(false); digester.addObjectCreate("hibernate−configuration/session−factory", ArrayList.class);

digester.addObjectCreate("hibernate−configuration/session−factory/mapping", StringBuffer.class); digester.addCallMethod("hibernate−configuration/session−factory/mapping", "append", 1);

Library Dependences 375 Howto: JOnAS and JMX, registering and manipulating MBeans

digester.addCallParam("hibernate−configuration/session−factory/mapping", 0, "resource"); digester.addSetNext("hibernate−configuration/session−factory/mapping", "add");

return digester; }

private Digester configurePropertyDigester(){ Digester digester = new Digester(); digester.setClassLoader(this.getClass().getClassLoader()); digester.setValidating(false); digester.addObjectCreate("hibernate−configuration/session−factory", HashMap.class);

digester.addCallMethod("hibernate−configuration/session−factory/property", "put", 2); digester.addCallParam("hibernate−configuration/session−factory/property", 0, "name"); digester.addCallParam("hibernate−configuration/session−factory/property", 1);

return digester; } }

Configuring RMI for use through a Firewall

By default, the RMI protocol in JOnAS uses a random port at each startup, which implies that there is no way to configure a firewall as the port number changes each time the system restarts.

However, as of JOnAS version 4.4.1, you can easily configure the RMI port number by setting only one property per protocol in the $JONAS_BASE/conf/carol.properties file.

To configure the RMI exported−port number, edit the $JONAS_BASE/conf/carol.properties file to change the following protocols from 0 (choose a random port number) to the port number you want:

• For the RMI/JRMP protocol, change:

carol.jrmp.server.port=0 • For the RMI/Jeremie protocol, change:

carol.jeremie.server.port=0 • For the RMI/IIOP protocol, change:

carol.iiop.server.port=0

Note: The jonas.orb.port property has been moved from the $JONAS_BASE/conf/jonas.properties file to the $JONAS_BASE/conf/carol.properties file, as the latter is the file in which the registry ports and protocols were already being set. In previous JOnAS versions the jonas.orb.port property was not useful in multi−protocols mode as it allowed only one port number to be set for a single protocol. Also, the jonas.orb.port property was working only for RMI/JRMP and for objects using the

Configuring RMI for use through a Firewall 376 Howto: JOnAS and JMX, registering and manipulating MBeans

PortableRemoteObject class for their export.

Configuring RMI for use through a Firewall 377 How to configure and use xdoclet for JOnAS

This guide contains the following sections:

• Downloading and installing xdoclet • Ejbdoclet Ant target • Xdoclet tags for JOnAS

Downloading and installing xdoclet

You can find Xdoclet for JOnAS on ObjectWeb SourceForge / Tools / xdoclet / xdocletForJOnAS42.zip

This ZIP file contains:

• test: A folder that contains tests for JOnAS tags. You can use this as an example for your applications. • objectweb−tags.html: Tags for the creation of JOnAS−specific resources (for use with xdoclet−objectweb−module−1.2.2.jar). • xdoclet−objectweb−module−1.2.2.jar: Updated ObjectWeb libraries for xdoclet. • Readme.txt: This readme file.

How to use this archive:

• Download xdoclet from: http://xdoclet.sourceforge.net/install.html • Install xdoclet and replace your local xdoclet−objectweb−module−1.2.2.jar file with this new version of that file.

Note: JOnAS examples (xdoclet and olstore) use the $JONAS_ROOT/lib/example/xdoclet/xdoclet−objectweb−module−1.2.2.jar.

Ejbdoclet Ant target

The following ejbdoclet Ant target illustrates how to launch an xdoclet task to generate a deployment descriptor for JOnAS. The defaultentityjndiname is not mandatory, but you can use it if you do not want to specify the @bean.jndi−name for your Entity beans.

How to configure and use xdoclet for JOnAS 378 How to configure and use xdoclet for JOnAS

addedtags="@xdoclet−generated at ${TODAY}" ejbspec="2.0" verbose="true" > ...

Xdoclet tags

Field−Level Tags

• @jonas.bean • @jonas.resource • @jonas.resource−env • @jonas.ejb−ref • @jonas.session−timeout • @jonas.is−modified−method−name • @jonas.shared • @jonas.passivation • @jonas.max−cache−size • @jonas.min−pool−size • @jonas.jdbc−mapping • @jonas.jonas−message−driven−destination

Method−Level Tags

• @jonas.ejb−relation • @jonas.cmp−field−jdbc−mapping

Field−Level Tags jonas.bean

The jonas.bean element declares the JOnAS−specific information for an enterprise bean.

Parameter Type Applicability Description Mandatory ejb−name text The enterprise bean's name specified in the true standard EJB deployment descriptor. jndi−name text false

Xdoclet tags 379 How to configure and use xdoclet for JOnAS

The JNDI name of the enterprise bean's home. Concerns only the Entity and Session beans. Mandatory if version < 2.5, but optional for Session beans for 2.5 onwards. cleanup text Determines the jonas−specific behavior for table false management at deploy time. lock−policy text Determine the jonas−specific lock policy for false database access. automatic−pk−field−name text The jdbc column name for automatic primary key; false auto−generated. inactivity−timeout text Optional inactivity−timeout value (integer value) false prefetch text Optional prefetch (boolean value) false jonas.resource

The jonas.resource element declares the JOnAS−specific information for an external resource referenced by a bean.

Parameter Type Applicability Description Mandatory res−ref−name text The name of the resource reference specified in the standard true EJB deployment descriptor. jndi−name text The JNDI name of the resource. true jonas.resource−env

The jonas.resource−env element declares the JOnAS−specific information for an external resource environment referenced by a bean.

Parameter Type Applicability Description Mandatory resource−env−ref−name text The name of the resource environment reference true specified in the standard EJB deployment descriptor. jndi−name text The JNDI name of the resource environment. true jonas.ejb−ref

The jonas.ejb−ref element declares the JOnAS−specific information for a reference to another enterprise bean's home.

Xdoclet tags 380 How to configure and use xdoclet for JOnAS

Parameter Type Applicability Description Mandatory ejb−ref−name text The name of the EJB reference specified in the standard EJB true deployment descriptor. jndi−name text The JNDI name of the ejb. true jonas.ejb−ref

The jonas.ejb−ref element specifies the value of timeout in seconds for expiration of session instances.

Parameter Type Applicability Description Mandatory session−timeout int The value of timeout in seconds for expiration of session true instances. jonas.is−modified−method−name

The jonas.is−modified−method−name element specifies the name of the is−modified method of an entity.

Parameter Type Applicability Description Mandatory is−modified−method−name text The name of the is−modified method of an entity. true jonas.shared

The jonas.shared element specifies whether the bean state can be accessed outside JOnAS. This tag was introduced in version 2.4.

Parameter Type Applicability Description Mandatory shared bool True if the bean state can be accessed outside JOnAS. The default true is False. jonas.passivation−timeout

The jonas.passivation−timeout element specifies the value of timeout in seconds for passivation of entity instances when no transaction are used.

Parameter Type Applicability Description Mandatory passivation−timeout int The value of timeout in seconds for passivation of entity true instances when no transaction are used.

Xdoclet tags 381 How to configure and use xdoclet for JOnAS

jonas.max−cache−size

The jonas.max−cache−size element defines the max number of instances (int value) that can be held in memory. The default value is infinite. This tag was introduced in version 2.4. jonas.min−pool−size

The jonas.min−pool−size element specifies the number of instances that will be created to populate the pool when the bean is loaded for the first time. The default value is 0. This tag was introduced in version 2.4. jonas.jdbc−mapping

The jonas.jdbc−mapping element declares the mapping of an entity with container−managed persistence to the underlying database.

Parameter Type Applicability Description Mandatory jndi−name text The JNDI name of the datasource. true automatic−pk bool True or False for use automatic generation of primary key. false jdbc−table−name text The name of the relational table. true jonas.finder−method−jdbc−mapping

The jonas.finder−method−jdbc−mapping element declares the SQL WHERE clause associated to a finder method of a container−managed persistence entity.

Parameter Type Applicability Description Mandatory method−name text The method's name. true method−params text Identifies a single method among multiple methods with false an overloaded method name. jdbc−where−clause text The SQL WHERE clause. true jonas.jonas−message−driven−destination

The jonas.jonas−message−driven−destination element declares the JOnAS−specific information for a the message−driven bean destination.

Parameter Type Applicability Description Mandatory jndi−name text The JNDI name of the message driven destination. true

Xdoclet tags 382 How to configure and use xdoclet for JOnAS

Method Level tags jonas.ejb−relation

The jonas.ejb−relation element declares the CMR fields Mapping to primary−key−fields to the underlying database.

Parameter Type Applicability Description Mandatory true if the pk is composite (default value = pk−composite text false false) ejb−relation−name text The name of the relationship. true jdbc−table−name text The optional name of the relation joint table. false ejb−relationship−role−name1 text The name of the first relationship role. true foreign−key−jdbc−name1 text The column(s) name(s) of the foreign key true ejb−relationship−role−name2 text The name of the second (if the relation is false bi−directional) relationship role. foreign−key−jdbc−name2 text The column names of the foreign key false jonas.cmp−field−jdbc−mapping

The jonas.cmp−field−jdbc−mapping element declares the mapping of a container−managed field of an entity to a column of a relational table.

Parameter Type Applicability Description Mandatory field−name text The field's name. true jdbc−field−name text The column name of the relational table. true sql−type text The sql−type element specifies the SQL type (CMP2 only) false key−jdbc−name text The column name of the primary key composite of this field false

Xdoclet tags 383 Howto: How to employ recovery in JOnAS

The content of this guide is the following:

1. Transaction Recovery Overview 2. JOnAS Transaction Recovery 3. Implications of a Non−Conforming Resource Manager 4. JOnAS−JOTM Transaction Recovery Configuration 5. XA DataSource Configuration 6. Monitoring Executing Transactions 7. JOnAS Administrative Recovery 8. JOnAS Administrative Heuristic Recovery

Transaction Recovery Overview

Applications and application platforms, such as JOnAS, employ transactions in order to guarantee the atomicity of operations. When the application is interacting with a single data source; e.g., database, then the use of transactions often appears unnecessary since the success of the unit of work depends only on the successful persistence of the work done by that single database.

However, whenever a single unit of work employs multiple data sources, then the management of transactional behavior becomes non−trivial. It is imperative that none of the data sources commits updates unless all of the data sources commit. Solving this problem has resulted in the adoption of the 2−Phase commit protocol. More specifically, J2EE has adopted a variation of 2−Phase XA commitment protocol from the X/Open Group.

Since any database may elect to rollback when asked to commit, it is necessary to perform commitment in multiple phases. First, all databases are asked to "prepare" to commit. Each database verifies that it is capable of persisting the data and either votes to commit or votes to rollback. After a vote to commit, the database delays actual commitment until all of the other databases have similarly voted. For this database, the transaction is in an in−doubt state. If all databases involved with the transaction agree to commit, then a second "phase" is performed where each is requested to commit.

The role of the transaction manager is to keep track of all data sources involved with a transaction. If multiple databases are involved, then the transaction manager will perform the 2−Phase commitment protocol.

Many databases have not completely implemented XA 2−Phase commitment. These typically do not provide a prepare() method or if they do, the method does nothing but returns a affirmative status. Many either do not provide a recover() method or simply return a NULL list of Xid's no matter what the circumstances.

A fully compliant resource manager will only resolve the in−doubt state when informed of the results of the voting by the transaction manager. Resource managers may implement "heuristic decisions" and elect to either COMMIT or ROLLBACK in−doubt transactions based on local information. However, when they do, the protocol requires that they report the use of the heuristic and its result to the controlling transaction manager during the next attempt to recover. Few resource managers are fully compliant.

Howto: How to employ recovery in JOnAS 384 Howto: How to employ recovery in JOnAS

If there is a loss of communication between the resource manager and the controlling transaction manager, then the protocol is completed by re−establishing the communication and having the transaction manager query the resource manager with the recover() call. The resource manager is to respond with the entire list of transaction which are in−doubt. Each transaction identifier on this list contains information which allows the transaction manager to determine if the associated transaction branch is being managed by it.

Transactions are either ignored, committed, or rolled back, based on the information in the transaction identifier and the transaction log of the transaction manager. During COMMIT and ROLLBACK calls, the resource manager must report any heuristic decisions taken on behalf of the associated transactions to the transaction manager.

If there is a platform or software failure of the resource manager, then it is expected to rebuild the in−doubt state and be prepared to complete the same recovery protocol as described earlier in this document. This will usually require a database manager to reacquire record and page locks to guarantee that resources required for a rollback will be untouched and available for backdates.

JOnAS Transaction Recovery

Since JOnAS 4_4_0, transaction recovery has been available. JOnAS utilizes the Java Open Transaction Manager (JOTM) jotm.objectweb.org from Objectweb www.objectweb.org as its manager of transactions. JOTM guarantees that all resources are either all committed or rolled back by utilizing a 2−Phase commit protocol when multiple XA resources are involved. Since JOTM_2_0_9, support for the recovery of transactions across resource or system crash has been available.

At JOnAS startup, the Resource Adapters as defined by the Java Connector Architecture 1.5 registers all the resource managers with JOTM. For any resources in an in−doubt state, JOTM requests that the resource completes (commits or aborts) its work and release any data sources (e.g., database pages).

For a resource manager to participate in transaction recovery, it must fully support the XAResource interface as described in the X/Open Specification. This includes implementation of the recover() method for the XAResource. The xaresource.recover() method returns a list of XIDs (a global transaction identifier) that are in a prepared or heuristically committed state. JOTM interrogates its internal recovery tables to determine if the XIDs were participating in a transaction when the system failed.

If a resource implements 2−phase commit protocol as described in the X/Open Specification but does not implement the recover() method, we refer it to as a 'non−conforming' XAResource and it will not properly complete transaction recovery. Currently Oracle RDBMS, IBM DB2, and Bull IDS/II are the only resource managers known to us to support the 2−Phase commit protocol and XA Recovery. Recovery testing has been performed only with Oracle RDBMS, but plans are to test with Postgres SQL when support for XA recovery is available.

Implications of a Non−Conforming Resource Manager

If a resource manager does not implement the prepare() method, its prepare vote cannot be trusted when used with conforming resource managers. That is, the prepare() method is an indication that the data source will commit the resource successfully when the commit() method is called. Since the prepare vote cannot be trusted, the

JOnAS Transaction Recovery 385 Howto: How to employ recovery in JOnAS

non−conforming resource manager can return a failure on the commit() call. This situation can cause the guarantee of atomicity (invalid results to exist) among the data sources (e.g., databases) to be compromised, some resources have committed and the non−conforming resource has failed.

If a resource manager does not implement the recover() method, it will return no XIDs when requested to recover. This implies that the data source has committed its resources even though the conforming resource managers may return XIDs to recover, but to recover with an abort (rollback). Again, you have a situation where the guarantee of atomicity among the data sources is compromised.

JOnAS−JOTM Transaction Recovery Configuration

JOTM provides for the JOnAS user a properties file, jotm.properties. This file is located in the /dist/conf directory. The jotm.properties file contains entries that inform JOTM whether recovery is enabled or disabled (default).

The jotm.properties file also contains configuration information of the JOTM recovery log files. These log files contain information transaction history required to resolve in−doubt transactions in case of system failures. JOTM utilizes the features of the High Performance Objectweb Logger (HOWL) howl.objectweb.org to manage the in−doubt records. All but the 'jotm.recovery.Enabled' entry is a HOWL configuration property.

The provided values for HOWL specified in the jotm.properties files should suffice for most installations. A short description of each jotm.properties entry follows.

Property Value Description true/false jotm.recovery.Enabled recovery enabled (default) true/false howl.log.ListConfiguation list Howl configuration on trace file (default) value is multiplied by 1024 to establish the howl.log.BufferSize 4 actual buffer size used by the Howl howl.log.MinimumBuffers 16 minimum number of buffers howl.log.MaximumBuffers 16 maximum number of buffers howl.log.MaximumBlocksPerFile 200 maximum number of blocks per log file howl.log.FileDirectory c:/logs pathname of recovery log files howl.log.FileName howl name of log file, e.g., howl1, howl2 howl.log.MaximumFiles 2 number of recovery log files

The values specified cannot be changed while JOnAS is in execution. JOnAS must be stopped, the jotm.properties values changed, and JOnAS restarted for any new values to be accepted.

JOnAS−JOTM Transaction Recovery Configuration 386 Howto: How to employ recovery in JOnAS

XA DataSource Configuration

In a future release of JOnAS and JOTM, additional properties will be added to the XML files used to define the characteristics of a JOnAS Resource Adapter. The additional properties will allow the Resource Adapter implementer to state the conformance level of the resource adapter. That is, does the resource adapter fully implement the xaresource.recover() method. Of course, if the resource adapter implementer inadvertently states an incorrect conformance level, the guarantee of atomicity among the data sources may be compromised.

Monitoring Executing Transactions

A Transaction Monitoring facility is available in the JOnAS Administration (jonasadmin) web tool. With this tool, a JOnAS administrator can monitor the life cycle of executing transactions.

Transaction Monitor Frame

XA DataSource Configuration 387 Howto: How to employ recovery in JOnAS

JOnAS Administrative Recovery

In most instances, JOnAS with JOTM will be able to recover all transactions in an in−doubt state after a system failure for Resource Managers and XAResources that implement the recover() method. In those few instances where recovery could not be completed, the JOnAS Administration (jonasadmin) Recovery web tool can be employed.

The administrative recovery feature allows the administrator to view any transactions that require administrative intervention. In the examples that follow, the sequence of actions performed by the JOnAS Administrator is described to complete the commit pending transaction.

The Recovery Frame 1 displays the recovery view in which one transaction has not completed. For example, the XAResource (database) replied to the prepare request, but the XAResource threw a XAER_xxxx exception during the commit request (e.g., database went offline). In this frame, the transaction has two resources (defined by an Xid Count) waiting for administrative action.

Recovery Frame 1

By selecting the transaction specified under Transaction, Recovery Frame 2 displays the XAResource view. In this view, the XAResources are shown with their respective Resource Manager, Xid, and Xid State. The resource manager

JOnAS Administrative Recovery 388 Howto: How to employ recovery in JOnAS

jdbc_xa1 has a STATUS_COMMITTED state that indicates that it has committed its XAResource. The resource manager jdbc_xa2 has a STATUS_COMMITING state that indicates that the XA resource is in an in−doubt state (i.e., a commit request was sent to the XA resource but the XAResource replied with an XAER_xxxx exception). If the jdbc_xa2 resource manager is a database, its pages will be locked until a commit or rollback is issued on its XAResource.

Recovery Frame 2

Since the jdbc_xa2 resource has not been registered during JOnAS startup, it is not selectable. If any of the Heuristic buttons are selected, Recovery Frame 3 displays the Confirm view that states that no XAResource has been selected.

JOnAS Administrative Recovery 389 Howto: How to employ recovery in JOnAS

Recovery Frame 3

By using the JOnAS administrative deploy option to dynamically add a resource adapter 'jonas admin a jdbc_xa2.rar', the resource manager jdbc_xa2 is deployed and JOnAS requests that JOTM recover any transactions that may be the in−doubt state. Recovery Frame 4 displays that no transactions require recovery since JOTM successfully recovered the transaction.

If a resource manager fails requiring recovery while JOnAS is executing, then dynamic deployment may be used to effect recovery. As in the prior paragraph, the administrator would first undeploy the resource adapter with 'jonas admin d jdbc_xa2.rar'. A subsequent deployment, 'jonas admin a jdbc_xa2.rar', would cause JOTM and the resource manager to attempt recovery without needing to restart JOnAS.

JOnAS Administrative Recovery 390 Howto: How to employ recovery in JOnAS

Recovery Frame 4

JOnAS Administrative Heuristic Recovery

The Heuristic Frame 1 displays the recovery view in which one transaction has not completed. In this example, the transaction has two resources (defined by an Xid Count) waiting for administrative action.

JOnAS Administrative Heuristic Recovery 391 Howto: How to employ recovery in JOnAS

Heuristic Frame 1

By selecting the transaction specified under Transaction, Heuristic Frame 2 displays the XAResource view. In this view, the XAResources are shown with their respective Resource Manager, Xid, and Xid State. The resource manager jdbc_xa1 has a STATUS_COMMITTED state that indicates that it has committed its XA resource. The resource manager jdbc_xa2 has a STATUS_UNKNOWN state that indicates that the XA resource returned an XA_HEURxxx exception for the commit request. If the jdbc_xa2 resource manager is a database, its pages will be lock until a commit or rollback is issued on its XAResource. Since the jdbc_xa2 resource has not completed, it is the only resource selectable.

JOnAS Administrative Heuristic Recovery 392 Howto: How to employ recovery in JOnAS

Heuristic Frame 2

By selecting jdbc_xa2 and invoking the 'Heuristic Commit' button, the Heuristics Frame 3 displays the Confirm view requesting a confirmation of the commit action. The Heuristic Commit button was selected because the jdbc_xa1 resource has already been committed and therefore we are requesting that the jdbc_xa2 resource also be committed.

JOnAS Administrative Heuristic Recovery 393 Howto: How to employ recovery in JOnAS

Heuristic Frame 3

When the 'Confirm button is invoked, JOnAS requests thru JOTM that the XAResource of jdbc_xa2 be completed (commit). Since the all resources of the transaction have now completed the 2−Phase commit protocol successfully, the resources (database pages) can be released and JOTM can remove the transaction information from its internal tables.

The Heuristic Frame 4 displays the Recovery view displaying that there are no longer any transactions requiring recovery.

JOnAS Administrative Heuristic Recovery 394 Howto: How to employ recovery in JOnAS

Heuristic Frame 4

HowTo setup a C−JDBC Database

Note: For further informaton about Configuration of a clustered database in RAID1, refer to the ObjectWeb documentation. This configuration starts three HSQL instances that are formed by c−jdbc as raid 1. This means that the same data is stored in two different databases and one database is used as a recovery log.

1. Download the c−jdbc binaries from the c−jdbc site.

2. Extract the c−jdbc archive in a folder. tar xvfz c−jdbc−xx−bin.tar.gz

3. Set the environment variables. export JAVA_HOME= export CJDBC_HOME=

4. Modify the $CJDBC_HOME/demo/demo−raidb1.sh file. The ports for the HSQLDB instances must be modified to match the sampleCluster2. Change the ports for the three databases to 11001, 11002, 11003.

HowTo setup a C−JDBC Database 395 Howto: How to employ recovery in JOnAS

5. Configure the c−jdbc controller file: $CJDBC_HOME/config/virtualdatabase/hsqldb−raidb1.xml Change: modify the ports according to the values defined in the section above. To avoid problems in the Datasource configuration of JOnAS, you must also set a password for the users to log in.

Backup original configuration: mv $CJDBC_HOME/config/controller/controller.xml $CJDBC_HOME/config/controller/controller.xml.original

Create the link for the new configuration: ln −s $CJDBC_HOME/config/controller/controller−raidb1.xml $CJDBC_HOME/config/controller/controller.xml

Modify the file: $CJDBC_HOME/config/controller/controller.xml

Specify the configuration file of the virtual database in this file. The configuration file is: $CJDBC_HOME/config/virtualdatabase/hsqldb−raidb1.xml

6. Start the HSQL instances. $CJDBC_HOME/demo/demo−raidb1.sh

7. Start the cjdbc controller. $CJDBC_HOME/bin/controller.sh

8. Connect to the cjdbc controller using the JDBC driver in $CJDBC_HOME/drivers and the url: jdbc:cjdbc://localhost:25322/myDB with username: and password: Note: No password is specified by default. You should specify one in $CJDBC_HOME/config/virtualdatabase/hsqldb−raidb1.xml.

Sample configuration of a c−jdbc database in JOnAS:

###################### C−JDBC DataSource configuration example # ##### DataSource configuration # atasource.name jdbc_1 datasource.url jdbc:cjdbc://localhost:25322/myDB datasource.classname org.objectweb.cjdbc.driver.Driver datasource.username user datasource.password pass datasource.mapper rdb.hsql # REMARK: You must specify the mapper of the databases used as backend by

HowTo setup a C−JDBC Database 396 Howto: How to employ recovery in JOnAS

c−jdbc. # It is not possible to use a heterogenious c−jdbc configuration here.

Load Balancing with Enhydra Director

1. Download the Tomcat (or Jetty) module from the ObjectWeb site.

2. Download the binaries or sources for the Apache module. Remark: You can also download an entire distribution of Apache webserver in which the module is already included and configured.

3. Configure the apache director module. File: $APACHE_HOME/conf/enhydra_director.conf

Example configuration:

Remark: In this configuration, the connector is configured to forward the requests for one web application (load balancing and fail over). The second (sampleCluster2 example) is running on one machine, but on different ports. Furthermore, the /status context allows you to enable, disable and change some parameters of the director configuration. The /status context is only available on the machine where director is running in this sample configuration.

4. Copy the tomcat module (tomcat−director.jar) to $CATALINA_HOME/server/lib or $JONAS_ROOT/lib/catalina/server/lib. Note: For the JOnAS+Tomcat package use: $JONAS_ROOT/lib/catalina/server/lib For a standalone Tomcat installation use: $CATALINA_HOME/server/lib

5. Configure the connector in the tomcat configuration ($CATALINE_HOME/conf/server.xml). Example configuration: Add these lines to the configuration where the other connectors (AJP, ...) are defined: Using TomCat 5.0.x as servlet container

Load Balancing with Enhydra Director 397 Howto: How to employ recovery in JOnAS

Using TomCat 5.5.x as servlet container

Remark: The session affinity attribute is set to false because the session replication is activated in JOnAS. Otherwise, a new session is created when Director switches between the instances. The Director connector may coexiste with the mod_jk connector.

6. Restart Apache.

7. Restart JOnAS.

Load Balancing with Enhydra Director 398 Migrating from mod_jk2 to mod_jk with embedded Tomcat

Note: This document shows one of several ways to migrate mod_jk2 settings to work with mod_jk instead. The mod_jk2 reference setup can be found here. Also, all references to jonas−server should be replaced by the hostname of the target machine for which you want to configure mod_jk. Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values.

1. Edit the file $JONAS_BASE/conf/server.xml; locate and uncomment the following line:

−−>

Change it to look like the following:

Next, comment out the existing mod_jk2−oriented connector and engine elements:

...

Replace the base Engine tag in which a jvmRoute with the standard engine is used. For example, comment out the line that looks similar to the following:

and uncomment the following line:

Migrating from mod_jk2 to mod_jk with embedded Tomcat 399 Migrating from mod_jk2 to mod_jk with embedded Tomcat

Note: Always backup files like server.xml before editing.

2. Now you can either let tomcat generate the mod_jk.conf file automatically, which will setup forwarding for a limited set of applications, or you can create a custom mod_jk.conf file where you can specify applications to forward and customize configuration information.

Note: The automatically generated file cannot be customized since it is re−written every time tomcat is restarted by the user.

a) To enable automatic generation, insert the following into the server.xml file nested under the base tag:

and insert the following under the element:

When jonas/tomcat is restarted, there will be a file created under $JONAS_BASE/lib/catalina/conf/auto called mod_jk.conf.

b) If you want to create a custom file, the recommendation is to place a file named mod_jk.conf under $JONAS_BASE/conf/jk. You can view this file as the equivalent of the $APACHE_HOME/conf.d/JOnAS.conf in the mod_jk2 directions; however, it is not a direct replacement.

A simple mod_jk.conf file that can be used is:

# Load the mod_jk module if not loaded. LoadModule jk_module "$APACHE_HOME/modules/mod_jk.so"

# Specify location of worker file and log file. Worker file will follow shortly. JkWorkersFile "$JONAS_BASE/conf/jk/workers.properties" JkLogFile "$JONAS_BASE/logs/mod_jk.log"

# When and how much logging. JkLogLevel emerg

# This is a little awkward. It seems mod_jk associates applications it will # map to tomcat based on the virtual host. If for instance I wish to visit # the jonasAdmin application through http://jonas−server/jonasAdmin from another

Migrating from mod_jk2 to mod_jk with embedded Tomcat 400 Migrating from mod_jk2 to mod_jk with embedded Tomcat

# machine and I have the following setting then the application behaves # perfectly normally, i.e, behaves as one would expect if you # were using the application directly using the appropriate port (9000). # However, if you try using http://localhost/jonasAdmin from jonas−server # without the explicit VirtualHost declaration, only the directory contents # are mapped. No processing on the tomcat is carried out, so struts based # applications will fail to work. That is the reason why we explicitly # mention both virtual hosts. ServerName jonas−server JkMount /cmp2 ajp13 JkMount /cmp2/* ajp13 JkMount /alarm ajp13 JkMount /alarm/* ajp1 JkMount /earsample ajp13 JkMount /earsample/* ajp13 JkMount /jonasAdmin ajp13 JkMount /jonasAdmin/* ajp13

ServerName localhost JkMount /cmp2 ajp13 JkMount /cmp2/* ajp13 JkMount /alarm ajp13 JkMount /alarm/* ajp13 JkMount /earsample ajp13 JkMount /earsample/* ajp13 JkMount /jonasAdmin ajp13 JkMount /jonasAdmin/* ajp13

3. Now tell apache to use this file. Backup the file: $APACHE_HOME/conf/httpd.conf. Edit the /etc/httpd/conf/httpd.conf file and insert:

Include ${JONAS_BASE}/conf/jk/mod_jk.conf

Note: replace ${JONAS_BASE} with appropriate value.

Locate and comment out the following line in the same file:

LoadModule jk2_module modules/mod_jk2.so

4. Now create a workers.properties file. This can be placed in $JONAS_BASE/conf/jk/workers.properties. A sample that has been used successfully is:

Migrating from mod_jk2 to mod_jk with embedded Tomcat 401 Migrating from mod_jk2 to mod_jk with embedded Tomcat

# workers.java_home should point to your Java installation. Normally # you should have a bin and lib directories beneath it. # workers.java_home=/usr/lib/jvm/java

# # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. # ps=/

# #−−−−−− ADVANCED MODE −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #

# #−−−−−− DEFAULT worket list −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # # # The workers that your plugins should create and work with # # Add 'inprocess' if you want JNI connector worker.list=ajp13 # , inprocess

# #−−−−−− DEFAULT worker1 WORKER DEFINITION −−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #

# # Defining a worker named worker1 and of type worker1 # Note that the name and the type do not have to match. # worker.ajp13.port=9009 worker.ajp13.host=jonas−server worker.ajp13.type=ajp13

#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Once all this is completed, restart jonas followed by httpd. Follow that up with a quick test by visiting: http://${HOSTNAME}/jonasAdmin. You should be able to use the application as normal. You can now use cmp2, earsample, alarm and jonasAdmin using mod_jk instead.

Migrating from mod_jk2 to mod_jk with embedded Tomcat 402 Setting up mod_jk2 with embedded Tomcat

Note: Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values.

1. Backup /$APACHE_HOME/conf/httpd.conf: cp $APACHE_HOME/conf/httpd.conf $APACHE_HOME/conf/httpd.conf.backup

2. Edit (~line 208) httpd.conf to add the loading of mod_jk2.so:

# Adding jk2_module reference. LoadModule jk2_module modules/mod_jk2.so

3. Edit $APACHE_HOME/conf.d/JOnAS.conf with the following content:

Alias /docs/jonas "$JONAS_BASE/doc/jonas−4.1.2" Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all

Alias /webapps/jonas "$JONAS_BASE/webapps/jonas" Options Indexes MultiViews AllowOverride None Order allow,deny Allow from all

JkUriSet group jonas

JkUriSet group jonas

JkUriSet group jonas

JkUriSet group jonas

4. Edit/create $APACHE_HOME/conf/workers2.properties with the following content:

[logger] level=DEBUG

Setting up mod_jk2 with embedded Tomcat 403 Setting up mod_jk2 with embedded Tomcat

# Shared memory handling. Needs to be set. [shm] info=Scoreboard. Required for reconfiguration and status with multiprocess servers file=$APACHE_HOME/logs/jk2.shm size=1048576 debug=0 disabled=0

# The channel configuration shall be consistent with # the configuration of JOnAS in server.xml # port = port of the AJP (jk2) connector # tomcatId = jvmRoute attribute of the element [channel.socket:toJonas01] info=channel to a JOnAS instance − tomcatId shall be identical to jvmRoute in the server.xml file of the JOnAS instance host=localhost port=9009 group=jonas

[status:status] info=provides info on the connecteur usage

[uri:$/jkstatus*] info=get the connector usage info at /jkstatus group=status:status

5. On the JOnAS side, edit $JONAS_BASE/conf/server.xml with the following content:

... ...

6. Comment out all lines in $JONAS_BASE/conf/jk2.properties.

7. Restart jonas and httpd services: service jonas restart; service httpd restart

8. Deploy cmp2.ear and alarm.ear.

9. Those apps are available at: http:///cmp2 http:///earsample http:///alarm http:///jonasAdmin

Setting up mod_jk2 with embedded Tomcat 404 Setting up mod_jk with embedded Tomcat

Note: Replace ${JONAS_BASE} and ${APACHE_HOME} with appropriate values.

1. Open the file $JONAS_BASE/conf/server.xml and uncomment the following line:

−−>

Edit it to look like the following:

2. Now you can either let tomcat generate the mod_jk.conf file automatically, which will setup forwarding for a limited set of applications, or you can create a custom mod_jk.conf file. The automatically generated file cannot be customized since it is re−written every time tomcat is restarted by the user. a) To enable automatic generation insert the following into the server.xml file nested under the base tag:

and insert the following under the element:

When jonas/tomcat is restarted, there will be a file created under $JONAS_BASE/conf/auto called mod_jk.conf.

b) If you want to create a custom file, the recommendation is to place mod_jk.conf under $JONAS_BASE/conf/jk. A simple mod_jk.conf file that can be used is:

# Load the mod_jk module if not loaded.

Setting up mod_jk with embedded Tomcat 405 Setting up mod_jk with embedded Tomcat

LoadModule jk_module "$APACHE_HOME/modules/mod_jk.so"

# Specify location of worker file and log file. Worker file will follow shortly. JkWorkersFile "$JONAS_BASE/conf/jk/workers.properties" JkLogFile "$JONAS_BASE/logs/mod_jk.log"

# When and how much logging. JkLogLevel emerg

# This is a little awkward. It seems mod_jk associates applications it will # map to tomcat based on the virtual host. If for instance I wish to visit # the jonasAdmin application through http://jonas−server/jonasAdmin from another # machine and I have the following setting then the application behaves # perfectly normally, i.e, struts kicks in as expected, form based # authentication and forwarding is done exactly as one would expect if you # were using the application directly using the appropriate port (9000). # However, if you try using http://localhost/jonasAdmin from jonas−server # without the explicit VirtualHost declaration, only the directory contents # are mapped. So we need to explicitly mention both virtual hosts. ServerName jonas−server JkMount /olstore ajp13 JkMount/olstore /* ajp13 JkMount /jonasAdmin ajp13 JkMount/jonasAdmin /* ajp13 # ajp13 is infact the worker name used in workers.properties. ServerName localhost JkMount /olstore ajp13 JkMount/olstore /* ajp13 JkMount /jonasAdmin ajp13 JkMount/jonasAdmin /* ajp13

3. To tell apache to use this file, edit the $APACHE_HOME/conf/httpd.conf file and insert:

Include ${JONAS_BASE}/conf/jk/mod_jk.conf

Note: Replace ${JONAS_BASE} with appropriate value.

4. Create a workers.properties file. This can be placed in

$JONAS_ROOT/conf/jk/workers.properties

A sample that has been used successfully is:

# workers.java_home should point to your Java installation. Normally

Setting up mod_jk with embedded Tomcat 406 Setting up mod_jk with embedded Tomcat

# you should have a bin and lib directories beneath it. # workers.java_home=/usr/lib/jvm/java

# # You should configure your environment slash... ps=\ on NT and / on UNIX # and possibly something different elsewhere. # ps=/

# #−−−−−− ADVANCED MODE −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #

# #−−−−−− DEFAULT worket list −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # # # The workers that your plugins should create and work with # # Add 'inprocess' if you want JNI connector worker.list=ajp13 # , inprocess

# #−−−−−− DEFAULT worker1 WORKER DEFINITION −−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− #

# # Defining a worker named worker1 and of type worker1 # Note that the name and the type do not have to match. # worker.ajp13.port=9009 worker.ajp13.host=jonas−server worker.ajp13.type=ajp13

#−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−

Once all this is completed, restart httpd and ensure that jonas/tomcat is up. You can follow that up with a quick test by visiting: http://host_name/jonasAdmin. You should now be able to use the application as normal.

Setting up mod_jk with embedded Tomcat 407 Using Enterprise Media Beans with JOnAS

This guide provides explanations for using Enterprise Media Beans with JOnAS.

Table of Contents:

• What are Enterprise Media Beans (EMB) ♦ Architecture ◊ Media Entity Beans ◊ Media Foundation Beans • EMB in JOnAS ♦ What JOnAS provides for using EMB ◊ Enterprise Media Beans Sample Application ◊ Enterprise Media Beans Core Application ♦ Additional EMB plugins ◊ Additional MFB Plugins ◊ Additional Publisher Plugins • EMB Advanced Settings ♦ Publisher Advanced Settings

What are Enterprise Media Beans (EMB)

Enterprise Media Beans provide a framework to integrate rich media data (i.e. audio, video, or image) into applications based on EJB Entity Beans within the J2EE application development model.

Architecture

Enterprise Media Beans target the seamless integration of rich media data into applications based on the J2EE programming model. Because such applications come in two basic shapes as described above, the Enterprise Media Beans architecture is separated into two components:

• Media Foundation Beans require only basic Java 2TM technology and can be used in any kind of J2EE application. • Media Entity Beans rely on EJB entity beans and are therefore of interest only for applications based on the Enterprise JavaBeans architecture.

Using Enterprise Media Beans with JOnAS 408 Using Enterprise Media Beans with JOnAS

EMB components Dependencies

Media Entity Beans

Media Entity Beans (MEB) integrate the services provided by Media Foundation Beans into the Enterprise JavaBeans architecture, adding additional services that require media persistence. This means that MEBs could participate in relationships with Entity Beans in a transparent "CMP−style" way.

Media Foundation Beans

Media Foundation Beans (MFB) allow media to be represented independently of its type. MFB represents media in a uniform way, allowing programming based on interfaces that represent the media and its metadata (width, height, color dept, frame rate, etc.), instead of programming based on a particular media format (GIF or MPEG video for example).

Media Foundation Beans can be used to transcode from one format to another, for example to convert GIF files to PNG (due to patent problems) when serving them from a Servlet. Media can be resized to certain required dimensions, or digital watermarks can be added to stock photographs that are sold online. All these media transformations are represented with interfaces, allowing any type of transformation chain to be implemented, from any media to any media.

What are Enterprise Media Beans (EMB) 409 Using Enterprise Media Beans with JOnAS

MFB plug−in architecture

For more information about architecture, refer to the brief chapter about EMB specification Architecture (Chapter 3): JSR 086

EMB in JOnAS

What JOnAS provides for using EMB

The JOnAS EMB implementation provides:

• an MEB implementation to manage media persistense and access, • a basic MFB implementation to manipulate some basic media formats (i.e. images), • a sample application, • an API to add a new way for accessing media (Publisher Plugins API), • an API to exend MFB and provide some new features (MFB Plugins API), • serveral easy−to−use plugin samples.

This schema provides an overview of all components that can be used with EMB in JOnAS.

EMB in JOnAS 410 Using Enterprise Media Beans with JOnAS

EMB components in JOnAS EMB implementation

Enterprise Media Beans Sample Application

The Enterprise Media Beans Sample Application is located in JONAS_EXAMPLES/emb−sample. It is a simple webapp that provides an overview of the EMBs' features.

This application is based on EMB Core Application and is designed to use the additional features provided by MFB Plugins or Publisher Plugins (additional image support, svg support, video transcodage, video streaming, ...)

Enterprise Media Beans Core Application

Enterprise Media Beans Core is the minimal base of any application that uses EMB in JOnAS. This core is located in JONAS_ROOT/lib/commons/jonas/emb/emb−core.ear.

The emb−core.ear content includes:

EMB in JOnAS 411 Using Enterprise Media Beans with JOnAS

• META−INF/application.xml, which describes the application components, • emb−core−ejb.jar, which provides a Media Entity Beans implementation, • emb−plugin−publisher−servlet−jonas.rar and emb−plugin−publisher−servlet−jonas.war, a Publisher plugin that provides different media and describes how to access this media through a servlet.

Media Entity Beans (emb−core−ejb.jar)

This is an EJB archive that provides a Media Entity Beans implementation. In order to use EMB more easily, some of the settings have been set to the default values:

• MEB uses the default jdbc connector names, "jdbc_1". If another database will be used, this can be changed in META−INF/jonas−ejb−jar.xml. • The maximum media size has been set to 6 MB in order to work properly with JOnAS default env. If necessary, this can be increased in META−INF/ejb−jar.xml.

The default Publisher (emb−plugin−publisher−servlet−jonas.rar and emb−plugin−publisher−servlet−jonas.war)

This publisher describes and provides a way to access different types of media through a Servlet. In order to use EMB more easily, some of the settings have been set to the default values:

• By default, the Publisher provides access on localhost using the default port (http://localhost:9000/...). This can be changed to access media from outside the computer. To do this, change the property in ra.xml named servletAccessURL(ex: http://yourname:8080/servletContext). Note that the servlet context must be consistent with application.xml. • Other settings are explained in EMB advanced settings.

Additional EMB plugins

The JOnAS EMB implementation provides some plugins that show how capabilities can be extended. These plugins are based on resource Adaptators (.rar) and, therefore, are able to dynamically add the new features mentioned below.

The plugin rar file can be included in an application or it can be deployed directly.

It provides the following new MFB features :

• JAI Plugin: new image−format support with Java Advanced Imaging • SVG Batik Plugin: capabilities for converting SVG to PNG with Batik • FFMPEG Plugin: capabilities for converting video to 3GPP to MPG with the ffmpeg command−line help

It also provides the following new Publisher features:

EMB in JOnAS 412 Using Enterprise Media Beans with JOnAS

• Darwin Streaming Server publisher Plugin: rstp access to MP4 media • Apache HTTPd publisher Plugin: more efficient and progressive downloading

These plugins can be downloaded from ObjectWeb CVS −> emb−jonas/emb−plugins or ObjectWeb Files −> Tools.

Additional MFB Plugins

Java Advanced Imaging Plugin

The Java Advanced Imaging Plugin provides new image−format support with Java Advanced Imaging. It provides mainly TIFF and JPEG2000 support and uses JAI algorithms instead of awt algorithms.

The Java Advanced Imaging API provides a set of object−oriented interfaces that support a simple, high−level programming model that allows images to be easily manipulated. The source code for the jai−core project is licensed under the Java Research License (JRL) for non−commercial use. The JRL allows users to download, build, and modify the source code in the jai−core project for research use, subject to the terms of the license. The source for the jai−core project is also licensed for commercial use under a new, no−fee Java Distribution License (JDL). The JDL allows commercial use of Java Advanced Imaging with or without modification, as long as compatibility with the entire API Specification is maintained.

Java Advanced Imaging and Java Advanced Imaging Image I/O must be installed in CLASSPATH before lauching JOnAS. JAI and JAI Image I/O can be downloaded from Sun Web Site. If the desired platform is not supported, the "Linux CLASSPATH version" can be downloaded and each jar files placed in JAVA_HOME/jre/lib/ext. In this case, the pure java implementation should be used instead of the native implementation.

SVG Batik Plugin

The SVG Batik Plugin provides svg−format and SVG−to−PNG conversion support.

Batik is a Java(tm)−technology−based toolkit for applications or applets that want to use images in the Scalable Vector Graphics (SVG) format for various purposes, such as viewing, generating, or manipulating. More information is provided at Batik Web Site.

FFMPEG Plugin

The FFMPEG Plugin provides 3GPP−format support and conversion for any format supported by FFMPEG. Batik lib is included with the plugin.

FFmpeg is an extremely fast video and audio converter. The command−line interface is designed to be intuitive, in the sense that ffmpeg tries to determine all the parameters, when possible. FFmpeg can convert from any sample rate to any other rate. It also resizes video automatically with a high−quality

EMB in JOnAS 413 Using Enterprise Media Beans with JOnAS

polyphase filter. More information is provided at FFMPEG Web Site.

Warning: in order to provide 3GPP and MP4 features:

• The ffmpeg command must be in the path. • It must be compiled using at least the following options: −−enable−amr_nb −−enable−amr_wb −−enable−faac −−enable−faad. See FFMPEG doc for information about building the ffmpeg command. (Build options are listed at the top of each ffmpeg call.)

Additional Publisher Plugins

Darwin Streaming Server publisher Plugin

The Darwin Streaming Server publisher Plugin provides real streaming capabilites for MOV, MP4 and 3GPP media.

Darwin Streaming Server, the open source version of Apple's QuickTime Streaming Server technology, allows streaming media to be sent to clients across the Internet using the industry−standard RTP and RTSP protocols. Based on the same code base as QuickTime Streaming Server, Darwin Streaming Server provides a high level of customizability and runs on a variety of platforms, allowing the code to be manipulated to fit specific needs. More information is provided at Darwin Streaming Server Web Site.

Plugin settings:

• The DSS document root and DSS access URL must be set. This can be done in ra.xml by changing the properties named publishTargetDirectory(i.e. /var/www/), publishAccessURL(i.e. rtsp://localhost:554/), and publishAccessURL. • Other settings are explained in EMB advanced settings.

A known issue is that to access media through DSS, the media must be "hinted". (see DSS doc) To date, there are two open−source solutions to hint MP4 media (MP4 Box and MPEG4IP), but they have not been integrated into the JOnAS EMB implementaion

Apache HTTPd publisher Plugin

The Apache publisher Plugin provides efficient and progressive downloading.

The Apache HTTP Server Project is an effort to develop and maintain an open−source HTTP server for current operating systems, including UNIX and Windows NT. The goal of this project is to offer a secure, efficient and extensible server that provides HTTP services synchronized with the current HTTP standards. More information is provided at Apache HTTPd Web Site.

Plugin settings:

EMB in JOnAS 414 Using Enterprise Media Beans with JOnAS

• The apache document root and apache access URL must be set. This can be done in ra.xml by changing the properties named publishTargetDirectory(i.e. /var/www/) and publishAccessURL(i.e. http://localhost:80/) • Other settings are explained in EMB advanced settings.

EMB Advanced Settings

Publisher Advanced Settings

The Publisher plugins provide advanced settings for optimal customization of media access.

Priority

The publisher is selected from the publisher registry by matching requirements.

If more than one publisher matches the requirements, the priority of the Publisher will determine the most appropriate to choose. The priority must be between 0 and 100. The lower the number, the higher the priority.

There is no default value.

LRU cache

LRU cache is used to optimize media publishing. It must be sized to accommodate the resource and application needs.

The cache size must be at least equal to the number of times different MediaBeans or MediaEntityBeans are accessed simultaneously. The required free disk space to store the full cache must also be available.

Warning: If there are usually serveral publisher with there own cache, sufficient free space must be available.

The default value is 100.

Auto Clean

When a media is published, it may be desirable to make the resulting link permanant. Due to cache issues and disk allocation issues, this is not the default setting. The autoclean setting must be turned off to have permanant published media.

Warning: If there are usually serveral publisher, sufficient free space must be available.

The default value is true.

EMB in JOnAS 415 Using Enterprise Media Beans with JOnAS

Delete on exit

Published media is deleted when JOnAS server is turned off properly.

The default value is true.

‰PNG IHDR€ä®@òsBIT|dˆtEXtSoftwarewww.inkscape.org›î¦“?WWWS‡#„Bað`ò×£GEÑ)Š¢³´´Ti4šï%| ¦¿———$B!„(rþühµÚ¬¬¬¬{:.H’ðå${öì‘äO!„EŠ±äÏI$B!„(ªöùIšF£éïíí−ÉŸB!ŠœGIþÌŸBLϼ“?S‡#„Bað¨ÉHà¿’äO!„EÕã$ à?’äO!„EÕã `$ùB!DQõ_’?Ð(Iþ„BQTý×ää!„0(Œä¤8Iþ„BQTVò’h4šþ>>>’ü !„¢È)Ìä$r“¿={öHò'„Bˆ"¥°“?P’?!„BYO"ùƒb~ˆµµu?µZ=−,,ÌlèС¦G!„Â@«ÕrèСBOþ ˜'€NNN¯wîÜÙ¬nݺ¦E!„"øøxvìØQèÉóбZµj´iÓÆÔ¡!„BäqãÆ >ÿüó'Òv±(„BQÜH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQÌH(„BQ̘›:€çÅÕ«WY¶l™©ÃBa>>>tèÐÁÔañÐ$,$çÎcÆŒDDD˜:!„OQ\\S§NÅßߟ*Uª RÉÅ5QôIXˆ‚‚‚;v¬©ÃBñ:uŠÕ«W3}útÆŒC`` Š¢˜:,!þ‘|MB! Éš5kHHH0uBü+é|HsæÌañâÅ–§¤¤póæMêׯo´|É’%xzz>¡è„BgÏ¥zõê¦Cˆ$ àC:þ©ü»yóæáîî@Ù²e˜5kC† ¡F†¿©êÕ«søðaìííŸôé !D±! ÂÀÌÌ +++’““133ÃÌÌŒäädt:Š¢V88{ö,±±±øúúúËÆC† ᫯¾âÅ_ä7ÞàÂ… |óÍ7dddä;ÖƒãshµZ’““Q«Õèt:RRR°²²’eµ„¢I(„0pwwgïÞ½´nÝš©S§²gÏZ¶l‰V«eÒ¤IðöÛo3hÐ Ã~±±±ØÙÙ±ÿ~¾þúkªT©Â´iÓ >ñãdzxñbCÏ!蓤:uê°iÓ¯¬M›6²Œ•B!Š IRË–−iÙ²eå9ë–~öÙgO1*!„BˆG'c…B!ŠI…B!ŠI…B!ŠI…B!Š¹ Dˆbn÷îÝ´hÙ ÎÔ‘ˆÇ¦Ó²nÝZÂÂÂL‰â! Å\FFþ¥«0ò«¦ERˆÿ"::šøøxÔ(øF¤‚Æ›4–}ê=“ `vV6ŠJ!+3›”øTœ=IOË >6çXªõ:ì¬lÌ−̹yå6n>Î(÷ÿFÅã“PB`He®œ?‰•µ†v݆ðígøxÊRC")Da {¬qºsÎ.ü`€ÄÛ)ÄüK`E_þÜu–Êáe˜ñöw$ÝI%−9Êáex¡Š?Kéý˜Ök>î%AQ±ômm9Iæ‰^s˜š−*™úôI’Š§êÌ™3 :”½{÷R©R%öïß³³3ÎÎÎüõ×_\½z[[[š5kÆÖ-[Ù¼y³a ä¬Y³X²d †›7oæù¶\»vmÃãÀÀ@>ÿüs:vìÈÎ;©\¹2þù'ööÏÞ7äÂ2vìXfÏ6þA‘™™ÉÝ´{XÛØå+;}òÏ'Z¡©ß22߶·GÌeñÆ¢RQ¡Z8!•ypÙ“’eqprcÜ;−HKMâÑó±²ÖP20”’ú)˜ÞühÖS;!77.Þâ“óè9¡c:̤à f†2G7;FþÔÐ÷ôUm¤g›x;…!/O¦vë*Ä]‹ç³ccg Àöepóòmâc¶ã oLì(½‚H@ñT;`ÀÞzë−fÎœIdd$K–,ÁÁÁ°°0ÆOÆ iØ°!Ó¦MãÔ©STªT‰ääd°°°`Ú´i\ºtÉÐnÎxA€«W¯Ò¯_?¾øâ """øòË/‹uò7dÈúôéS`ytt4c½>œ™oûµK§ñ{¡Ã¢ÅÉÉé'"½xñ"j+ëçn®¿‚¬úá3b¯§SŸQ¦EˆbaÈ·½˜Ño='tdሸûºP¦¦~ÉBs‹Ü!?Œû…öSë•*¤$¤ÒÙ÷=C™™EÞ¡_¼û=Õš–çÔ¸37£ñëEëÛg$€‘ššŠ---Ñòˆˆˆ'ÞÕ¦M€|8•+WFQjµšÕ«W³`Á|}}™7owîÜ eË–äNúàå`!þ®UÄØ@!ŠŠ¤¤$nܸñÈûefýI¿+øòÑ÷}ˆ9“1+ßåðÖ“FëÙ9Û²wÍ}úüë8ÝÞƒ»3mÇGO1ª'/¬eÞ»wmíôœÐÑð{ðý¥ï\½ò'€â¿“PˆçÜüùóÙºukËäÊÌ̤t 7Ç·.ÌW¶u˾}û>7kkµZ®]8EÉ 2¦åiµZ®]Öþ'¢Ïa¥QX¾äcí_THhbåË—ÿÇÁ¿‰~Ñü»ÌÌLÌÍÍ Äééé¨Õj@Ÿ€]¿~GGGœ ûddd‹———a®œvRSSIOOÇÅÅÅPÿÁ6ÓÓÓ±´´DQ²²²PÅÐFRRiiixxxä‹3Ο?Ï… zô(wîÜ1Ę™™‰™™)))èt:ôo¤:¬¬,ÌÌ̸qã%J”oï…dÁ´÷9}t.îÞ$Þ¹Åð™kP[ÛнQ ê6íDÜ+\8s„·G|ÃÚ%³ˆ‹ÁÓ'ˆ÷§üÐ'ŠSwÄÌÌœó'òÁ§Ëð+U>ßq¶üºŸ¿ý„ *ܸú#¿üÌÌ GOb¯] öËéðÆP.9ÂgGâ( ÿ=ó§¾GÌåshìÉÊÊ`èô_ò%›™éLý°3éi88»óîØo¹—–ÊÀW+òÕªsÄ^;ϸ~ͱ´²!>.†Ñ³7b-É¿úŠx>½ôÒKøûû3aŸ¬¬,ò—ÆtèÐÁèöc†“ŸZ`çƒÿ‘¥¥Vë*¤fï‡O¢ÛØöØ:iøæÃ¥” )ñØ à˜V}µù±Àëçb±s¶•P/−[¶ä“O>¡B… èt:¸~ý:{öì¡{÷îT-Z•øøxú÷ïOÓ¦M™7o_|ñeÊ”áäÉ“,_¾š4i‚——‰‰‰¼úê«y¦|)S¦ Çô“ÏŸ?Ÿˆˆ:wîLŸ>}hРݺuãúõëh4T*Ë—/ôÉæk¯½†J¥âÀ,]º”J•ôwš−X°À°ßâÅ‹é×O¿üPN}NÇÙ³g‰ˆˆ`È!lß¾Aƒáææ† /^dÆ y’UñèïÿËg1iá.–ϟĆßÐ*B¿®sƒV¯\¾Kfâû™Cùtñ~E¡{£ÄÇÝ@meCâ›Dô·_0v¬eñ—Ãùhúʳ¢¨ cûöíìÛ·}ûöñÞ{ï@ýúõi×®–––ÔæŒÙŸXvþØl;E«¾áػزéûÝØ:i°wµÃÁÕ–ã»ÎP2Ä‹cÛOáäá@ÙZ¥¸þW,'¢ÿ¢|ÝÒ†i[nþ“ Š¾Ü|¿ÜIœnÇ$pô÷SXÙZQ½YÌîÏÝw=#ÛNáê……¥nö8¹çÆ”«Œ‹—#G?Eb\ uÚVÅÌÜŒ−?Fcna†“‡=®ú¤/ýn»VÀBmNµ¦Œ~9?wøÎœ9p‘ì,−5šWÀÜ"oÚsãâ−Gvf6a¯T~fÖ —PŠß~û7ß|“÷Þ˹=66–)S¦pôèQÔj5ëׯgôèÑ,X°€_|‘òOÈ[»vmvîÜ @xx8›7o¦K—.DGG³hÑ"–,Y‚¹¹9›6màwÞaÅŠ´hÑ‚Û·o3räHÊ”)ÃÆùøãY³f Z-–ü‘èèhnÞ¼I×®] @éÒ¥?~±çñIÉbŸ}füƒâŸÖ¾ð×ÙBåìŸûˆ‹½ÂÄúÉÀ“nT!%)µ• NnxûZ¹sÊ\1_/Û¥³GiöêÛXXª)]1Œ §ãá@ÉÀ2hìô=)gïãÊù†8ããn`ecË¡Ý¿±þ§¯èòö8Îßǵ‹§ õnÅ\æƵóùÀÊVÃÂÂÒó® K ãéÌ=¯K—¸téëÖ-ÃÉɉ¥K—’™™™ç柦M›Ò§Oæ͛ǪU« ÛçÌ™ƒF£É3¹|xx8ýû÷gÑ¢E†/X_|ñÞÞÞ†ÉÜjÔ¨ÁG}ÄŠ+øî»ï

EMB in JOnAS 416 Using Enterprise Media Beans with JOnAS

Û§L™Bpp0¤¦¦P¥JFŒÁªU«˜7o¡î¸qã(W®Ý»w'>>Ðÿ]NúˆÕjЯ_?®^½ @@@Ó§OgçÎ|ú駆ºï¿ÿ>uêÔaàÀ\¸pwwwæ̙áC‡=z´¡nß¾}iÒ¤ Æ ãøñã€þKè‚ 8~ü8Æ 3ÔíÙ³'-Zµb̘1üþûïÄÅűsçNjÔ¨Áµk×ò}šeË–Á˜1c W"þ‹Ä[ÉÜ»›Á˜âc‰»z‡Ìô,b/ÆñB%_>ë³’¥KP¶v)¾ù3Õš–'=−[G [ÎÜã°Ö¨Õn5ZT¢b½ÒÌùb"ÂhÙ;œSœgú› hÞ«>g\dÃÂŒ\öw¯ÜfpÃÉ´î׈-K¢Ù¹b?}¦v¦Ö+UòÄwý\,£ÚÍ ¬UeÜìX0|9uÚ½ˆƒ‹−G·ŸæÈï§è?+Š›—o“•™MìÅ8üBõÃ'漌:m«r|×Yvýrˆ³»å;ÿÅVwõõ_«Á¥“1ü¶`;cVæýÌùý§?P™©èø^Sæ~¸”wfFâWÆ›šM¥T?Ü}]ø~ÌJÊ—dà×ÝÙôýn\J8вw8s>øÖ¶VTnX†?ÖãØÓô™Úå?ÿß= ’ŠBѵkW"""øùçŸéС½{÷æèÑ£¤¤¤ðÚk¯ú˹YYY†}jÕªÀŒËزe Ë–−£aÆlÞ¼€0bÄ>LHHVVVì۷ÇÞ`¯_¿¯¯þîJ'''Ê”ÑßZ§NzôèÀ¦M›pqqáÜ9ýå¸;wîpäÈ*V¬ä®biiIÅŠyR?S}åÊ•±±±1Ô™93ÿº²EÝ°aÃŒÉ-PãÑØ9R)¬1=OH ß•’ûMúÁoøiw“ÉÊÌÄÜ‚äÄÛhìá377´iecÇíØ+$܉Í×¾-ɉ· ¿'Þ¹‰ƒ¾§ÃÌùïÕ«iiúKï€ÐÐÐ'îæ½êÓ൴êNdÐ`’î¤`ïœÿ’pý×jÐîÝGŸOõW²2²¸v6ÿû @Ë>ᄵ¬DÝöÕòòdIÅÃIOO'!!á‘÷Ëyƒ|ÚÔjµ!ÞÛ·s?Ð^xáöîÝË©S§:t(ñññ´hÑ‚àà`V®\i´− ý‡m—.]xå•W077'<ÆÑÑ‘Î;3xðàùäfÏMhh(þù'‰‰‰T¨PíÛ·söìYæÎKÕªU™8q"“'O~ÒOñsÏÖÞ‰ñ v°aÙ×Ù» Ï’A4h¥ïh×}ˆ¡§Ï7¨,j«Ü»v´z'7,,ÕDöŸˆ_© ¬ûßT¨Ùˆ—Ûæ_ TQFÍÞȺ¥_òó·ŸàåLõú-©X³ÝMeëªo±spaÜÜß1·°ÀÑÅ“ðWºöwv÷bÌœ−l\ñ ûw¬ÁÛ¿4¡Uêæ;ß åúù¯lùe‰wnâWª¥_nU«Õsþ–áνb¨wîð凊ëY" 5oÞœæÍ›X³ðã¼)S;Ê/è…ƒ›~œe@ù’ôœ˜;'mÄÇ- SË(ŠB¿™‘Üô'o}aX£7°‚/Ÿíø˜#¿ŸäÒ‰ëx¿àÎȶ3ðð˽ʓÃ'Ø“¾ÓrÇËu|¿9vNú^•JňeïàêåÈ{sºçÓŒ®¸ûºð箳ø•õ¡j£‚'ÿïòñ+(Š‚o¨Õšê?¯×étñŠ¢´j9«KV%X«Óé¶þÓT4ØÚÚÒ¶m[FŒÁ„ ¨^½:QQQtêÔ —o@yŠ¢ R©077ǵZ••U¡´miiù¯ul4öØÚ;a-±/”cŠçSvB Ú» ˜» Xä}}jSn“r ÷Påö1è²2@§C±P“uç*Š¹Ó{·û;e¡ËÎF1·E•¯¾¡Ì{dݺ€™³*+»S¥*°Ð¡O»^À]`3ÐlίMÙ@¼¢(ý€™Àmà*wøCâšOH\ó føL9ù4Ÿ>!Š”œ¯gNÀk:n©¢(æ@ EQj¢OþVètºö÷·ŸBßÛ6}Âgô×ét3EY>aûW÷Û Ü|u:Ý=EQ¾ÞP%L§ÓíAßëxˆÐét7E±¾}šüç¶r¤§§“”””§Mc“€fff²råJV®\‰³³3:u¢oß¾”+W®ÐbϾ;w[ZZÒ²eK"##±µµeððÉ’ü‰¦Í"nnO2oœÅþå·QVãÞ¹hté©$¬ù”»‡V¡©Ù «º$,IÜœxÛ™[n3iI84Hâºé$oú ›J−°©Ü‚øeÃI;±Ûº¯“sšì„ÄÕ; ˜Yvl «Y ûÆïä 3eçw8µbe‹î^*f¸¼>‹Œ ûIÞ¾›Ê−±®Ð•¥ÍS}ú„(jrÀ+:n)ÀýK°WEiq¿¬†¢(‡ï?vG‰ØÈ™CbíýŸ«yÈð$ úþM 9ïå€=ÀF +pUQ”íÀ÷è{EP`v§V«_+UªTÁñëĉœ>}ºPÚÊ‘ššÊ?þ˜§Í‚Æq˜››S«V−êׯO©R¥ −ñì‹‹‹ã«¯¾",,ŒÈÈH^{í5Ä۶m3mpâ™qí™1g° -‡S‡±ØTyÅP~÷ÀJµ—Èé(æj²cIøy iÇ6b[«‹¡S»Q˜9x’¸þs²b0wõDzdyîÚÚlÒNlÑ·_¹åý¶À*´º¬ Ô/Ô yëîY—/tëýêÀól³-Õ…T 5ÉÛbéS.O¹\õOõ„BüwA”ºmÊm´÷’1wö1Ìõ§XZãÚsÎSѦÆcî\XµÈó£MyÚòýâF¾öÚÄ©ÝH£Ç¶oüö/¿MÖ« ÓÆÚ¼Öè~Š‚Käç¸D~þ°§ûÔ\½z•«W¯X~üøqR“Ò8}Îhù •|%9,Â’““9uê...EjÎÞg}%!„O™ÊÖ¥À=••]¾Iš ¢ÂÜÅ÷É´mBsçÎeåÊ•øûû−ÏÌÌÄÛÉu“öå+Û³3ši;?Ä7äáÆZ ÓÈÌÌ$−−ÍÔaäQh N§+°§P!„ëÓ§}úmmjÕ/zcËŒÑétܺz÷’.Ä^ŠÃÃÏ•%“WcieÁëáWÆ‹F‘µ™3x ™ÙXÙXÒgZüB½¸tò:+gnDe¦âøÎ3ÌØ=œ„›Ixø¹ÚNî"B!Ä“‘ÉÄ®³¹v6–¹−åÀÆãÄœ¿Eôš#Œþ¹?½?팛3c~Àô߇Òc|f¼ýi)÷X¿`−zÕãëCcQ[[2íÍœ9pù/cÏêçzøÿ#—€…BñÄŒló9¯¼ÝˆÝ¿Â+ÈæoÔ7”5ìf¿hf®bј_8ô :-–‹ÇsÇEWõ'°Bîåÿáÿ{‹a¯|FïO:ñã¤Õh³µÔnýàlsâßH B!˜ú¯Õ`ÃÂT}¹,{V"þf’¡Lm“{óʼ¡Ë°wÖ0ö—wûë@²2²ŒÖ°ñOl¬IºBjÂ]J¿èÿÄÏãy# B!˜èä$ÝNAã`¹…9«foA«5¶F…Þǵ¢?ûÖeÌ/põv~Rá?·ä°BabS¦LaáÂ…F˲²²H½›Š½U¾²Ó'Î ŸN·h«Þ´‚áqÎ¥\ŸÒ%pt˽c>µZÑò‹/rñâÅ÷?qâ) ©ÞvÒhyHõ@¬lÔ…ª(F$B! Ê”)Cƒ ˆŠŠ¢~ýú(Šb(_¸p!kÖ¬!((ÈèþYYY”ö−ÇîÙ§ò•mÛò;Ÿnÿ PÇv+ý OOùÏuþIܵ;ŒëüŠ¢Ðkò«Ìùà|¶ýãÇnoáÈø…zÑ Óã−÷f¥aÌÜ3µµå¿W~NH(„BXøkšõ¨K`_¾û C÷%5!™¯Þ[Œg€û;†‡Ÿ+.êý\ö JXÄ%C}''',XÀñãÇÎl˜¡nÏ=iÕªcÆŒáàÁƒh4~øáÎœ9Ã|`¨E»ví˜8q"{÷î5l_¹r%×®]ãí·ß6lkß¾=‘‘‘̘1ƒ−[¶¶ÿôÓOÄÇÇóæ›o¶µjÕŠ={2{ölÖ¯_oؾpáB,,,ˆˆˆ0l §ÿþ,Z´ˆåË—¶ñŸ»»Ó±cGöºuë2hÐ –,YÂ’%K Û§OŸN@@¯¾ú*T©R…#F°jÕ*æÍ›Grr2qqq$$$0|øp¬-õÉK¹råÇn±±±FÿïöíÛÀo¿ýÆ®]»;v,åÊ•3Z÷i9sà"j݃ôÂÁÕøØDÞ«?‘ù'ã;Ï0ü•Ï§;ŸíƤȯٸh¯ômHƒN5Ð8ØÐ~@n\¼Å…ãWygV$}¦vaÞÇËøqâjzN蘧mV˾µGiÒ-.‘#ÚðóÌÌýp)ïÏ{#O½óG¯zÛ²8L¿¦ðºyÛ¹›”ÆôísóòmÞ(ÿ1õ:Và¯Ã—ÑfkÉHÏbÛÒ}ÌØ=œ×Gµe|—¯ØüÃîüðCþ9ã΢¢¢HNNÀÒRßÛáë뛧nΗ“W_}•Æ`n®ÿñòòÊS××W¿rCûöíiÐ Ax]\\òÔõöö E‹T¯^Ý°ÝÜ܇¬…x*• GGGJ–,Ihh(ÎÎúuQË—/Ÿ¯®““kæÿV¶lÙ|ÛìííÖ É·ÍÖÖÖhÝààà|Û¬¬¬ŒÖ Êw#„Z-6Z7 €€€€|ÛÕ−Y²$%K–|¨º>>>øøøäÛþ`bšÃÓÓOOOQ«ÕXXXš¯~\\\ß---iݺ5QQQìÙ³///*V¬˜ï¦´ö›m\9}ƒaKÞÂÊFM²‘•‘•§ÚF-£þî#Pøì IDATæœûZ,,õ©…J¥ÂÂÒ•J?㜹¥yëûêtºëÛR©CÛ–÷/Áê ^Ø@e¦2Ä™‘–ÛybniNfz¦á÷Œô¬|ûæÔËa¡6';[ûïý?{wUõÇqü=3 Ì° â‚€"¸ƒâ¾+**澦fje©e¦Yi¶©Yi‹š™š¥–Vš»¥å¾æn*.ä¾" ¢ìû óûƒã˜Êrù¾Ç'æsÏýÌ$òå.çCR]ºt¡|ùò\½zÕü¨(ù¤¢äøþûïQ©T´lÙ’ÁƒÓ·o_óÙÁC‡ñÑGùþü÷5 $%'¡wÈ>ÕË•‹W)¨µ€c£â±±µÆFoͱíg¸qöV¶>þ−ªâß"{‘ÿ¸n_âÄÎPÚÔä…»©T

EMB in JOnAS 417 Using Enterprise Media Beans with JOnAS

½5‡¶4÷IKI#59ËÐv@S~ÿn·y½às÷)ÃÁ!ty© ›ï5ooÚµ.«gm¡F_.¸ÆÙC—òœ»8“°˜¨_¿>îîî 9ÿÆ"J¦Üæ Baaa4lØÙ³gçxïo¼ñÐ'€ÿúë/Þœ2†IëGæØîôAäÕý)jºhËô! Õd õ‚jÑù¥@¬u™g9k5Ëýòi©rncñûWqèRÎÉ|®l%7ôv™gõ¬uZ‚ŸkÉÑ−§Yôîj¼j¸3jö Ç/UÖ‰ÈëwÓr*¥+”bôÜÌõ‘Ý}ÊPªlæçðì=˜5|1Û–î#øùVTky¦¸e¯ÄDÆ1ãÅEÔjæKíÖÕ±uÌüE»zcÔÕÖ:−ÕTÊ’ùßgK)‹‘û÷¾!„(><<×vWWW´ÖV¸”s.ˆxYÜ8— 8§Ò>é 0yÍè·w%(Ëë6¼nþºaÇ·$tÒÂüµK9çlrdÿ©¿ÍÇDÅ›ZéB!„¢pI(„Baaä°BQÄE†ÝeÙ´ JÇáZèM¬±S:F®¤B!Š0///*»WaË܃Y@!„¢swwgß¾}Ì=›Ë—/Ë‚ÅÌý¥‹)…Bˆb`ôèÑlÙ²%Û²r¢èÓétJGÈF @!„¢˜èС/^T:†xEmyO)…BˆbÄ××Wé¢i`„B!,Œ€B!„F @!„B # B!„…‘P!„ÂÂH(„Baa¤B!„°0R !„BX™º¸xñ"¯‡ÁX¼Ö,_Ö¯ç|…ÒQ„dÂÄ Ü½[Ü–¢¢¢8{ñ:ÏŒúDé(,!.š…Ÿ¾J‡öAôìÙ3ß—À‰ˆˆ gﾤŠWQ|_o|3{{{¥£‘'ó¿™ÇˆYý±Òj”òȾ¿cº‘™3gâää¤t!!`1áèäB½æÁJÇxdÑQ·øõ×_ñðð iÓ¦hµÚ|?99™ëa·Ï}E¾YX"ï²pú+lܸ‘=z`cc£t$!ò¤u߆X묕ñÈ–OûóçϳvíZzõê…£££Ò‘„(tRŠwôèQ<==©X±"juþÝvjm£Ã»Z@¾WX´Ö:àAqܤIœšâsöDˆ’âòåËœ>}šúõëË/bÂâHXL:•Ëf`móoÐF£‘ÔÔ4†µ/—-−11Ï—£BŪëOnݺ…§§ç#€©©©$''çÚ‡Ñh$1>†§§'^^^JG"›ÐÐPzꩇö1`Xµ÷@•½-ÏøtÙî±{þ¯+”-Xšó]Å¡”−kypjï9¢#âð©ã‰o@E¢#b‰ŠG¥Vs9ä:mú7yìcEGG/ °8Rƒ?þ˜#FÙt’goáêîÌ‚7—ÓnPs:iÁ©½çX8quÛÕ¤rmObîıý§ôÓ‘…WòÜÔÞùzÕAˆ’D ÀnùüÉÔ¬Û‚{Q·HKI¢iP~Y0…ŸæÐÎul^5ŸfíûàTª {~ÿ‰>/¼MbB,ÛöÄÙµ,üò5«}ÂÓÃßçú¥3,þüu^xëK‚z}£w#o*õv›!=Ùï?ǽ;á,Ÿ?™¿ÿ ÀÖ5ß²nÉç´ê4OŸZ¤$'ЪÓ@z?ÿ6¡Çö°míw\8}˜y¾DyO_ZtìOøµó|;íUbùbBRSr¿„−„¥3Œ¬øüúïÌšY›éñj{J=˜2ÊÝ·¬ùëus¶2©×ll:ÉÕ37‰¹ÿ ŸO™,ãv%ˆ¿¶œ¦fS_¢nFsöðå‚3BCR–`ñ±w±sp;'ó)ÿFm9¾3±Ñ‘´é:„S‡wpòÐvê4`ÞÔᜠÙOõ€fÔ¬Û’äÄÿØ::—Îr ½ÉI h¬´ 餓¢'5%™ÏÞêKã6ÝY³xN.ÔnÔÖÜÞgØ;øÖj@©Òå¨êß„ðkçÙ»y9j'?(ˆ·éA£ÀnxV®AE_?ªø7fÁ'¯Ô㦽ޓ„¸h%ÞEÆJÃç;CÍíjõƒ› 7−Úø…Ã:¹uÛÖÌ2ê_gÚS’Rù ×lÞúá%æ¿þ3M[ÎÅ3G¨×¼z[¶®ÉX9 —ò9ßó[½±óÆþÄêY›Yóeî÷#š2LŒÿá%ªÔ-È‹ÓûѨS‚Š.D±'÷ëÖ-ãêÕ«9¶eddn0`e•ý>–ð›7rS£Ñ0|â\’ã©U¿I qԬגÛa—ÒäSªø5Âtúz;:ô~‰G=E¥ªu²ñû7[{GÆÏXƒVkÍÄYë±µ/>siéí˜øå¯Ìœø /¼ù%k¿Ÿ[ùŠÔªß*[ß‹g0nÚ2ìœ9}tW®cÞ¸ü7{7−cô”ïùò½!L˜±'—|B¼°°0fÍšõØûíÞ½×Æÿ=÷§£;Ç̉⽪»ðÒ§OSÎÛÍÜçÕ9ƒ9¸ájšàç[qãÜ−j·®wíPéíuèí3ïW¬\[¬âa¤,zôèA¥J•rm¿téËWo Ç·²µõù¥J—èø÷ »ûšNoǪ#ÎL=ÿÆŒ,ý»>3†ÖŸE«µ6ï Ðú©ghýÔ3æ×ZëÓN£u¿ÿ_§·ã-ÏVa0¤› 圴ïõ"ã?¥B¥jÙÎþ›[y/Æ~üF£‰³Ögù|„(ÜÝÝÎl)))¹ö™4eÞîŒæÿVqm¬¥Nà“]~ýÿâM£QÓ¼{=óëê +àì戳[ñùÅSˆ¢D À" €€€Ü'4>xð ¶î§m·¡…–ÉÑٵЕ“®]»>´(ŒŒä½Éñü_fkR¯*U{¤ãh¬¬ÐXe~Ü/vç¬ý;KŸgG³£³/Ã×}ð¸,¯uúÌØÕjyâP” eÊ”a„ í3í³Oè÷f'yÒVˆbF @Q$ùøøàãã“kûÕ«W™öÅ·y¼)_„B!!„BX)…B!,Œ\.ÓÖ!ûZÀ±Ñ÷˜¹â$Þ%k®«¤¤$ââârm¿sçC:ÑQ·slwprÅJûßO !rwêÔ)Z¶lùÐ>))©ô+;TÙ~vR7zéXPñ„y `‰}úô'^ ¸$Z°`S§N¥t霧¡ÉÈÈÀ˜’ÈÔ‘ÙÚn‡ßäýy[ó´ðñ[¨\-.N.nÿÝYˆÊh4À®]»{ßY³fq:eþ‡Bä )−Xrbþ'NfÚ¸^æmZkf-Q0•–)=Í@jRªùµÞAF#ç/„È )−\ë΃²-WëîUE¡4EGïç'Ðûù‡O€+„(X 1‰¼ßãK®œ ÃÉíÁª?“V¿J¥Z Í`0’šŠÎ.[Û×òtܦíz‘–šBÄÍ+xxWG•Ã“|–êÈîß8¸c−Í;ô£V½Vܹ6ËRxBX‚ëׯ3mÚ´\Û jþïŸýûöS®¹m½cÙA¼j¸óù ¨ÕrÆOˆü$`ЧOªWÏ}— .°pÉ/ô~áÝlmƒÇ6ÁµL…'>öm«Y2{I ±|·9Œ[Ws/‚nƒÆ>ñ˜ùeÕªU¹ÅF£ñŸµ€³¯zìØÑGZ øaþÜü ;~ýu[~•z̓ùcÅ\ZtìF£ùï„(*T¨ÀèÑ£Úçíwïì怷Ÿ‡B)‹???üüürm?xð k6î¢epÿ|=nFFËçObÆòã|=é…Ì, Ûðí´QŠ€={ö|hQÁøwൠŸ8—ðk牸y§RnÄÇDáìZ6Oc Q\¸¹¹1f̘‡ö™ôáôxµ}¬\-ae>|úkÒR ”vw6ooÐчRÙ¯ˆ!€,=5'ײèmíÍÛŒ†t4åÿZT¬X‘Š+æÚ~õêUlí¨×ZªtŒ"IokO½æ0¤gÎ?–‹ƒ“©„(ù*ÖtÇÍÓ×òÎöϾ¤£ƒ‹}{ !‡€.:ê6»6.å^d8` F@ šµï£l0…]9w‚ÏÇ÷'91½]æ“Æ2´…ÃÝçÁƒV‚k+˜Dˆ’K @ ÷Î -hв Uj5DõÏT e+x+œJyë~øœÞÏO m·¡JGÂb…ì>ˬɲMc¥¡œ·=_ ¢rm/…’ QüIhÁR’±µwâù7f(¥Èq,åF¥ªu”!„Es÷)ƒ- =FQºB)ι̑ͧiÚ5€ŸËìýïÉÓÀBT¯Ó”¯>x?·üB¯¡ãyzøûJGÂbh4jË𶠧¢x“¶−XFFs?| •JÅá]ëÙ²æ[NÙɯK¿P:šâîþÒe=ˆŠãbèQ¾ßÁÁkHKMQ:š#æN'výÍ¥ëÜ KJˆÅÖ>sbã}[W2ðåñò©ÅÜ_¢çзN§,µFCbB,§ï YPô¶ö”.çEb| Ö6å”'„E¸uùæï0¿¾Ñ˜ÁG^Go¯S0™ÅŸ€ÌÎÁ™{‘7ÙóÇ2.…þÅ«“s'ü:½L«Øe0S_íŒJ¥fÚû1Ü»„“K¥£ a1j4öáÝå¯dÙöÙóß¡µ–‡?„È+)−˜J¥âÅ søsórFMZˆVkÍ-ëhjá«€ÔkÌË¡·s@«µ3Ö¢VË]B(IooÃ…c×(]ÁEé(BkRZ8¿-ñkÐÚüº~˧L£¼ƒÛpqs'%9‘—ÏdiS«5T¨XU¡dBX+§ÃØöã~óëˆkQœþó1º·¿''vþeÛ½Û±xþkj!Ä“‘ЂÙèm±µw$−5k›Ìu5ïܺN¥ªµsÝçú¥3ìüm {~ÿ‰{wnfk÷¬\Czéi)€ £ÑHzz:©©©¤¤¤äÛ¥¤ÔÔÔlÓ×䇄¸hÒÓRiÞ¾?}ý.ÝŸ‡ƒ'mÇÅͽݣ‰ñ±|;m{7/'Øû™ÃßÿãÇçGüÇÖ A ¤È±EñÑ¡CvìØAbb"K—.eéÒ¥xxxðÌ3Ï`4 츶:¶üð''÷œ£\¥Ò\ ½IJb*¿|ú;=FÉÓÀBZÊÐ×?gÏ?³ó·%\="[¿Î;³hÑ¢'G»víRìØ"…„„pþüy¶oß½½=ï¾û.·oßfþüùæ>²jÕ*NŸ>mÞþî»ïÃœ9sÌÛZ´hAPPÑÑÑÙÆôéÓÝl*†¶ hP3]ìóíý8¹90쓾æ× :øeiwtÍ¿c ai¤´@ZküæØÖ¬}_ܽªdÛ®V«é;ì‚ûäÏÍ¿°{ãRÎöö™E“³³s–í*•

EMB in JOnAS 418 Using Enterprise Media Beans with JOnAS

++«,Ûî¡Óézܲ])W©4¶ï÷¸ÊxºR¦¿+ù@H¹Jnù:¾–L @ dm££epîó>Œƒ“ ú¤S¿‘„_»À®KÙ½ñG"ïpíâiÒÓs?CX\ܺq‰»²lS©ÔÔªß*OãV¬âOÏ!oqòÀuò4¶U«V5ÿ²åä䀫«+#FŒÈÖ7((ˆ ,Ûœsì›Ó½¢M›6eðàÁŒû−ÞY6²À§fy¿Ç—,81µ@!„%‘ÐÂM}µ )É Y¶5 ìN·Acÿs_÷ŠUøòŒœÌßÇÿdç†%ìߺ’-k¾¥i»‡?DRÔ ÙÏѽ \8u÷ŠU™²`{¾Œ¯R©pww§I“ÀÛÛ›Aƒ1xð`|}}˜ðÎx%£ !€îù7f’‘‘ywRB,¿ý4‹ÊÕë>Ö*•ŠšõZR³^K^ÿN.ˆ¨…*°Ë³vyÖü:5%™o(cÙÙÙQ½zõ[ˆ¼Ú½{7þþþ|öÙg´lÙ2ßîã}\]G´Uä¸B”TRZ8÷ŠYï÷{vô4~û^®÷þkµê·":J™iM ŠNOÔíÄÅÜÅÑÙUé8BšÖ-[Óºuî˲¬“ÉÄé}°/eǹ£W¨ÖÀ[±,B”$RZ¸ô´Ó©¤$%°kãÒŸÛ«88²gÏœÑd2qýâ)ÔB¢¤ødÞ ú½½ |˲zæ …{c`’“âÐXiñð®Á‹ã¿R8•òœ]Êâá}ÿ²læ%î€{˜·}úÜ·œÜsºmk*˜LˆâO @ ÷åªSJG(’ªø5Ä˧¡Ç÷’œ‡wÇP‘7:{®îÎY¶¹º—Bo/ß‹Bä•€îÎ-ë,Ÿ?‰‹g`£³¥iPoº~Ãâ/߸ʇ¯>…OúØ;¹ð㜉´~jO_éhB”x×Borùä ŒÆ ~»»á1”-Tšk¡áœÚ{~otR:¢Å€nú½ißs^BRB,«~̺>£×s–=µÃº%ŸóÊûßQ§IæÛ6ã;B1¤iØÑ_éHB”8RZ8g—2œùk¼«›_‹L—þ>ÆŸ›–3dì§JGÂâÔm[“Ôä4νBrBŠy{µÞèí−÷T!òƒ€€=¿ÿD»/HøŒ†t’ã”!„Eºy1‚7ƒ¦SÞÛReÍÛË~ÒO @!òH @!Boçˆ{ŪJÇÂ"þã$]G´eÀ„.JG¢Ä±ìÙ~…Y·Áãðô®¡tŒ"ãä¡í$ÆÇâY¹ÝŸ}€=¿ÿ¬p*!,‹Ëª$Å%+CˆI @ ÷Ù[ý¨P±*z;®œå»O_S8•òìÙ@b|t–m¿ÿ2G¡4BXÖ•;JG¢Ø“KÀ*9)”¤’㉺ €ÉdâøþͽÒEÌÝ–Íû€³!û‰Doë@\LVZ™ZˆÂtxÓIB\äé·:g¹ÐÙÍAÁTB” RZ¨mk²ã×ÅDܼ”W‚ÿ٪µL‹ûzçû«×yƒK!×ùhà¼,Û'-~•Jµ;'¥ã avôçû³Ó•!D‰$O[°”äDÒÓRé9ô−ó½neÜ+yëšÂÉ”}‡ÊÕëfÙf4P«å[F%üÿzÀBˆ¼‘ŸfÌFgKB\4†ôtó¶³!û©P±š‚©Š†z−âç¹ïEjJ;[€ÞN>B G6T:‚%Š\¶`*•Šà¾#˜ø\ ⣙÷ápΆìcÊ‚JGS\`çAÄEßaÍâé$ÆES½N3^ûp‰Ò±„Bˆ|! …ëØg8~ Ûp.d?Ö:[^xs–ÜãönƒÆÒmÐX¥c!€'¦*AˆE @ d4¹qÃüZ«µÆ¯A ‰ñÑddqprQ(²Ö/Áµ 9_jÒXiyåýo 9‘–ëZèMv-8œe›ÆJM9o7Zöj€^Û›õ¦ç7 1QÑáW¿5•kæئV˼cB\!æN]zPéE’OÍú\9‚[y/ìK)œHËuùä º oC÷—Û™·Mî;‡!“{òÝ„\~”.ç…•6sY¥–Áè?â…“)+>ö.Uüqõ_ËÂYYi¥¢Ý Á§Ï}Ø["ŸIháSFF–m6:[…ÒÍÛ÷•bO…yÕpÇ¡”−z{QáÑl^¼—€65¨Õ¬ŠÒÑ„(öäæ/ çìR†ˆ°Ëܱ'—2 é éJÇRœ!=Å_ŒcxçÊl[·ˆÔä$~6VéXBX”ýëqpà f _̽۱|þÂB¢Â£Nù£ÑÀ+³~ÉçJÇRÜú¥_`m£ç…7gaHOÃFoËÕó!¤¥¦(M‹u3W÷R$Äwót'>5êsýâi…“)ïòÙctì3-µy›NoGJR‚‚©„°,^5ÜÙ±ì ?ô+-ú4 %1Íì)„ø/RZ0•JF“õ6ШÛ×q,å¦P¢¢Ã»Z]l_c~~íÑQ·p,UZÁTBX–ÕVV8™ÅŸ[;GT*»6.å¹×¿àÙؽQîuKNŒÇÊJË_þNƒ–©Û¬#e=*{O¡BQüÉ%` ¦ÓÛs7"Œ{‘áÛ÷FNó ã¦− úN8ή 'B!òN @ ¦±²"¨ç ¼?¼]¾†ƒ3ýù¾µ*MqOõEér^”.ç‰wµR““è2ð5´ÿ¬—,„BgRZ¸®ÏŒ¡ë3c̯[u `š¢C¥RѸMwók½−]U0‘B‘ä@!„B # B!„…‘P!„ÂÂH(„Baaä!bÂh4£tŒG–”WàÇÈÈÈ(VŸÉ}ɉñJGBaá¤,ôz=7¯œåån¾JGy,Z«‚[;W«Õ’{§Ø}¥cºKéâ ÒÓ;ö]{Yºt)§NR,Ó(JßB(A Àb" €÷Þ{_ý•ÔÔT¥ã˜Œéqlã?㟠¸B(G @!D±voÅ;\U”³{³µ¥…âú¨òæ?1¿~’ë8©‘|fGÎ…d.öÿÌõQå‰ß³ø‰²‹‚1qâDà»ï¾S:E’•Ò„¢ X¹xâ:di×CˆßùíCû:vxcB*µü³XÜ−]º”°°0V¬XÁ°aÃN$DÑ#ÿÒ !e2¤‘rn/j»RhÜH ֽ݉Ö>ÈH¼GêÕãX¹x¢−_ý0ÒoCë^«Rþ=ɧ·’‘p}í`ԶΨíJaßl IzÇ\ Àô[ç0Ü Cmï‚ÚÞTªÿ ˜Arè. ·Ï£²ÖcíUëŠÙÆI9»‡ôÈKØtFãXÿ¿={–°°0ÜÜܸwï{÷î%%%N—çãå%—E\B(*#)–ÈÙ}¹»h8·?iÇÝÇpûÓNÄïZ@Úõ“DÎîKüîE$‡üNäì¾$‡lÊ2NÌoÓ‰üêi¢¿Ì-Û‘‘÷HÇßñ ‘³ûšÿüÿ=€™Ûûóë'Üûåmn}ÜL¦,},'bfîý4ÛŸu~轆EÑÛo¿M@@/¿ü²yÛ¨Q£`üøñYú®Y³† `kk‹V«¥B… ôéÓ‡äää,ývíÚE«V-ÐétX[[S·n]~úé§lÇ~óÍ7 `ôèÑ,]º___¬¬¬¨Zµ*!!!ý^¶nÝ @«V-¨S§)))ìÝ›õö€Î;ÀW_}ň#Ðétxxx0eÊ”,ýÚ·oO@@óæÍcØ°aèt:¼¼¼øä“Üo%¢¸PQ$¤G\ÂuÈʾ±ÔVÄnü4[¡õP*¦þ…m@g w®xpù#íæÜã]*||mùªÙÚŒqwH݉®js„‡‡sýúuóY³É“'g;[póæM{î9®\¹BJJ ;wî¤bÅŠ•Ï`0°k×. ³lÚ´)½¼/!!îÞ½KÆ™ÿï¾þúëlý’““9sæ QQQdþÿŸ3gÎce¢¨‘PQ$¨mìÍ_«¬m¥e/ÈÈù)]µÞ1ó¿:ûÜ÷}L*+ÊYm§H ;ͽ_ÞFÜÜÜ€Ì3h}úôaÕªUÄÄÄо}{sxãÆ N< @:uضm›6m¢\¹rÄÇÇ›ÛÿÍÃÃ… R©R%¬-- Äßßÿ±òÔ¨Q^}õUó˜F£Lÿ#Š/)…EBúíó˜R™ÓI»yT*4eÁ*³¨2ÆÞ íÖÙ÷O»òÏO q*knÓØ»f#âRöÆdÂÚ³6n#—âñÅœ:½NFR,ɧr>£TÒ Ê„F°zõjúöíK¹rå=z4éé™÷N†‡‡›û¿÷Þ{têÔ‰N:ñÜsÏ™·ßºu+ÛØUªTÉs¾û—-¬¬èׯcÆŒA¥Ra2™Ìmÿæåå•ík“É”−_NýŒF#‘‘‘yÎ,„Rä)`!D‘`2¤qû³§PYYcŒGïß•ÖmY_P[‘|r3‘_$å\öùþâ¶Ï#=ò2É'3±-ÛÕܦõôC-³'éø"fö@cïŠËÀÏ@mŽÇ`¸—y¿YÔ¢¨TjÚ@ë^[SZ`[·+çò¤œÿÈœ^¦$2ýëËûÝ¿ÙÙÙ±oß>óY½5kÖpãÆ ¾úê+ªV-ʨQ£°¶~p)}Ø°aT¨P!Û8ÕªU˶ÍÖÖ6Ïùïy ¬_¿>[Û Aƒ²lKLLÌñk++«'ê'Dq"{…E‚Må†Øø44e(Õ{2ñ;æƒ!•R}>$éÈj4¥Ê −S]ÕæØ·JüîEhÝpîù>6•˜ÇVëpµœ„] 3ï−Œ‹Ä”aD… c\æYk?2â3ï;4¥§ ²²FWµÉï"#îj;gœ»G_§Sf6§²èª6Gãœ5‹ÚÖ¹p>´|âàà|€™3gR½zu

EMB in JOnAS 419 Using Enterprise Media Beans with JOnAS

óþ¿™3gæxpÛ¶mF4 ›7o@¯×S¾|ù,ý¶nÝJFFjµÚÜÏÑÑ‘Ò¥Kçûû¢°H(„(2œ{¼‹sw³mw ‰ã?w8´úàë¶Ãqh;»†½s[W¥º*Ͳm/;î·‡fršý¡€ûôþÐûwx¥ÝÚxèxEÑýbéÌ™3Œ’ððpnÞ¼™-ß‚ Xµj}úô¡råÊDFFš§jñðð2Ïä :” °~üxÎœ9CÕ¸sçàôéÓrétçÎF¬-->|¸ùÄ *0sæLnݺũS§²ÜWJPP>>>,^œ¹šK·nÝÐh4YÆ>qâ:tÀËË‹ï¿ÿ€îݻ˜€¢X“P!,Ü Aƒ˜>}:ÌŸ?oooš7oξ}û²ô³²²bÏ=ìÙ³'Ëv__ß,gúf̘Add$ëÖ-cÁ‚YúúøøÈ{¸†¯AƒYHöóóÃÅÅ…{÷î±uëÖ,àÓO?ÍæÍ›ÍOûúú2}úôlcÀ€ß²}ûv ó,çÇ\ ïCˆÂ" BQj=¥ú}ô«zˆÂäææƉ'X·n*•Š~ýúÆÝ»w)SæÁª«©R¥ ÁÁÁY³³cíÚµ„„„pàÀ¢££qss£FÔiÒ$˱'OÌ+¯¼‚««kÞË/¾Hß¾}³]¾U©Tlݺ•¸¸¸lmÕ«WgÚ´i¬Y³www:vìH©R¥²íïïÏÔ©SY»v−ãä䔧¼B(M @!„¢TÖzÛüï¢@•+W#\¾Î©‚Ì3xz¯N:Ô©Sç¡}jÖ¬IÍš5=h.îÏÏ—“zõêåÚV©R%^ýõÿ¿råÊŒß QÉ40B!„FÎ !„°(:t ""ÂüðKn‚ƒƒ¹wïU«f_@!„å›o¾y¤~÷×ÿ¢$’KÀB!„FÎæ£Û·o³|ùr¥c¡˜ÄÄDâââäûà ¤¤¤ÈçVLý{ù;!Š )󉇇†‰'*EÅF¢¢¢äûà ÄÇÇËçVŒý{ ÒjµL7!D¡‘i`„B!,Œ€B!„F @!„B # B!„…‘P!ûÐö˜˜˜BJ"„°DR !ò$555Oí–êܹs´lÙ’_ý•k×®a2™ cóæÍtîÜ™−[¶(QQ‚I(„È“Ÿþ™‘#GŠÁ`2׵ݷoݺu#$$Dá„ES£F¸sçÝ»w§R¥JDFFâééIpp°ù³Bˆ‚" "OzöìÉâÅ‹©U«îîî\ºt ;;;Z´hÁùóçiÔ¨‘Ò‹¬Áƒç¸½_¿~ètºBN#„°$2´(4Û·ogùŠeJÇ ¼{y®^¹Jzzz–íöö¼8|X¾cìk¯S³fÍ|«¨Ähï¾û.C!„È/RŠB³ÿÀ>.ÅŸ¡A?¥£ˆ|VWW…«³¯fÛÞ ]ó¾,ÖOS%>6 àè蘧±þüóOfÌþ"[Ñ¥×Ò®D݉2¿¶µ³å‹/?ç‹/?W0•ÈÉ€¾éׯŸÒ1„ÈRŠBU½Qe:m©t ‘Ï‚5cDzƒÄÞ‰7o«X¾ã:åËø¿ÙÍåË—Y¾|9 ÀÁÁá‰Çºxñ"á‰WèþjP¾dË+W «gl6¿nÒ£ù*˜Hää÷»˜:u*Mš4ÁËËKé8B䙀Bˆú!“zrîÈe¾zõGê¶-A%?ŒÆ ÖÌÞJ-¦¾\:q_>ÝȬ½ï V«ùxàÛJÐ f¬š±©pÞL.JWpaÜw/ ÑÈ?−«VÓ‚ò÷æÅ>~f>½ÇvdJŸ¯è;.}æí¶:Ð߀Šèlm¨Õ¼ !»Îrð·ãèôœÜsÎ{î[s›Jõ`®¼£›Oáß²*¯Ìz†owÅ”‘‘eÎ:µúAß_>Ý@ÅîÛÊ„¥Ã áuƒÊþxû{äاJ½Š,zw5e½\¹qÜ?Ÿ†jSÙß“+§Ã|ºq–BRˆÿçSNj׿}o.çý•£øhÀ\¦þ66[¿ÛWî wÐœ¨92xÕpçȦS¼³ldA¿ !D>Pä›aÆFLLLí{÷î!ÁúÕWÎÖÖ}LÛ‚WdTö÷Ìòßê}([ÉíA{m/>Ýò«G£µ±Ê6–·_ÎŤ¥úþûïÙµkWmÿœQUk²Ë©)©œLyUË1aépìõLY?6ûJµ*`£×òzàÇhm´Ø—ÊýÞÄ6ý›`ç¨'1.¹ÈÌ-(„øoRŠ|3lØÃ×|ýpênÙŸ£÷˜…”¨xpt±ÇÑÅ>˶Š5+P±f…l} ã>±ânØ°a\¼x1×öpüò!Ú>Ó$[ÛÈY 2Z‘a÷ÏC:ÛÌKÀ®åY:ÍÜn¥µbæw¸M©rÎYîéüä÷q9uÿ¿BOÔ¾)…%JPPAA¹/ó¦ÓéˆÖ‡Ñu„åœu~*•ŠÒ\”!ôÕW_±qãƇöñôôäÛo¿}hŸÍ›73wî\¶mÛFRRtêÔ‰×^{¦M›æ[æGñ×_ñÎ;ïdÛþóÏ?ãâòßçF#?þø#‹/æðáÃ$''™ß3ÞÞÞ4mÚ”N:Ñ£G"]èJ(„BˆlBCCÙ¼yóCûT«V−×6“ÉÄÈ‘#ùæ›o²µÅÅÅñË/¿°råJ¦L™’cAVPÖ-[—ãûÚ¾};}ûö}è¾ôèуƒfk3™L\¾|™Ë—/óÓO?áàà@DDz}ÑÄ Š"(‚†š`Bé 5@€HHióþ8÷^nK−—ùÖÊZ÷œ™3³Ï%äüÎÙ{«(`…B¡P(œ ›âÏ”ÌÌL>þøcæΛ;Faaa6χ††f{]FF]ºt±)þl‘˜˜HFFÆ}Û—[( â‘ѹsgöíÛ—eû;w"“Å“¬sÕù—ôåû=ŸÔ}®šÍ16/úWwgšt-ûXm¹Ïªþ2øóÞtý¶¥»qqw¡q§ÚØ2…Bñ¤pæÌÏ~̘1tïÞý¾+IÝ/7nÜ`ïÞ½6Û²†,X`um•*UèÕ«… åTw,Š%SÖe9ÆÅSÑüöYÈc³Ñ”o†ýJzÚƒ¥ºy•…_¬zÄ=|÷Ýw¤¤¤˜ý|÷Ýw9ºö›o¾!−−ÍxìêêʦM›Ø¹s'û÷ïgñâÅfi«âããùñÇù=X²qãF3¯\ÕªUŸÏŸ?ÏéÓ§³¼våÊ•fÇíÛ·çèÑ£|þù猒 V¯^MTT_~ùå_+ZyyŠ«çcX;{ 1Qq”ªZœno¶ÃÍÃ…+g¯säïp2Ò39±+‚jÒ¢WCö†áŸUHOM§q§Ú4í^ß8Þ¶e{Øzƒn#ÚP²r1@ó¼mXðEJûÑ÷Ý88:hý—îf_Ø1b>=F¶gñײ{ýaÒî¤ÓeXkzdåŒ Ü|€åÓCY?gÝßjG‡AÍIKÕÞ “n¦°/쇶âЖüùóVVþ°‘ÍÁÿÒkt*Õ/Ã'ÏcV¡ÃÀßËö2磥´ØŒ uK3®ã¢33¹yÝmpótáËþ3-Æ=¼õ$g_$−5 ½¦Ó¦þ3¾;þ% û„ÎßA•ÆåiÔ±ã»O#=−Ô;i¼ûÜ$Ê×)E¿÷::o;ÛõâôÏŸ·²øë?iýbÊXäܹj?? ¦õ‹M¨Ñ´"þŒtóý,§öåøλ)W¶.ÞMüÕ›¤¥¦óA‡¯©Óº*í4ãçqKø÷OíßãØ?œÚ{€ÍÁ»XøÅj−—œ—;ß¾>×ö?üÊÆßw2õµ9lXøÙù¿æmgêks˜þæ|³úÌ+ØÈÉ=g˜õ^0ÿ¬Úo¬+¥dÎÇK¹rö: ‰ï‹áWÈHÏàN²æÞ·á?çIk˜úÚNî9cÓ¦ã»"صö Á_-á›×çrDï-•RòûÄÕÆ~N^fÛ²=Æãä„æ|¼”éoÎçܱ(«q3Ò3¹“¬åIŒ¹Ï¬÷‚™4à'~ùh)wRîz¯·.ÙÍ”¡s¿ÝäÚ VÎØÀÿ†üÌ¢ÉkIÓ¿ÈìZ{ÃÛN²ð‹UVÎÓûϱcå~–L]Ï7Ã~åÀ¦ãV6ݸÀÚÙ[ŒÇGwœâÐÖ“¤ÞNe᫘öÆúˆ−Z0kÖ,þúë//^Ì!C äÎìsyš ÀÒ¥KÓ«W/3Odvû−Ǿz5û—bÅŠY è' %yŠ2ÕKp;9•ÍÁÿ’’˜ÂA“‡B©*Åè8¸ekÒjÒ(°Õ›T Ã+ÍÙ¾Üö¦wS{© Õ›T Q`−jµ¬b\úµ…w/λD²¾ú‡›¾¦p™ê%Ô‚M+ѬG}Ní=KZj:/ßGý¶Õ¸Gõ¦Ùµún@ûM©ß¶:|[Â¥ýŒýSï¤áìâÄKãºZõ=¼õ$ ;ÔäNJ*g\¤TÕâ\=wÝè ÌÈÈäøÎê´®jvM‰ Eˆ¹Ïí¤;6h"ËË¿ >íAÿ»ÑÝg8)·nÛì P©AYnÅ'ÑõõÖ8»:m·¤Ï˜@«s‡·¤yϤ¥¦sjïY†}Ý”[w=$>E¼Øµæ )·nyHó–¯]’“»ÏŸDv„ìÇÑ)û½9y¤„+Ñ{åï·ŸÌ+ÿíE…º¥¹pâ2)½É;?aûŠ}ìùë(õÚÞõH˜b*ð=½ÝI½“Ι#Qü½T{` ÒGf¸î>Ä]Ñ—g4ëæ/ ,^ l‰}#¿™°ßþá§wÿ þZ"_ýõ®MûÒœ‚N'Œ¿ ‰`†ÿγQ¿”þŸOºÇ0½«ç-ƒll½€dfj÷fØ»ëê‘õ ˆ‡•ÍÖÿ7÷‡e9P???›ý\]]ñðð0‹˜MLL¼çø .ä…^`ܸqLšt·ŠMdd$1116ç´€áÀ¬Y³ŒçCCCÍD¡×^{Ëf˜y°aÃ=z4}úôaäÈ‘Ô«Wï÷ao”TGstÔ‚)C~¦bý²*æ…ΤDU±r…ùâÅ:ñWo2qÝ»ðñ F³J¼Ùx^~ð0y ¼>åEþÛï>ÿ±‹ÌLIÛÿЪo#[ÓðÆ7/ñeÿ™lú}'Îܸ–Àô¶S×DŸ‹áÓÓ¹q•^£ñ*äIA_\ÜœÞàS|Š´Šè=ºã4»×æܱK¼ñÍKfûRL¹q=‘±mq©*Åé9ª=#F©*ň¿z“¶ÿ 0dG\ôMÆwÿ–ès1n_ _.†ßݷبSmæOáí_àåWÀèóö/È+ŸõdT³Ï)RÚbåü‘™Ù ìGɬY³X¿ÞvôlZZ™é8ºXÿù»ŸZÀê–æð¶p*Õ/KBÜ−ÎÕ~÷/œ¸LáÒ~´êÛ˜ŒŒL.†GÓ0‹¹5›Wfúˆùøñ¢P1o*7,Çâ¯ÿäõ)/æØÓqxëIZõkŒƒƒô´

EMB in JOnAS 420 Using Enterprise Media Beans with JOnAS

ânQÐדc;Ì=−‡¶¤Ûˆ¶dffrdûiÚ h–õ¤BÐyh+:mÅøÓ8ºã4þÏØ® àåW€¾ÔoW2Õµ}¦¶^@ê·«a„ttÇiî8MFzÞz’Ú-ªš]ãSÄ‹ '.#¥DÁѧ©ölyt:ÏT*ÊÁ−'¨Óªªqi]‘;XŠ¸ìG,Û •B²¢Q£FFñðú믛 @€+W®X ÀŒŒ 6m2YÝðô¤V−íÿ¥Áh ,,Œ «¹===Ù¼y3½{÷fÏkotrr2óæÍcþüù¼úê«|ûí·¸»»[õ{RPPñÈxùå—³mOKO}èZÀ-û5¦QÇZd¤gPÐד‘3î¦íð−æÍg!£ˆ¿zߢw#I?]òï§ÄEßÀÉÅÉèY~}†±Oý¶Õ©¯÷Æø•ðeê–¹{‹ÌŒL| gʤëë-© ßShˆæB0uˇÄ\Ç·¨—q™à—£Ú–Äø$\ÜœŒº–}—k‡|y7CýìÃ_sù^nxzi`^ßÝ̆)›>0~î2ì9:¾ÚŠ˜Kñø.`ß0oV´ØŒZ−«™‘iô””¬\Œ©[>$ïÉ/Ǿ$.úá ×þMúô¼±Ïä°÷Í®Y³Ù1|øpÎÍz¯âöíÛÙùí6µjÝ3çi`ú¼Ó‘qÿÇámáÈLI±ršç»Jãò$Ä$2¶íWètÆû¶…›§+…ŠûP¥Q9@ó®úa#µZd]]!'xùà£ÎSIKMÇÃ˦Ý5oDÏQíVçÊÕ*‰§N¾v)’l{?îú NÎZ@Å-ÛÔkS‹áÑYÚóáÂ×™4`EËøq'% ߢ^Œ“}íp¿âÞ|ÜõÚ3%: õ ÍÚ øxШc−WGѲþ¸¸ÝoÏ|…¯ÍÆÓÛjÍîUñx¹×jŠ)Y½èf…¥g®D‰!Ìæ¼}ÛzEdÏ=fÉF#x+T¨€¿¿?ׯkËÿ»wïw2wî\œ°°0œïës õ?B‘çÈ®è¼ÂLü°'¦ØꟶR¿ØÂ2KNl1]†ËGŠ˜ì9ËÑ5ºû¾0îïÊ Ngóf½·ˆsÇ.‘z; GŸ…Œºï¹„–−[š¥›°Å5dztx¥ùCÍãS¸ 3÷}F\ô «ß¡öN öò ÷6úßïúÔjœiÛ?6~nÒµ.¥Î1×iU•:z¯×+zš]÷ÍÖ³´-BÝÒ¼òYOâ’Ì^Túô”^Ÿò EÎÞNN¥ ¯ö;îQйᓨݲŠ1ÝÏäÐ÷ˆ‹¾”ÓöTm\IëÇÇ|áý»ûîª4*ÏÌ}Ÿ{å.îÎƗüYQºZ ^Ÿú ±·ÌîcáÙ)ÆÏïÍ}¸è,äiö‚W¦z ~Ø3м›ú£JõËòÅš1ô}÷îR4`øà›ãØ%OÕšTàýyCímïÏší£¼ÂÈš‰„ûeØ×/rë6B'puÏûßGVØzÐétY.‰æv½ÔÙ½À8»:½Ã÷â~_œ€Êñèà ËÖÛ•−ÛWìcÅôPÜ ºqõ\ 㠻﹆¥ç,6Öv‚ôÔÔTnÝ2/àé™ý ö½òüe…¥œ2e S¦LÉ¢·Ö?+h@§ÓÑ©S':uêDLL _|ñ…UòŒË”T('Nxz?¿ÎÞ9óâ=é¼4Cv{‡ç‡·±· „öšÑ>»}ˆ÷ yÏ4ïÙàZ¤€œ−ïZB… g s\¿×À½ÊÂYâççÇ7ß|ƒ³³3“'O6ŠŠ"22’òåËß×x¹J£P( …‚ôôtcuVXzól−ÙšæÕ3pøða«s‡Y—ݬVÍv-ó‡aË–−VKÍ÷âôéÓœ;wî¾ç:Ôz%* —‰B¡P( »Ë«¯¾Êï¿ÿe[KÑæåe®ªZµj)RĬRƲeËxöYóR‰K—.5;®U«… Ýÿ>å{aéÍ ¤Cë`ÄÙ³g›%¢ 3tsçÎ¥OŸ>xxd½Êc¹î½¬m/”P¡P( ÕÑ®V- ,°Š¦]»v−Ë–−3;gËÛ§ÓéèÖ-›Ù¹üÑL,œkøʨÈU.E\åà–ö6C‘ÇHNHÆÃãþ ÅýÅË/¿Ìˆ#¨[·.ÞÞÞœ?ƒZõmÛ¶-Í1FÍ/¿üBF†¾ÆzRߦuëÖ¤¦¦²uëV³åæ 0bĈG~//^$<·Ø³g§N¢}ûœ•¦Sä.Bˆû®`I“zõêQ¤H{›¢°àaÿd¼½½¹páË–−cÕªUl߾˗/›õ)_¾<=zô`̘1+V,Ûñ¦gÏ̘1ƒ¿ÿþÛøwßÁÁ¶mÛ2zôh›jÕªe¶ß®T©RV}Z´haåkš‡0##ÃLô=ÿüódÇK/½dölºyó¦ñspp0ï¼óK–,!,,ŒãÇ›}èt:*T¨@çÎyóÍ7)W®\¶s=N² ÞÌpuu=tOâC8·(]ºô鯾úª‚i]AEîpëÖ-lËuÙ‹uëÖ±gÏÆooSÙP¬X±, Ìç”ÔÔT–,Yrßé!rƒ)S¦Ð½{÷'2w˜BõêÕ£L™2ö6å±sóæMbccqttÄ××÷¡ö³Ý¹s‡k×®¡Óé(\¸p¶5‚óéééÄÄÄpëÖ−ÜÝÝñõõÅÕõÑæ>{Ä_$оU«V·”Pa<==©Y³¦½Í°â eL IDATرcœ9s扴Mñhqvv¦wïÞ6kyÚ///ªU«FíÚµímŠ" Ôú®///›©^J–,ùHÆzptt¤hÑ¢ö6ÃŒœŠ?PA …"ãââòXÏ>,”−[ö‰´M¡PJñù\(P`LµjÕŠ:88´–Rêg{Û¤°/§N—.]M›6ö¶E‘‰ÕÕªUË©hÑ¢ùw‰F¡Pààà€‡‡‡§››ÛÍG%þ Ÿ À−[¶\ êÚ¨Q£uBˆÔÈ|‡‡‡ptt¤sçÎJ*ìÆÎ; jÕªê÷P¡P Óé„““SAN÷ÐéaÅäó=€ …%Bˆ€VRÊ×ím‹"ÿ"„XI)wÙÛ…Bñt¢C @…B¡P(Š|†€ …B¡P(ù % …B¡P(òJ* …B¡Pä3ím€"ï!„pJÚÛÇ„?P@QÆÎv²|ùò³·lÙòD‹@!„¯——×"EŠqppö¶ça¹pá‚‹ŸŸ_š»»{¦½my’HLLtˆŠŠriÙ²eý−[¶ì··= E^F @E1ˆ¿Ö-[w\´h‘ÎÁÁÁÞ3gδ·)vãÈ‘#tíÚœÓÞð÷÷ŸôDŠ!„¯··÷Þ?ü°Ìرcó¼ø $((ˆgŸ}ÖÞ¦°¯u EÞE(²ÅDüuX´h‘ƒN÷ô½34iÒ„—^z‰AƒáïïOjj*óçÏ'%%…—_~{›øر™™™é™RJGà‰ÚiŸ|òI™1cÆäiñàììL×®]ùöÛoçvíÚhb'88Ø^¦Ù[â@J™)¥Ì°£i Eçé{š+ùAütïÞ‚ ’‘‘Att4qqq¤¤¤0`À;[÷ø±%þd6ñg`àÀ6Ï·hÑ‚2eÊä®1O!!!6ÅŸB¡x4C‰¿üA^AAAe”ø{z1ˆ¿°°°|YÞN¡x’POÿ|„ùƒ¼*þTH>¢@+\\\ÚÅÅʼn§iŸ›â.\»v−ψ?ww÷£EŠ)¶víZÖ®]kos¤¤$bcc•øS( ”ÌG(P ÉÔ©SEåÊ•ímŠâ1qùòeÆŸgÄ@FFFÑ?þøÃÞf(#ëׯ'**J‰¿|¢ ð«”²µ6_`”2à>Çl –R±Ñ¶øZJ¹çÁ,!D QJ¹^ì¼n¥”+îsÌ€Ÿ”rŠÅùZÀ 8pX+¥\÷ ¶ß %ó:αråÊÔ©SÇÞ¦(ÞÞÞ8:æ-ÿÖB¡~'ŸnNûØçIJ¼q?Ý¿“Rnãþºÿ“ômßK)×êÛ¾‚LúÖ^•R¾/„X…§Pï¥[ o댕úë*í²¹ŸŸ¤”aú¾ W¤” !¡y§èm “R^¿ÇwSµqþPÚbNÃ÷4¨¬B”=¥”)Bˆ4!Ds)åßRÊýBˆ®À[úŸÛBˆ±RʧúÏÑöB|Är÷{BJ@…B¡P(Ê›|.¶Ï΀é’ä´ýyÊ¡ FЖo}„-€¦€-(YËëM?_ÎH)−~®ëíÉêº{ÝOÃýH)Oêm Rn¹Ç8ëÿ!Œ«§BˆBhÞÌ?spý+@Zôðm`%ÐS¿mDJ™ÌÐ"‚ j X¡P( …7„±h^¨@ƒ,ú}LBÄ¡í€W“„o'€÷LÚVã…“€U@A ±”rÚ¾À BˆchÁ#ƒÐcV¼*„¸x/ÍLÚ~~·˜;; −ÿ)„ø− øc´Ô6Ù¦šÑ®¸šîíB´z !Ò€`pxA_ÇshÛ}£ B¡P( ŸÍÑ‚èÜZJiºÜú3 0îEH)oéÞJ¡yâ:èÛÒ„ÀP`š Õ·BtG[N½†¦Kµ4´%ë¬ðA¨H)3…ÐeÚ£yñÞ·ÈÕ÷æKÔKô×FÚìBóòmCûÎÛ.ÀI4±x;Û %

EMB in JOnAS 421 Using Enterprise Media Beans with JOnAS

…B¡Pˆ–R~dyRJ9Ûƹ−À[ƒH)/¡‰Ósqè þøð®I—ãì69u(‹~†½‡V©b„nÀÀïRÊXí€6hBo²É˜Í³¹0‹9X/ÕhAõÇ~úã]À °[ŸØùi¤`¸7³=’ÀBýx6¢ES?6”P¡P( …íRʹY´−F ¾X«?„äáeÒç”2@ $ Õµ=e9˜¢@ͳxøŸ”2FïI…–³o³Á}šh@ºÐAF€p`ª”2ÉÆ\ Ð"k‹£í5œ.¥Lз}Œyü à¬#Rßö¡þ~¢g|+¥Ú’±Ñû'„趇´ê!aBˆºh$%Ђ@C©:´Zà «£Bˆ"RÊ«¦“I)—éKÑUþÞB8ö3“¤”;€BˆhõCDïWRÊíÀv!D´´2¶î!„Z)·ÒRÊk¶„è…[%ýýB¸I)Ï !n¥”úqL/Vvo‹¾-šÀ4°˜–‚¾ôœ−ûLQP¡P(ò?ýô£F¢P¡B\ºô0[ ›ü˜Íh-hK”€¾í RÊôeÖv¡−{þfÑïl, c]bîû÷ïÇÙYÛÆo\VÞ»w/;vì0EPPÓ¦M#!!Á¦œ7o!!!tíÚ€%K–ð÷ßwõ‚¯¯¯•Œ‹‹3ιaÃÓ›6mâúõëüúë¯( +öa’sÏ‚ýX/?¨ýû÷³aî]»Fzz:… "èׯRJ<==Bïý÷ßgþüùŒ’)S¦IÑ¢Eñ÷÷8¢?~Üj|[|ðÁ|8+W®dóæÍ−ªMJi;WÁ‚¶*Ga\ÞµkáááôêÕ‹pøða€‡€ÙågS( åTØ…ß’™™IÑ¢E‰Ù{MFF¹>¯"o0kÖ,bbbxî¹çØ·O Ú+Uª?üðIIIÄÆf¿E(«ßƒœ?>RJÞ{ï=–,Ybܯ÷0P¡P(²C=±vÁàEyõÕWqssãÈ‘#DGGÛ“““©S§uêÔaÉ’%téÒ'''*UªÄ‚æÙ–/_N›6mðóóÃÑÑš6mʆ ¬æ½|ù2¯¼ò >>>8::âïïOÿþým–ÔŠ§C‡99Q®\9þúë/³öôôt>ûì3Ê•+‡££#ÞÞÞôîÝÛè5RäM DýúõÉb*T0R+¦U€ŠŠŠbïÞ½¤§§óÑG=ðÒªA®Y³†Š+Ò AJ–,Éš5k€»ðÂ… „„„¡C‡m9×pÎòwS¡P(î…ò*ì‚A¶lÙ’mÛ¶±mÛ6ÂÂÂxùå—Í;gxнõÖ[FËéÓ§È`¥K—¦yó怟þ!00½{÷×Ï_¿~gŸ}–‹µj?nnnÄÅÅñûï¿3hÐ ã)ÿûßÿHLL$##ƒ³gÏÒ¿.\¸`ÜS5dÈæÏŸ‚råÊqõêU–−[ƦM›Ø·oeË–}Ìߢâqr·2C-ZµX¼x1...€–föìÙ$''Ó°aC\\\prrÂÇÇǸ_ð~¨Y³T-ZÐRº ÊÄìÚÄÄDzôè@ñâÅU]`…Bq_(¨ÈuNŸ>ÍùóçÑét4nܘ€€¶mÛFhh¨QšâááÁáÇIMM¥aÆDGG3cÆ £ìÝ»7Ÿ|ò •+W4Ï\•*UˆŒŒdéÒ¥FqâD.^¼ˆ““üñ=zô %%…%K–àëëk5oÉ’%Ù¾};aaatïÞØØX=J£Fؽ{7óçÏ`ÕªUtéÒ…ÄÄDZ´hÁÁƒ™}:”)S†Q£F±aî_¿N«V-Œ} *d³dI[¥PÁÓÓ“¯¿þšÄÄDc.À7ÞxƒÊ•+ãããcÌ)X·n]ãX¶0ì1ô÷÷7ö+R¤eË–5óðð°=€B¡Èw(¨Èu Þ¿š5kR @l.Ù‚VÑ pá À€É“'sðàÝ$î,\¸)S¦Mjjª1óüùóÆ~ëÖiåûõëg\Òóððà•W^±9ï /¼€»»»ÙCýÚµk¬]»Ðò¬_¿€Ê•+sðàA¶oßó/DawªW¯NõêÕsÔ·B… LŸ>ÝìœáåÃ___‚‚‚î9Þ;ImÞ¼¹ñåÆ@ݺu©[·î=Çòó󳚳L™29²C¡Pä/”Tä:¡wýúuºwïnkÑÑÑ>|Øjã{©R¥¬>_¾|Ð6à£ÈNooo£´`Óùcccéر£ÕµW®\ÉÑ …""„(ÈÅ)/™Ô°U(”Tä.lÚ¤•8¼|ù2+W®4k µ€IIIVŸµ_ÝeË–ÅßäÉ“Ìh… ¢cÇVã]]]¸qÃfÂ÷û .ÌðáÃ-ÚÝÜÜz…"§DGGsîÜ9œœœ¨_¿¾½ÍQäOo÷y y6r+àúØ“3^»ë–—4~Üs)òJ*r•={öpóæM„,_¾Ü(Ê~úé'BBB ãÝwß5»fýúõÆ ðQgÈËvæÌc¿aÆQ°`ARSSµZM©[·.W®\añâÅ|òÉ'F‘–’’BRR~~~9¾ƒ¹))‰#F«5€iDQØü”šgñâŌՊ… =ÝŠ'GgG§1?.P§UÕÇ>×´7æ%¯þqÓcŸG‘·ÈO †ýU«V¥{÷îHï޽ضm›Ù²−ÀÒ¥Kéׯ=zô0z»wï`¶oë£>âŸþaÈ!ƽz¦Œ€ÈÈHêׯχ~È›o¾IµjÕÌöæ„^xB… — ƒ‚‚˜:u*o½õåÊ•câ¤!—IDATöìÙ÷5âÑÀ˜1c(UªNNNøúúÒ²eKfÍšeÕ766–¹sç2wîÜGâV(Š¼„ò*rƒlÑ¢…ÙyÃñíÛ·ùûï¿yöÙgmC† aÞ¼y¤§§ûÕ €^½zѱcGÖ-[Ç÷ßÏ÷ßO‘"E¨S§•¨ëС“'Oæ£>âĉœ8q‡ûôööfÕªUôíÛ—ˆˆè%vvv^{í5³þgÏeÐ A4lØиç3/R§NFe,Y§Pòeð{ÍÍu~@Š”2é³ÃRÊ›:Fn "W™8q"iiiT¨PÁì|É’%Ù¶mVm:uâ7Þ`ãÆT®\™:ó²ét:þüóOBCC9rä¾¾¾ôìÙ“¨¨(®_¿nŒö0vìX^zé%BCC¹zõ*ÅŠã¹ç3KÓ±víZÒÓÓ‘...lÞ¼È ""‚ Þ”’%J@éҥݗ¦ÈG኿?þøƒ~ýúqãÆ ¶nÝúÈSòdWбrÒ®È÷´†Ým´5F]€g @+!D ‡”r¦Iß@àäc°±>ðµÞûáÀf`ÞCÌý>p˜ôc>>tïÞݸe`ÆŒÌ=›””ã¹^½z÷£Îš5‹FZÚÃïÕ¤I“X¸p!+V¬ 33“>}ú0oöŒHIIá“O>aÑ¢E\ºt‰B… Ñ©S':Ebb"þþþ4nܘI“÷ßçÕW_¥\¹r|üñÇ−Z”ªT©ÀÀ ÓAKK´qãF«ïÅ°ÅbüøñŒ?“'OÒ A,X`öÂuøða^{í5öïßOùòåùâ‹/øì³ÏmŸnãÆèßF‘oÙ¼ ÿ\M4š À6ÀõÜ6*ø °]ü B @…BñTP©R%ãçÀÀ@þûßÿÒ¥K+/Û•+WÌD@xx¸ñ³éËGZZš±ïСC‰ŠŠB”’;vš·¬{÷†âàà@… ˆŠŠbþüùlÞ¼™P¨P!fÏMdd$åË—§Fܸ−#>>–−[÷C={–—_~™ääd«ïEñt"„XÔ°+¥LÕ·} ¢€?−®{¤o[cÒT ¼| ”Bl.H)SѼeç…¥é@ý8c¤”‡„îÀj`.0M·ŒRnÓÏ= hÛô×%ßã>¿Î½€ÒÀïÀgRJiÑï¿ÀV)åýñ{Ài)å ý2ï@m`p%¥\ ¼$ó…C/ ÐM–RÞÉÎÆÜ@(HéÖ-ݺu3ó (YQ£F £g÷ðáÃtëÖòåËóã?÷|þùçH)Ù³gñÜÑ£G‘R"¥¤M›66Ç¿uëË–−#11‘k×®ñÉ'ŸZ%˜ÐÐPÙ±c§NâÂ… ”*UŠ‹/2cÆ ãï¿ÿ>QQQœúè#zöì

EMB in JOnAS 422 Using Enterprise Media Beans with JOnAS

hdÀš5šÃ£lÙ²ÄÇÇ›U…¹pá‚YU˜çŸ9sæpüøq®]»FFF†Ñqúƒ0`€öÜ5lÅHKKãÆøøø°k×.@ –2,õ¾÷Þ{„††>ð|ŠˆÈÍÍýAðV¥‚ô¯»¨¨(æ̙Ӣ]/þ—¿üÅÑÎÈÈà‰' S§N„……QZZzÏýj+z!tçBÒRTÚ«Œªªº@Q”ÿrj;ƒ6¸ÅñÌ‘#G°ÙlrË·:vì………Ìœ9Ó(a¢( V«•ªªª+Ã]IIÉ=_wÐ A|üñÇTUU±lÙ2Œ¶êêj®\Ñê»ÖôîÝÛX•œ——×.ÂÀàÁƒÉÌÌ$33“¢¢"zöì)ͽËÿPe D @ -Ü=¦hßXhIÿ¦ÙwÜF-s´¹«whTåCàߪª®ÒTU-Vå÷ÀnEQ>ÒTUÍW¥µ‘¹cÀEQÞF›ÿ7ÄÑ¿;«(Ê;@=Ú¨¡»|ô|Ú~lWå)´¹Eh£{ €B8Q…ØØXâ V¯^ͪU«ŒçÛ·o÷@ïDkJJJHIIáµ×^câĉ‘““cÜ¢ÿnœËù‘‘‘øúúR[[ËóÏ?oÔ—\´h‘ËŠâÛyþùçùãÿÈÅ‹r$Ó§OÇÏϼ¼Fµû!. C»½=¢=Ôö»E»²bÅ ã?µ×_½Õr.mÉy‰^|ñE–/_h«” `Ú?~üé—¸;‹…'xâ–µüÜ vÙâÏ™Õj½å.0͹]UîÌ××·ÅBç}¯—Ý6zõêå²M¡s_l6›.[Øâ3téÒÅíçš5k ôïߟêêjÖ¬Yhß ¸íµ„xè ]~à{ÜÀuW“‡@Ñ®Lœ€€úõë×â5‘‘‘Œ;–°°°Vß»OŸ>Œ;Ö(éâÌd2×Õw¸c2™ÈÉÉaÁ‚=z”¨¨(6lØÀêÕ«©®®¦G·|-x8\ºtÉ#GdÊ”)\ºt‰Ï>û¬ÝjBˆ¶$Px\ïÞ½ÝîÒñî»ïÞò5Ï=÷Ï=÷Ümß{Á‚,X°Àm›Åbiuwg={ö$33ÓåXóçâáuüøqª««1›Ídggãï¯ÕiUU•œœœçÿý÷|òÉ'NRRR‹½‚+++ÉÊÊ´m銋‹ùôÓOHJJbÈ!p€²²2}ôQ—23_~ù%………„††2fÌãxQQŸ~ú).\Àf³1yòdz÷îírÝÒÒR:Àĉùæ›oÈÊÊÂjµ’œœìö*!„÷‘(„ðzªªmLÐØØhumì„ ®Û‹~òÉ'¤¤¤PQqsx“ÉÄ«¯¾ê²[Lqq±QfÑ¢ElܸÑX8”ÎW_}Å–−[Ø´i£Fâðá›5içÏŸÏÉ“'Y²d‰ÓÓÓ™?>µµ7Kùøø°nÝ:–,Yb;sæŒqÝÅ‹³~ýz£m÷îÝìß¿ÿÞÿ „†wÌlBˆVŒ;Ö˜~ðì³ÏOZZõõõ.ç]ºt‰ÔÔT***˜:u*›7ofÙ²e€¶] >Â×܆ ÆlË–−ã—¿ü¥1uág?û¹¹¹\¿®mŸzåÊ£³Þn·Ûyá…¨--eöìÙlÞ¼™Å‹S__ÏK/½Dnn®›«Âúõë=z4+V¬`þüù.EŸ…ÞMF…^/44”ÌÌLfÏMAA'Nœ`Þ¼y¼öÚk¤§§3räHþþ÷¿S^^ÍfãÃ?ÄÇLJÔÔTNŸ>ÍÎ;IOO穧šo[ Ï‹ŸŸ:u¢{÷îüæ7¿¡¸¸ø®-¿¿>‚è|û´º—ñññÔ××3mÚ4üýý ¤W¯^¼òÊ+”””ÜëÇ~¨ää䨋Åk¾´Ùlõ¾¾¾KÇÿg"))‰·ß~›-[·röìYªªªˆŒŒd„ ,_¾œ€€@«÷·k×.þô§?‘‘‘ÁÙ³gQ…þýû3fÌ—}tŒfnW~å駟ÿ~Þ|óM¶mÛF~~>V«•>}ú0nÜ8Feœl\WïwG““£NŸ>½¢_¿~ ¾¾¾ ñ°êø“{„-ºMøË£ÜþšâââœÂßN`abb¢ÌaâÉ ^¬yøÞl˜„?áqYYYêŒËÊ£¢¢œÃŸ*áOˆ¶#P/å.üuéÒEŸ𨬬,uæÌ™þ„¸Ï$ á…nþÎ%ü‰MŸ@!¼Ì„¿I‰‰‰•î§ð.ûöíkþCCC%ü qŸH‹´þT ÂSöíۧΚ5«yøkÖlX/á]»v-wþòð'ük ; ù”ÙlÆ××·Él6l¯áO÷׿þuhDDÄç€hòtÄýa±Xðõõm0™LCŸõÿSÓšÌ|ÐÞIEND®B`‚‰PNG IHDR)Ñ/DBsBIT|dˆtEXtSoftwarewww.inkscape.org›îç9Ï=G’e™ª$©¾-cƒ¿¬íêšViEA„ÇPŸ'…ß¼ªß±Cû.'Oô“ª’¤$Iª_×¥éùÏÖ¯cne[ƒa ‚ð›±ï−®°«ìÁíÐÑÕÃÂƯýp÷ꢒ˜Wj•¤nÿ}‰³Gw>tþ“$©ý¿.Çç·µ´î2ˆ9ßú/á©ŒK“VäfgÐнµªC!:,Hù™š[ãæÙ‘à«g8óÇÖmóŸ“Ô¿±´v m·¡èêÔXQ·oTz,îùñ ^|íÆM[R£õ ÷©U’*S×¥CÇXnš½³Š¢Q½Ác¦3xÌtU‡Q††àü1444)))®ñzÝ}£ 8u;õ eyOfßÏ_{çÚºz¸·ìˆ·æáP¯±r™„Ø;|3o“f¬d×ÆÅÜ 8‹‘)ã¦−¡}ál_7Ÿ ˧hÝeÞ;×b`dBß—Þ¢ÿ«SÊmÃâiƒÉÍÉdø„¼p¿{e™>/NfÄ›sXþÑ«¤¥ÜS®ãÑ®#µ´±¶«Ç ýGÓï•ûw¶(*,dïÏKù뤧$`jaCûîÃyù9èêé?ò5ù§M¼¸t‘„ØHÏÃÙÕ“°àËå–ÉÎLgÇúù\:}˜ì¬t¬mëÒmÐx†$)¾2*Ë2¿mXÈÙ£¿‘—›ÍÈ·?«´¾C[WqÁ÷~rÒÕ7dî·¿—[¦ ?ß6, àü1Rã°°±§ûà ô}ùm455«¼ºú:»dìÝó=%ÅE¤È²Œ³«'/¾ö1ÍZwS–såìþؽ¨° r²Ò11³¢›#ßù;'n]â—•3xùõ9üºjN{oÃ{çb#•¯y·Aãèóâä*o£ºSË$UŸKBld¹iæÖöhkë|õ ¹ÙD…‘Ÿ—CA^©IqlXò.s×x|¹Ü›«çNd¬íê‘“•ÁiŸ-\=w„¯·_ÁÚ®.ù¹ÙÊõ—|0Œ¤ø(@"−9Û_¢}áD…tù±Q¡¤ô¥¬÷ï«gÈÉJãÞÝeY sÍÿ„2IݼæGò½hå:¶öÕÅÓ‡ùú“‘€D]—¦èq'ôçuõÊ%©¯gâü‰=hjicc_Ÿø¨Ûìþq1·ƒ.2ï»#ʤñ¸ÜZt"´ü‡Ñ74¦A¯Ò}$Ó´Õ åæß÷#á7¯`fi˺ƒ·Yw0”ùëà³s−I÷b())Á{Ç:ö~…~ÙL[ð é© ê{kÖZö]•™±ì· óÊèêðÁÛØt2‰U¿²ö@¯¾¥H€¾©ò6_ý‹·:3õÅ¿¬œI~^6í{¼ÈGïòãÑŒœJII1ÛÖÞoõvî7’u‡n³Á;‚¯¶øóýïèèêu‹›ç*Ô;nê¶Í IKE'ýƒÇö忯y‡^/)_óŸÇ3tüŒ'ÚFu§–−)−− MÌËMÓЬj§>#ÐÐÐÀµEG@ÑËÍÉBßÀè±ê ºDFj"(`EóÖÝI/=:îC´uté>xx¿}Çiïm´êÜKG¢Ân™Œ$i(/wé7ŠÝ?~Á½»áLÞ„íz!ihþ7wB¯±ôW?åÕªê2päTîÙÀÐk¼3¤M½^ ?—ÈÐkÄGßfËé4 MéÒ4'öÿÈöõó ºršˆ´´´)**P–ΚÏW¶ÒKû˜ òr”ûÂѹ oÏY‡[‹øŸ;×pþ¨rºµ]=e‚«ªÎ}^%%1VÙÓ¾çK•fý›ÄØ;å.¹ƒ¢¥~YñéëѶ'¶ ÈÍÎàÈ®uÊå ŒLóÞbå'ª®¾ 6œà»…oxþg•]!“hÔ¬f–ud3ÿ•µ]]|¯¨3"ä*§}¶ŠÖDó¶=•§¹ã§−%êö Bo\ ÀïºKJR×ýO(ËzpøG™’’bå´ü¼^Ÿ¹šä{1„_fË·³°¬ãÄð‰±÷ç¥O¼y9ÄÞ AKK k{¸µdØ„™Ê‹%=†L¤ ?íëæäOh?†ÆæÊ+î−;3êüöÃBüOàÒéà å¢Âb«ÞZ·ul@vfÚ?^s3ÆM[‚•-Ó¿¬ùt’Y=JA~qQ¡”””`jaƒE锪ørÆËœ?±‡^ÃßàÝy?q#S‹r§W5A–e’ïÅ‘–„¾V¶Nåú{”‘šDb|”bì’µ=†Æ¦5(NOÒ’âÑ74ÁÒÆ]ýŠ}s ±‘ȲüŸOUdY”J^n688£§oøŸê+ÛÎÌôäG¾æª¶äƒaÌZYµo Ì{³{k=«âáÇÇ?÷É©Œ®õÕ¯Ö2k«é−IV¶Nõ)jbn…‰¹U−DuŸ¥Ã#O'mìëWK]’$)àÖ& G~]ßИz ›UK}eÛ©Šm-mj9˜S¡ŒhIU£á?¢ÛÀ±ÕÖ*A$©jÕ¸Y[U‡ Ïqº'‚ZIJµjM$)AÔšHR‚ ¨5‘¤APk"I ‚ ÖD’A-‰$%‚ZIJµjM$)AÔZ•¾`¼fÁhìþÓBí)**ÆÚ²!ï/Þ§êP*.:ŒÕŸÄÂÖüÑ *u/*‘wæl¡a³ªßJ»:T)I¥¥Æ°âÌÿj*¡šÄGþ«â¢B: ö`ì¢AªEx„U¯má̾Ôm°³Z¯_ý^¡šÈä§ÞA³°òg

EMB in JOnAS 423 Using Enterprise Media Beans with JOnAS

BUåçPœŠ¦\ðè…«™HRÏ0 ŠÑ‘sT†ðŒÐ ½`5IJµjM$)AÔšHR‚ ¨5‘¤APk"I ‚ ÖD’A-‰$%‚ZIJµjM$)AÔšHR‚ ¨5‘¤APkÕ–¤r2sÉJ˦° H9- ¯€¬´lr³ó«TÖï@. øB¾;/':$©¢£«…™ )ñéšêŠ–ÔÑ_ÏÒýÕvøsä§Ó˜×1áo¿Ûlüä7~¾ù%¦VÆb)).!, €:õ,XØÆZÿùH,µ ;Sô u‰ KàÌÞK,;öqu¾|Ï÷ ‰¾ËÉõ›?íyâwðþiõæ…Øüù>¼z5åÖ¥ö¬r`ÅÉY\=ñ7³ú/ÇÄÒˆ=«þ ?÷þMÞ¶}qˆ;Awé8Ä‹³û.qþ÷@ŒÌ ¸v:„Í öóÓßKÐÑÓ©KA^¡òX¬ßÌ€ÃßûräÇÓØ5°¦° ˆ¤˜T–û~B€o0©÷Ò‘eؾô0ƒßîAJ|:›?ßÏÖȯñùé4×N‡Ç;+F³xô:ÞXò #?ÄÖE»ÿ2¿Å}S“»·VUkǹ¤!1ô½^X{œã[Î1|Zïró·.:€¥½ÞèJ×m‰ú;–s®à½ñ…y…|}rë.NA^åwÿë4Ì‹Ao÷ A‹º4níLFr6AçB+]¶0¿ˆCëÿäÐú?ñ;ÀÝÛ÷ðÝ~þotåû« yùýð÷¾V.‰jhV¾;òs ùáúL^ö*yÙ„Dqb«Y©9ÌÙ>…Ÿo.−×Zë3¡3}w¾ @÷‘íÙ°·¶.åêÙöÅ!ô uù%äK¾:þ1™)ÙX{B9ß¹¹›B¿¢ý Onœ-|»]}mú¿Ñ− pÁ;°Ü±X\\¶ũçî@߉]ûó¯[Ü8s‹ƒëþ¤¤Dæ‡k‹Yâ3ƒâÂâJËï7ézë„K‹º4ðp">"‰ˆw+]63%[y,^=TnÞŒŸÞà ï¸qæ?‘ºnv86¶eCÀ"¿Ý£ÜòeÇа÷z±!`−{¸Ó¶¿‡â=TPÄÙý—é5¶#:ºÚO¼ïÔMµ_Ýë;± Ù鹘٘ÐaˆW¹y™©9svÿeRâÒèöj[ô uÉNW4¡−íÍ10ÖÇÐD¯Ò²×¾¿/F¯##)íÒ!'3¯Òe MõÙ¹‚m‘+˜³íêS³°r0/÷;+5é3ÒÔ{éʪßÔC}ŒÌ Å'cvzNiÌfhhh`akª\þË øúŸÈÉÌ»çctÞg¥å`fc‚–¶–2¾²¸AÑ:023xh"îÚ¥'ñ‰¸¶v¦I»ûù9ùæ‘“™ÇÙý—)È+¤Û«m‘44ÈNÏA[Wc CÌë˜ ¡)UZöcÖ³ò-ŸÉÍÊC[GqB’ûNqÇƶÊcqÊÊ1åæ¹wh¨³·¾¾‘.šÿh™xõjŠ¿Ï5Ú ôÄÚÉ‚€?ÿÆÞņ]]9±åë>ØŠµ“%ÉÙØ7¬Xv\Ø=ô uñê݌߾ò®R\Îͱt0çøæ³X9˜ã½ñ—ýNÌ-ø ëj”ö«Id³]Ýضø¿ÌÝC‹nM¿©µ ±a [Ò¢›[¹ON]´t4 ð æÀw'è3¡s¹zZ÷mÎÁµ'Øñåa¢‚chÓï~¿HeqW§®%Ÿl~ {›rÓ Œõqk׀ذ^x¹ †f†\µïo@ßH—I‹^VΫ¬õndnÈMÿpö®þƒv=+Ì8K#½Õ6}›ãظ»¾ö¡Q«ú¸´¨ûèó©¶$åÖÎÍÒOƒ[*§7ïÒçÒæÿý0‰Ÿ?ÝÍo_y#Ë2ÎÍ027¤ïk/s+‹G®cioNÏ1è0QôI9¹ÙÓ¢›¾Äš©›Ùüù~:¿Øš’âÌë˜òO®-ë+û¡Êèêë°ôÈ 6~ò»WÁ¦®%ÿút%/;ÇFuÛÕÆÒÎ}SkcÛ3•./µÁßç…ùE,:ô]G´«PVYÓ^ã_^tègm Ý€œØv¾æ7JPYnkŠ½‹ ?\[̶;+ø߆×hÑÕ¿ƒW045`åé9¸µs©Pœ®¾¢ âÁcÊÔʈï.}ÎÞäµØÖ·âÔo"IýÓ3uº7Øj´t4±w±aÒbŨÞwWeÑÈïxÍõc4´40±0dÑáÿñÂËmðùñ¯7UáÛîséè 6Ìܦ–%Å% }·WMn b…ùE¼Ýrº:¸µkÀë_(©Y[ÞbÙÄa7 ÛúV|wészëÄ3?3ÌüZõnúXu\÷'G9ƒ¦¶VZ6E…ŘZ+¿V’Ÿ[@aAF¥£€G^N>Y©Ùš¢o¨[Sáþ'b0gíHKÌ@SK³Ü−Z²ÒsÐÒÖDÏàñìŒ\r³ò0µ2V~P¨z0§úí‘bTÉWtõu”÷³z\zºU:…g—Yéw5T•¼2†ÌêòLõI ‚ðìIJµjM$)AÔšHR‚ ¨5‘¤APk"IUÁƒwC¡vˆ$UgíRu‚ðÜIê1¥Ä§±wÕ„\ŠPu(‚ð\Iê1Øv’b™c›Î¨:Ax®ˆ$õ˜Ê’ÓŸÛÏ‹¾)A¨E"I=†ðkQ„F‘”…¿Ï5G$Ï‘¤ÃÑMgËýìÿ ‚PsD’z„ââNlõ§−Ó7Öãüá€r?¡æˆ$õ±·ïñâô>üò%-ú4ãPÆ÷,;öwoßSuh‚ð\xnî'õ¤œ\íõIù³5ï⪢háù#ZR‚ ¨µ*µ¤äb‰/-©©XÔ^ˆÄS±ýy9ùªÿƒKϼLrlšªÃ¨²‚üB²Ó³1·y>p:ˆMZª¬þ*%©×?üS»¾Ð,¾ƒa®•Êê\†ØºÕWuÿÊ®n#¿ò Á~ûTJ•ådå—ŠqIí ™™™$$$àâRñI45©¹k ÌÍÍkµÎU)IÙ×sãå©ß—p §¦bz¨Õ_−`ÂÛ3k½Þ2‰‹?UiýU¥©©$©ç½¦¦ØîÆDqî¯?yeÔÄZ-72ü6/œ©õzËèꫤÞ*wœkëê£ãØ −òk"¥e`‰‘SÛZ¯·Œ¦¾¹JëEjÜí(ih`d化l‹„úŸ–1(2EÇ$¤Öƒ=tL"Tz Sµ—T‡'ºº'KZªàÂ` ZU~œNu’%ÕÖ¯î"B¹w7œö=†Wi½"éézRJ‘d@‰¤SëÇB‘¤¯’zUM}?f…§®Fëàê m^„‹{köý²Œ´äx:÷I‡/àw|gí¢IËÎäfg2tü‡Ä„ÿMBìÚu ÀõŸ1òíÏÈÏË!+#€›WàPß•ÓÞ[yù9æçá½s−E… ó> ›¶VÙ¶ OÑ’zN…\óã=ß3æÝE4oÓƒe3^¦ëÀ±¼;o#Ç÷m$,ø wB¯s`ó×¼5û;l]ؾn%EEÄÇ„ä¯,ë¯#;HˆäÖõ øŸxï\ËK'±¶«G½†Í11·bÒŒ•xï\C“–©ëÒ€:ÎŒ~wü…¶Ý†2jÊÝÐ+m=õúšòos+æ¬>Ä{¾'+='—¦hi×þxáé$’Ôsªe‡>åþ×74æ¥IŸTX®i«hÚêöþ´T9½CÏ•W[´ï€C}Wê+îÑcÈÄråXÛÕeì{‹«−~áù!N÷„Ç6tü ÑjhI í…þ£T‚ð−)AÔJA~iÉ÷”WVDKª òó”…çWJb¬ªCxfäç±ð½þ‰–¦z9¦¦¦† ’T• ?ƒŒ´$U‡!¨˜…µ=uÿqáAøïÊ”VqzkãÆ% Þ̳²²*Iª Ê®b ‚P½þ™ <<>¾~JJJë¶mÛîVu,O ¸Ð-[·˜ª®(ɲ\ñÔ I’vȲPö$Èa@—Ò¿7Ó€X;m? Ø[«k£á9ö2° Å{;ø h ÜI’ÔP’$SÀHz»s Èé²¾wàõÒi3•@P‚"‰”ÖuX’$ýêÞ Êî‚°L–å‹’$ €°Òé÷P´F dYö‘$ÉE–~\šÀ Y–ó%Išü $•þL–$ÉH–å¬'ÝAØ*ËòVI’,€À¯¥ÓO¯ haí—ey€$IªXþrY–ÏJ’ÔE² −…¢Arô¿nÀƒ*KR÷J[¢hE¹•þÿGi¦¥"{–•Q$¡‡• .Ërþåk?Pþ·U ^„J=ø–¹ÿ‹Q´¬ÒX>µô·Lù³«‡½(ÿÁñ'þÄQ?Ä¿ÝOê/à]`»,Ëé’$YÀ`(ŠsØAÜߨ;(²èf ÿcÔ} l”e¹H’$'ÑŠ„j¢ÊW–åI’ô#}Ä+$IZ−J—ÚK’¤ Ô;}ûÈÉÉ¡¤¤___¦NJXXØ£W~NhhhèשSgóåË—Uv; ¡æìܹ“[·Ã”JJJ8yò$}ôEE5rvõÄLMMç_¾|ytu—«öO0nÞ¼9vvv ¡¡Á®]»hܸ1ß~+¾Eóº

EMB in JOnAS 424 Using Enterprise Media Beans with JOnAS

.dÔ¨Qhi©×Ë]z÷ê.Wí[Ræææ bùòåSTTÄG}Ä„ ظq#o¾ùÌ€wî;vdÆŒLŸ>eË–ÕÜÎjUDDúúútèЇ=Üßߟôôt€J“Y»víh×® ¸Ã(îõO'Nœ`øðá4kÖŒÆãëëûß7ä)¢−)kkk¾ùæZ·nM÷îÝtè Þ¤k×®lÛ¶ÜÜ\vïÞÍèÑ£100`ñâÅôîÝ///êÕ«Ç¡C‡ZþÍ›7™4iÝ»wgÊ”)]nÅŠ„††booÏ÷ßÀ²eËèÑ£-[·ÆÁÁAYOll,°sæLüýý9rä}úôa„ xyy±råJe…ðô;räëׯgýúõdff>t¹ýû÷sðàA´´´077èr—.]bÚ´i¼øâ‹Œ]ñöàegÊßeÓj‘¤öíÛG÷îÝ9sæŒòSªì˜>>tëÖ=z°}ûöJ/ 999(û«’’’”Ój‘¤ÊüÒ³gO²³³ËÍ{ñű°°`ñâÅxyyѲeK222HHH Q£Fxxx©ˆˆ@Ñ8iÒ$Nv97oÞÄÍÍM›6UK\ëÖ-ÃÍÍM9æIx¶øùùáééY±Iºwïï¿ÿ>þù§rZ‡Âd}úô¡OŸ>üþûïU¾â6jÔ(<==iÙ²%=zô`îܹ>Ñv=ëTÖ'uùòe’““ #))‰–−[¢££CŸ>}»Œ¼¼¬,+ €V-ZaggÇîÝ»øꫯpssã³Ï>ÃÉɉ6mÚ(¯Î={–;biiIÛ¶m•æ$Ë2 ,ÀÅÅ[[[ÆŒCRRÄÙÙ>üðCÜÜÜ äƒ> }ûöÊ¡ƒ~î®Ä< ÜÝÝÎlÆ ÃÓÓP\I(š½AAA¤¤¤0räH†Ê¸qãÊ]V.súôiæ̙Ä pwwçôéÓܺu‹ŒŒ ^yåFŒ¡|h)@ïÞ½qsscÆ ìÚµ }}}Ñ’RC3gÎ$""‚ˆˆºu릜ޥK\]]•§JÊG¨éééaffVîB–––rp°‰‰ ÆÆÆ4kÖŒîÝ»óÃ?°k×.êÔ©Ã Aƒ*ÃÄÄ„ÜÜ\Î=Kll,ü1÷îÝ#==k׮ѪU+öìÙƒ aaaüø㸸¸0}útå-„„eyƒÆÁÁåâ™3g’——GÛ¶m±±±aïÞ½Õ·#k‰Z%©²ÛPŒßýû÷ãïïWv¾_Ùˆ]+++ådYVÖZî÷?oQvëŒ[·n‘——GLL ¶¶¶ØÙÙ!I—.]"==]9Æ@’$Þ{ï=† x饗033ûï;F¨VqqqÀíÛ·•ÓËN·oW–„nܸÁÍ›7+”U¶NY¢˜:u*W®\aãÆŒ?þ¡Ox)..ææÍ›ÊrÓÓÓ±µµÅÊÊ WWWnܸAdd$ëׯ§K—.pKKKN‹−ÂÁÁéÓ§säÈ,−−‰îØãÇÇÈȈˆˆ^ýõÿ¶C„±eˆÎðáÃÙ¸qã¿.[¯^= Ä;*}rð!ChÐ ãÆSö Ê„ºuë’™™ù¯Ç@vv6−[¶dêÔ©tèÐE‹¡¡¡Á–−[ˆ§N:ÒsæLŠ‹‹?~sæŒ,˲ºuKYÖÅ‹å;vÈ~~~Êi‘‘‘²¯¯¯œ››+˲,geeÉÞÞÞòîÝ»åèèhår111rpp°−¿öÚk²$Iò½{÷”óü{÷¯ª6Çü׉F‚ "Ò;åDE‘d©¥OÑ)ïpò!”€àÞÐvíÐ>“KKp1tP¢à¹C©˜ëŸr¯¹ÍQ¾ŸIrò#×pùœ1Æw»]ÈwëÖ¤Äãº.o4¼Õj]5Ïb±àËå20æy_-VÏšÇóŸÏ¹ïûWÕsÎ]þ™óP±X l—›Íý+‡cÄ Œ®)T*•ýçB¡°ß^~ú;""Ó4É4ÍÀ˜®ë¤ëúþ{2™¤N§sTG·Û¥ÉdB²,“ëºÔëõ(›ÍÒf³¡Z-F³ÙŒF£ÑÉ. pßÖë5år9ªV«4¯šëÔ;Ÿ/9f=•JÝôñ쑇Ô−ê÷û4Ni»ÝcŒÒé4ýYH T.—)“ÉD\%D!‘Hü}„ ¤^@Qª×ëGã’$Q»Ý "€û%ÔÂ9ÀS)B „†¡!¤@h)B „†¡!¤@h)B „†¡!¤@h)Ú¹V−?mÛJ%5êBà2ß÷ 'Ãv2¤8çß−ËjhšöY–å‡W»:„â\£ÿ[Æ9ÿeYÖ;UU¿*ŠRºø·Ã ÂôæRAÇq>äóùo¯reU‰PNG IHDR,ár|ˆ«sBIT|dˆtEXtSoftwarewww.inkscape.org›î›ºóZääæfäæææåççÇ>·…U9ÙXX×.wjêšØ:ºU`X‚ ¥ihj¡¢úB·/?Õ ?-A¡ª‰„%‚Ò K¥!– JC$,A”†HX‚ ( ‘°APÿmPD sùÌïX¾‘)Ÿþï÷ªçµt÷FÛWÍ`ÜŒõUPÝT«„uãâ ²2ÓQS×ÀÓ¯−‰ñ Àº¶ V¶Nÿi?~Ù¤Gyoðÿx£M÷ó¢#îpúŸ ˜ZØVzºyé$™ieγqpÅÒƱR·ÿ2î‡ßfÞwé÷}èWÚ¶ÅÞçô?€ê‘°¢ÃïrCñZM]S lÝQSW¯ÂÈ^OÕ*aÍŸ4ØèP–ŒÁØÌŠ=ë°eÙôõ#½>þßÚFÈ-Ë−º²æij—© Dtx0³¾îʃ1hjëTux¯j™°LÌmîÞ$$è·¯ùSÛÙ“7ßêƒ$I%b»yé$·®œ!%9CcsœøáæÕ UµjùñþOªåÕ÷nI ÿA®;„,çSß»%'÷¯SÌÏÊÌ`ÆØw¹|f‰õ6ý9iK*~uãè®Uü6e0ùùyœúgyeœÒì\3ÿÃ[¯M−lK%¬ä„8†v)}—ùŠ_Ç2eÑ?¸z6)ÿ?Ãæe?±ö÷ïå|Å´õ‹'3eÑA¬k;p`Óbì\o«nŠ„µzÞBƒ/Ó{è$EÂZ5oa·©ïÝš Ë'ÇÅÿÈ6·T\ ±Ñ|Úµt?ÛŠÙcùþÃÔ-ïCb\ ³ÿWòôïðåÞ±€c~U$¬£»V±{íÜË–•°6þ9u‹«façTŸ”äG$=zÀöU³X¸ãöîƒËLO−üKÂÐÔ€¼¼2äMÚödàèYH’ )Iñœ9´¹mϤ¡m‰ÞC'*E¾gÝ|Nî[‹¶®Ã'þÉ·ówS¯qKâî+.X¨©©óæ[ï3næF~Ysñ³¶ «oLØí+ÛµªÔv#î^gÄÄ%x¾Ñ(ør*ò *¤0YIŒœ¼Œy›¯óÝü=´èüªÿñ©ÕUµÜ+7¯f¨¨¨r÷ÆZué_j~Ñ7ôûæÐúíè™òíà\´-`º«gSFN*hUXÙÕaÒжܸxœ˜È{Ô²«£XÞÈÔŠ¡ÿûI’8õÏîÞ¸@\tøK/€´”DÏP¼®×¸%õ½[)^Þ^P'»õMÇw‡`mïÂÈ.ܹqûá·±©íB‡w?¡m·D…‘ŠŠ .^ܸxLqÜŠ{§ß—tx÷lݸzn¸w3€zÞ−‰½ª˜—”ËãÄ8Ö,ø†õ‹§(Nod9ŸØè0 [RÚºØ9¹àà≖¶™©¼¬G±÷ùõë÷ ŠØvý=—ýE- ùÉiëèlj»pîèþüid™}²eÕ#Å{¥÷ä½Ê)ÜG׆Ø9Õ'2äü8œ¿¡¾w+º¼?Jñ%\ÓTË„(ö§u…{Ãæ\ÆÍK'ÊSB\ ›–þ@»nƒ¨í챙Ʀ_8¢Ó½ÌæWîÞ¸Àý°[üøeÉá>Ív#SÞé?š−Ë~ÄÿðüoÁÂÚcsEÀíëçøñ‹’}H)IñLÕ(è/ùqÅI:÷Á²_¾ èòI>lcF^nFͯ˜®¡¥Ã¨)˧ Í;öfÃSÉÌHåûo¡-k€y-ÚÄż|s³ö½Øö×LÂn²â×18×÷+ÕçÒ¹÷þš3ëGù¨999YŠKYÚuÄ-+§ »È¯_÷ †5tø†Q!Šã]\Ñ4óZµùsoMÛ½K‹N}9¹"6−m=FMYþÒûú2¢ÃƒY0yP‰i~íèøÞPz:‰sçÆyÅþÑÕ/HTöuêS¯qKn^:Áêùزü'ÒS“Ÿ:ÎðyòrsØ¿q!û7.DEEY–§ÍíºzÎÚÊ©Z%¬·?ø‚´”ÄRãd}ú°óZµ cûóZµ9lÙ™¸7|“>-C^¶ÿªëûŸ‘’üw¯ÒÚÅ}þý_ø´|›sG·“‘–‚um:ýßð˶nLü}Çv-BRQ¡û€1ܾvÄø˜C:ýß°RÓú|:©eWpú-¦®ÎK±cÕ,"CnRÇÝ›V]û+®Ìõvÿp,–¶N\8¾‹œœ,ܾI½Æ−8{hs™w ´ïù1uêy|ÕŸÇIñäçåâêÙ(8 }Ö{ «o¤øûËékðkÝóÇv‘Š-ƒz/qïeÃ6ÇÕ«Ù3÷¿¹7z³Dljj™ZâàâEÝú>ŠéÚ:zL_~‚ã{ÿæzÀ1Ò'¢k`L−»ºø¶*øB”$‰I¿ícïÆß¹w#}#SüÚô 7;‹{A±uª§(¯÷ÐIÈr¾bš¡‰…"Â!"FfVŒ±à+gIˆ»OnN}Åéj•¸A¨yb£ÃØõ÷\Å/jÒÐ6鮵ÍòÞ{ï½Õrà¨

EMB in JOnAS 425 Using Enterprise Media Beans with JOnAS

BYDÂAiˆ„%‚Ò K¥!– JC$,A”†HX‚ ( ‘°AP"a ‚ 4DÂAiˆ„%‚Ò K¥!– JC$,A”†HX‚ (—zÖƒ¨âDTV,BÓÕ7ÂѵaU‡ñL1wyUÕa/¨ªëÔK%¬k¿Gß°´w¯êPjϺ)˜ÖMGßXïù Uîè |>ek•Õ©—JX²œG·‘m±r0¯¬x„ täo‚N®Å¬×xT5õ«:œ§È§ãÇÍER§7]®Ò:%ú°jºü,4³¢äüç/+/¢ ë”HX5œ„Œ ùývŸ üWUY§DÂAiˆ„%‚Ò K¥!– JC$,A”†HX‚ ( ‘°AP"a ‚ 4DÂAiˆ„%‚Ò K¥!– Jã¥/Sݤ$¦qfÇ%\|ql` @fzÇ7ÀÑÃoÇ—*7äZ$MÜ‚g+7zîÄ•§8½−€>ã»R¿™sÅî„P−Ü@úã Œ, x£‹—bºÿ@’ãRÐ1ЦŻ>/]îý‘—›ÏÄ #‰¸ÍÒ õLx>¥NXq‘øeÐR»ÿo”XÏÌÚˆ÷¾|KQ¯¢Cb¹°ï*‰±ÑÔÖÀ¹qm|:zTþN*‘‘°ê5soNo»¨XVÞýÃg@|t"Ã}6ÍÚǤM#±v²`ù·›ÉLËBKW“{,»_}ƒÇ›.¯z×…JÖ´[cv/>B¯Ño±çÏ£4íÖ¸D½J{œÁH¿)Ü¿ó'O;B¯G±yö~~;7m]M ¢ZÐu}/–yÃWÒöƒç 1Éôþª3Cg¾_U»_íÔˆNwMm º|ÒŠÃkNó÷ôX:˜Ñô’Ê_òõF²3røqÏfþgo¶Ì=Àƒ°8v. ^ÓºÏìXÏÎÌæ›®³¹v"#K´ÔHŠK©°}ªW_'ÜÞpÂW õšÖÁÕ§dhda½Z÷ÓnÖý´[1=ôZ$oGÔ4J¶Þ‹Û2÷«¦lC]Ss;äü|Ç‹zU\haXؙҼ‡7Úêtþ¸eéùö¦ Á¢‹SÙ¸í‰ Yz}:ÛÕÃÜÎx’ÔÂoÞêvn_ ãÚ‰`¼Ú¸³ùÁú×-rvH¨6z|Ö¡ÄÿÅYØÔÓÞUÔ«1óè?±;v² ë"ç0çø7 I½+J¯Æ´°ù¦ël¼Z»‘ø ™k§n³3y1]‡¶fûo‡Xö¿œÞ@Ô‡O−ÇÂÞ¥ Un»Ç¤ó¸(~§±¦k߯íû5 #µä•ân#Ú±û£ü=}Aþ÷PQUáÆéÛŒ˜×ŸvüÅÕבë§î0¬ñDÒS2QQ{zÁºI±)üðþB$£ª¦ ²xqJ°Œ− ȹ>u−JÍ«ãeÏ€É=hPØÞ¦ÏغXqbóÝOÀÕב÷F¿…¦¶¶ÎVÌ=ù−þ:‰±…Ÿýö!§¶]ÄÉÓŸ ÐÒÕ¤v=,ìLùyÿ8¯õÇÂ΄Á?¼ÇñMpô°}¥û.T®Ÿw %! õ©i¨1`r L ~GÑ´–˃~fÿòDÞŠFC[ƒê_gO$Iâç_±é×}d¤fÑiP Îï»J~^Á•Fs;Lg“6bóìýäåÉ Ù‡Ë‡o’•‘ýjw¼šSú„õÑ”eΫãeO/ûÓœÕƹQí2—wõq,Ñ?Q|]ï ðîÐ@ñºa›z4lSOñÚ¡¾HV5Í»Ÿw,sºº†Z©:ghªGŸ¯º”¹¼¾±.ƒè¥x]¼^YØ™–(ËÌÆ„a¿~ x]·aÙuõuVcú°A¨ù”®…r−’;ÃJLSUS¡}ÿæUP¡¼ÜªªÕë{;5) IE]íª¥ÚQº„unÏ–ýoS‰iêZêU°.¹É„·fÑáÃæ|½rh•Æ"”ö8!•IÝçrýÔ‚ Cÿ‰Ýøý{U[q9Ù¹ô0…½ kÃçTu8ÕÒ%¬"]†´¢×˜‚F%•'ߡף¸tè™iY87®_ç‚WÅ$qfÇ%ì\-ÐÐÖàâÁôü¬=§·_"?_¦qûúßx›º–4ïá͵S·¹vâ−\ñhá ÀKa\9~‹”„4ôŒtðl冫#ÉRñß@ÔíìZ|'O;q£t52gè ®ŸºCöîLX5Csn!%!U±ÌÅC7¸Ššº* ÛÖSôwÞ¹Æ-ó!xµv#êöB¯Eá×ÙçÆŠy Û¸cçZ €ã›Î“’Jç[¡ª¦Jй{\= \À)êÇ åv@( Û¸z=Š‡áÐÑ× #5‹]‹`h¦GË^~ȲÌÙ]— ¹‰‘−{ùbbU0Îëìî@â£hÖ½1þ»Ñ7Ö¡e/¿Wvl_%¥MX¢“ò¿€‘…v.Vúû 3?ú −u´õµI|Ì[ƒZðÕòOˆºý€yÃWR«ÃãÉÏ˧Àf,³–Ì´, Lõxü(•Üìªø-TóG®dçÂ#Y蓙ßã70æÏAtþ¸þ{®°rÒV¬Íxü(•ôÇ™¬™¶ƒ·~ÉLï»÷,òo6ñíÚá´ú??üw²zêvìÜjƒem3äÂa )‰i,°G[Zöòcb÷¹øï ľ5±X9yóÏNÂÎÅŠ−söx$ˆ-óþ!28†öý›ÕØ„U½NÞ_¹=WøeÐR~´”5Óv·ß,¹ö#ë#çàäeÇ'¹®Xïñ£T–\ÎîÔ?1µ6 7;/dâÆQœßw•ÕwgòÑÔwA†K¯ðåâü´o¿—¦ôàÈ:êÛ2eëç´íÛ„I‹òsïWs „çJxL~Œ†¶:ÖN¥‡ÀD‡Ä²sál]-XÙ‡·f ª¦Â¢1k ÀÑÃ퉋x{Xr²r¹z"Ç¿:8zÚqjÛE2Ó³8²ÎŸüö?TUUøcܺÛ×7ÖaÛ£…,¾ô=+oÏÀÂ΄I‹™{ò;.¼ÿ®@üºx2ëð׌_ñ ) i¬ù~{‰rµ«Ç¾ÌeŒšß¿bõ ´−¬â§„šÚd¤eñè~"ÆV†Ôr4À¹±!W"‰ ~€‰•!ÞêSÛݺDYêšj¼ÑÅK1`ÔÅÛ,kŒbNMÎ`Χ+8²Ö=cÅ8œä¸Ç•¿³ÂRô^egäûã=#êöœY¡Ë'-€‚DÙ}T{vüvˆÑ−~ n£Ú„ߌFEU…ESË,KUUG[B®DÒÛúsڼ߄!3zãâãÀéí—HŠKÁ´–AçîñfOoFÌéWqI (]Âjð¦ 'O;Îï»JFj݆·¥ãGo-¬“{P·aÉÑïïÝUq»–©^‰[}ŠßÞ£¡©Î¬Ã_³sÑôuÊó}¬=‹™MA?˜±¥!óÏLäÒá›d¦ea]ײ‚ð²¬ëX²ìúZs†à !¨¨ªàÐÀ–¶} ¾TP«µúRÁÏÈl¦Ÿƒ)»EVp)ü»3`EÁçÉ ø¿ŠÛWãU—eù¦,ËÉÀF Õ ®×X#Ër>°ªh¢$I ÿ½QÆ:ëeYζSðæ Bu·C–åY–ïÁ€ë ¬cdȲ|E–å4`€$IµŠ}>ìËXo,ËéÀ>”ðóñªî%,þ¡ ü{0] Sø·~±é9€6ýTÅG þ ÿ«¬ìb늫 ‚2xÑÏÇc|>2)ù™Ðòt|>RËØVv±ÿ•îóñªö$©›$I^¤Cük~€X’$wà³bÓÿæK’Ôø¼h¢,Ëû ÿ…Vvà‚ð ¼#IRcI’:–ÀíÍ>+üü eù1pO’¤¯ ¯ôQµú˲üP’¤| ÎÁRp?XLÁy=²,ÿPØÁèBÁ)aû2ʶþ½(Jb€u¾'‚PñÖSÐOe¼−Ër¾$I€náü/)èãê|Í“†Fo ú…M(8%Œ−£ì@µðï…¬F’$Û³òÞl.•J’$SSÓÌÍ−¸ 6j éÔ©SEÿÚ¶m«ãää´~úôé]ª:6A8r䈢~ùGGGE´··çرc/›‹‹ Æ {éõ„š!LB¨77çÎ;8::òÇ0räH¶mÛ†··7»wïæÑ£Gx{{³}ûv>ÿüsY¿~=®®®Ï−ÛÓÓ“õë׳|ùrfÍšÅ/¿üÂèÑ£Ù¶mqqqн{wœÉÉÉaÙ²eÔ«WÄÄDî߿Ͻ{÷gïÞ½¤¦¦Ò°aCyÿý÷122âúõëœ:uŠwß}·ÆaTiÂjÐ +W®$ MMME‹æÀL˜0kkk °´´dòäÉìÚµ ___ÂÃß[¶‹‹ ÖÖÖhhh––FRRË–−ÃÃÃ[·nñÝwß±fÍúõëÇÏ?ÿÌÍ›7ÑÓÓCWW—¦M›’ŸŸOxx8ýõvvvüôÓOìÞ½›Ý»w³yóf†Î¹sç*û

EMB in JOnAS 426 Using Enterprise Media Beans with JOnAS

UDGG===–−[Æ;°³³ãÿþïÿ˜;w.§OŸÆÔÔzõêEëÖ-IJJÂÃÃ{÷î=³l−−−ÜÝÝñõõ −− :„••Þl`Ò¤Iܼy†¥¥%***4jÔˆ°°0Î=KHH³gÏføðádffòå—_2mÚ4>ÌàÁƒ+õU…*ït_¼x1«V-BSSµ’ùó›o¾!((ˆ:°k×.ºvíÊùóçÍjÔsË-[·.öööäääðÅ_`aaÁ¤I“°´´¤AƒH’ľ}ûËgeeqîÜ9îÞ½ËêÕ«QSS£M›6øûûÓµkW†Î¾}ûˆˆˆ`óæÍÔ«W??¿ ?BõÍÂ… 9zô(zzzÿ•ôÌÌL>ÌíÛ· äáÇ̘1ƒ .àááñÌr/_¾Œ¥¥%}úôA__ŸO>ù„·ß~›÷Þ{ÜÝÝÉÈÈ(Ñ•aeeExx8{öìaÑ¢EŒ?š5kF»víøóÏ?IOOgÏ=ôïß_qc|MRå ëìÙ³ÄÅÅ¡¥¥Å¸qãJÌkÚ´)€¢½¨SþE:ç§NÊßÿMpp0Ÿ}ö›6m¢S§Nܼy$I"%%E±¼µµ5öööO−oÈ!hhh0cÆ R#¿½„’×n¬è â×_UÌ366VœþÕÏ¢Ó¯ç†ÙÙÙ1sæLvîÜIhh(>>>|ñÅ (HN©©O~}ÎÇÇuuõ§–ùÙgŸÄ7ß|CZZƒ zùVUvJÂüùóñõõåÞ½{ø€… ¢¦¦Æ€Ê³Û‚’غu+AAA888°gÏàI"(þœ§¦M›¢¢¢ÂìÙ³yøð!|fÙfff|ôÑG%¦………¡©©IÓ¦MY¸pa©uŠoÏÄĀߒ››ËgŸ}Æ;＃ƒƒóæÍ£qãÆ¥>K5E•µ°ttt ãÇdóæÍôë×M›6ÏÑiÕªzzz@Á›µiÓ¢U«Ve~“yxxЪU«o0 hv¯]»KKK:vì¨hº7nܘiÐ ¢ƒ ¾ÅºvíZã:3…’Œ9räßÿ=·oßfüøñL:///š7o®XÖÝÝ%K–››‹¿¿?Ÿ}ö-Zµ*ÕÅТE ¼½½KMŸ>}:Ìœ9“.]ºÐªU+lllPSS£U«V¸¸¸(–mÐ S¦LAMM]»v_¸#F ¯©-+¨Â–••Û·o/s^ß¾}éÛ·o‰i>>>œ,€äädnݺU渕êâäÉ“>ððprssÉÌÌ$,, KKKâââ$ gggâââ¸sç¾¾¾¨««“œœLLL ööö„„„ ¦¦†››[™åçääpýúuòòòðôôT ¸u놆†È²Lll,^^^¤¥¥qõêUÔh€¢Œ[·n‘€‡‡‡ââPXX²,caaÁ•+WpqqÁÌÌŒˆˆV¯^¯¯/:u¢V-Z¨««DRRŠþØ V®\Inn.>>>ØÛÛóí·ß’˜˜¨ØvVV×®]CEE… ”Š_]]àà`Õj„N¥¼Gåæìì¼#44T~+W®”yùòå²,˲¾¾¾ìèè(ëëëË€Ü-[7ÙÙÙYd+++999Y •ÙÓÓSÖÖÖ–¹]»vr~~¾¼bÅ ÷ïß/çææÊÝ»w—%I’−,,dùÀ²,ËrË–−eÙÑÑQä† ÊíÚµ“YSSS¾råŠ,˲ò?ÿü#Ê®®®²¦¦¦lgg'ÇÄÄÈ}ôQ‰e'L˜ Ϙ1CäK—.ÉééérË–−e@VSS“õõõå;vȲ,Ë-Zµ’õõõe777õõõ刈ˆ—:ö^^^òÈ‘#å={öÈYYYŠé¡¡¡²§§§üÝwßɧOŸ.±N¿~ýä·ÞzK^ºt©€A–e”埥¥å7ûöí{©c4`À#""dE½+zφ.ëèè(êª,Ëò’%Kd@ööö–ÕÔÔd@þñÇÇsssåððpÙÅÅEÖÖÖ– d::ZÎÊÊ’ÙÕÕUÖÒÒ’ùý÷ß—mmme@®[·®œ••%gffÊmÛ¶•UUUe333ÙÔÔTñ~yxxȲƒƒƒ Èfffò£Gä7ß|³D[²d‰TXÖãǹ~ý:o¼ñ;wîdÚ´iüüóÏ|˜'N”(gëÖ-ìرƒ©S§rìØ1,,,øòË/KlgíÚµ Ê„ÀÀ@üüüØ¿?YYYìÙ³‡~øázõêűcÇèÒ¥ _}õIIIŠ2Þ}÷]nÞ¼I^^;vìà»ï¾£[·nhhh‘‘ÁêÕ«iÒ¤ —/_fÁ‚L˜0ÈÈH6mÚÄ’%KðôôÄÕÕ•ŒŒ ¦M›V"þ¥K—râÄ ,XÀÇÑ××W\]„‚¾ç͛ǚ5kHIIyî%p¡bXYY…ŠŠ «V-âÆtìØ‘Ý»w“-X®iÓ¦ÄÇÇãééÉ´iÓ(zÈ\‘~ø»wï²cÇvìØÁ;wø駟󳳳¹wï...¬_¿¿þú‹¯¾úŠ»wïråÊV®\É‘#Gøõ×_9vìêêê%ÆÆÆƲqãFæÏŸO||œŒŒŒR¾ýö[¢¢¢¸ví'NœàîÝ»%êprr27nÜ`àÀ\¸pÈÈÈ }þ« KXÕÂÞÞºuëðöÛoãìì Pb€¦ŸŸ´nÝ Ôm6E·5,Z´ˆÎ;“““CVV–bÜ”©©)Mš4Q ÚëÒ¥‹â’oJJ !!!ȲÌáÇéÔ©W®\ÁÚÚºÄïÓ§NNNŠuTUUQQQA’$´´´PWWgëÖ-Ô-[— t@Ë–−111¡~ýúDFF**¾±±1;vTœ>?6Båi×®î66˜™™áé鉃ƒNNNäçç+~´nÝCCC|||ÈÈÈ ..®D9EõsÈ! {{{óßxã ¬--qttD[[›¶mÛ*>©©©Šõùåºv튦¦f‰‹MNNNøúú*êgjjªâ”MEE−−−TUUËf ÞdÎœ9Š:§x:„ªª*ZZZ¥Æ†††bnn»»;M›6EMMÐÐPÅüæÍ›cgg§¨ŸÅ¯V–°ŠÔâ¯ÿíèÑ£\¹r…−[¶P¯^½ó‹¼}ôÑGܺu‹ãÇóóÏ?—*÷iÛqwwG]]¦M›ÈÅ‹™|X1¾ î3J-§--MDD¤¦¦²{÷n<<;;[ ºèM’¤ËÎP^W*•¯›››÷Óé´¢Z-ÖEYK¥R¯ÆÆÆÖ‚®úãUh…‰ˆö÷÷kGGG˦if»Ô4−¿µµÅæ¿Õa9ÒRUõ§®ëY"*u¯×4íq6›÷Ó4üçEh]6¡$©JD/º\__´»»‹À‚Àɲü‹þÚ>WVVlooÇYíÿW €,`Æ•} kµš½°°àW−àB£Ñ Ó4ƒ.ÃWÍfÓ\]]¥pØ·öšàB»Ýv=Æ•ï´(ŠK-Vë−Ïó ×3§FFF(™L]†¯AxØjµÞÑLе@o’$Q(äî¤îÊÀ*—Ë_ …ÂL„B¡ §ã€†åfi""UUÍb±¸ image/svg+xml «ear» «rar» servlet−publisher «ejb» emb−core−ejb «war» servlet−publisher «war» user−webApp «rar» ffmpeg−mfb−plugin «rar» apache−publisher−plugin «rar» jai−mfb−plugin «rar» darwin−publisher−plugin «rar» svg−mfb−plugin ApacheHTTPd DarwinStreamingServer JOnAS user App provided by JOnASEMB core application additional plugin request publish convert image/svg+xml Enterprise Media Beans require Media FoundationBeans Media EntityBeans EJB 2.0Entity Beans Java 2 baseTechnology require require image/svg+xml Media Foundation Beans MediaFormat MediaConverter plug−in plug−in 3rd PartyImplementation 3rd PartyImplementation

EMB in JOnAS 427 How to Develop a J2EE−Compliant Web Service (endpoint + client)

• I. Introduction • II. Server Side ♦ A. Coding ◊ 1) Service Endpoint Interface ◊ 2) Implementation ♦ B. Server Side XML Descriptors ◊ 1) WSDL Definition ◊ 2) JAX−RPC Mapping File ◊ 3) Web Application XML ◊ 4) WebServices XML ♦ C. Deployment ◊ 1) Packaging ◊ 2) Artifacts Generation ♦ D. Installation • III. Client Side ♦ A. Introduction ♦ B. Getting the WSDL ♦ C. Coding ◊ 1) Service Endpoint Interface ◊ 2) Service Interface ◊ 3) WebService Client ♦ D. Client Side XML Descriptors ◊ 1) Web Application XML ◊ 2) JAX−RPC Mapping File ♦ E. Deployment ◊ 1) Packaging ◊ 2) Client Artifacts Generation ♦ F. Installation ♦ G. Testing

Introduction

This Howto describes how to create a Web Service Endpoint and a J2EE client that uses this web service. The endpoint will provide a method for computing the compound interest from an initial investment, an interest rate (percent) and a time quantity.

Server side

How to Develop a J2EE−Compliant Web Service (endpoint + client) 428 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Coding

Service Endpoint Interface

The first task is to create a Java interface (aka Service Endpoint Interface, SEI). It must extend java.rmi.Remote.

The SEI will indicate the methods that will be used throughout the web service: that is, the web service interface (in the same context that an EJB has a Local or Remote interface) or, in effect, the Business interface.

package org.objectweb.interest;

import java.rmi.Remote; import java.rmi.RemoteException;

public interface Interest extends Remote { double getCompoundInterest(double principal, double interest, int terms) throws RemoteException; double getCompoundInterest(InterestBean ib) throws RemoteException; }

Implementation

Once the SEI is created, an implementation for this interface must be provided. For the sake of simplicity, this Howto will expose the web service as a JAX−RPC Endpoint (i.e., a simple class, with no EJBs).

package org.objectweb.interest;

import java.rmi.RemoteException;

public class InterestImpl implements Interest {

public double getCompoundInterest(double principal, double interest, int terms) throws RemoteException { double total = principal; for (int i = 0; i < terms; i++) { total = total * (1 + interest / 100.0); } return total − principal; }

public double getCompoundInterest(InterestBean ib) throws RemoteException { // delegate to the real implementation :) return this.getCompoundInterest(ib.getPrincipal(), ib.getInterest(), ib.getTerms()); }

}

The JavaBean that will be used in the SEI must be written. This JavaBean is not an interface; it is an actual Java Bean, with default constructor, setters, and getters: package org.objectweb.interest;

Server side 429 How to Develop a J2EE−Compliant Web Service (endpoint + client)

public class InterestBean {

private double principal; private double interest; private int terms;

public double getInterest() {return interest;} public void setInterest(double interest) {this.interest = interest;}

public double getPrincipal() {return principal;} public void setPrincipal(double principal) {this.principal = principal;}

public int getTerms() {return terms;} public void setTerms(int terms) {this.terms = terms;} }

Server Side XML Descriptors

The difficult part is bringing together all the XML/WSDL elements.

Since this example uses a JAX−RPC endpoint, the web service must be packaged inside a web application.

WSDL Definition

First, generate or write (whichever is preferred based on the level of familiarity with WSDL) the WSDL Definitions associated with the Interest interface. This WSDL will be updated and published by JOnAS, to be usable from one or more clients.

There is a helpful Axis ant task that takes an interface as parameter and generates a WSDL based on that interface:

classname Fully−qualified class name of the exported interface location Endpoint URL address (must be set to a dummy value: will be updated at deploy time by JOnAS) serviceportname

Server side 430 How to Develop a J2EE−Compliant Web Service (endpoint + client)

wsdl:service[@name] just set here to have a visible value namespace targetNamespace of the WSDL Definition (all exported objects will be in this namespace: XML types, messages, portTypes, ...) typeMappingVersion must use "1.3" aka JAX−RPC Mapping (J2EE WS must adhere to this mapping) output the WSDL to be created

JAX−RPC Mapping File

The JAX−RPC mapping file is used to control the mapping from WSDL to Java artifacts and vice versa. For example, in this type of file, the JAX−RPC Runtime can be instructed to map an xml type name {urn:someNamespaceURI}xml−type−name to a Java class (for example, someNamespaceURI.XmlTypeName). However, it is not limited to type mapping.

It is also possible to specify:

• how namespaces are mapped to java packages, • how the inner fields in xml−type are mapped to inner Java fields, • how the portType is mapped to the SEI (in terms of operation<−>method mapping + parameters order), • ...

A simple mapping file is sufficent for this example:

• map a Java package name to the namespace URI • map a Java type to an xml type

org.objectweb.interest urn:objectweb:demo:interest org.objectweb.interest.InterestBean ns:InterestBean complexType

Server side 431 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Web Application XML

At this time, JOnAS must be told the name of the class that implements the actual service (InterestImpl). For a JAX−RPC endpoint, the JSR 921 (WS for J2EE 1.4 ) indicates that the implementation, fully−qualified classname goes into a servlet statement.

That servlet statement looks the same as a servlet definition:

Interest WebServices packaged in WebApp Sample Interest web service InterestServlet org.objectweb.interest.InterestImpl

WebServices XML

The core webservice descriptor, webservices.xml, should now be placed in WEB−INF for a JAX−RPC endpoint and in META−INF for an exposed SessionBean.

This is the file in which JOnAS is told how to link a wsdl:port and its implementation bean (service−impl−bean).

Start by creating a webservice−description element, giving it a unique name (Interest Webservice). Then add the wsdl−file tag with the path (inside the webapp) to the generated WSDL. Do the same thing for jaxrpc−mapping−file.

Notice that the WSDL file MUST be located in WEB−INF/wsdl (or META−INF/wsdl for SessionBean).

Once this is completed, it is necessary to describe how the WSDL will be mapped into a JOnAS component. This is done via the port−component; it maps a wsdl−port (give its QName, {urn:objectweb:demo:interest}InterestPort, which is the port name identified in the WSDL) to the SEI (service−endpoint−interface), then add a link (servlet−link or ejb−link) to the component that actually performs the job. In this case, the job is done by the "servlet"named InterestServlet.

Interest Sample Interest Webservice

Server side 432 How to Develop a J2EE−Compliant Web Service (endpoint + client)

WEB−INF/wsdl/Interest.wsdl WEB−INF/InterestMapping.xml InterestPC ns:InterestPort org.objectweb.interest.Interest InterestServlet

Important: The URL where the web service will be available depends on the values sets in this file:

A URL will look like the following:

• for JOnAS < 4.3 http://{hostname}:{port}/{webapp−context}/{webservice−description−name}/{port−component−name}

• for JOnAS > 4.3 http://{hostname}:{port}/{webapp−context}/{port−component−name}/{wsdl−port:local−part}

All of the XML files are now complete.

Deployment

Packaging

Now it is time to package the webapp.

As usual, the compiled classes go into WEB−INF/classes; web.xml is located directly in WEB−INF.

News that comes from webservices.xml will also go into WEB−INF, along with the JAX−RPC mapping file. And, as mentioned above, the WSDL goes into WEB−INF/wsdl.

Package all of these elements inside a war.

Webapp content:

interest.war | +−− WEB−INF | +−− web.xml

Server side 433 How to Develop a J2EE−Compliant Web Service (endpoint + client)

+−− webservices.xml +−− InterestMapping.xml | +−− classes/ | | | +−− org.objectweb.interest.Interest* | +−− wsdl/ | +−− Interest.wsdl

Artifacts Generation

Now that a generic webapp has been created, all the server−specific files can be generated. For those familiar with EJB, there is a GenIC−like step for web services; all J2EE modules that deal with web services (in a standard way) must be prepared before the installation into JOnAS.

The tool that handles this for web services is called WsGen. WsGen is bundled with an Ant Task so that it can be easily used by developers. It is only necessary to specify 1) the srcdir attributes to tell the task where the archive(s) are located, and 2) the destdir attribute to indicate where the output files should be placed.

Note that WsGen will place a modified webapp inside ${destdir}/webapps. It also does this for other archive types (ejbjars, clients, apps)

Installation

Everything on the server side is now complete.

This last step is to install the newly−generated webapps into JOnAS:

>$ jonas admin −a interest.war

Make sure that a JOnAS instance is running before typing this command.

The WSDL for the deployed web service should be available at the following location: http://localhost:9000/interest/Interest%20Webservice/InterestPort?JWSDL

It is a good idea to verify this.

If everything is working fine, go to the next step, which is the client programming.

Server side 434 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Client Side

Introduction

In this section, a web−service client that uses the Interest endpoint will be created.

Getting WSDL

In a real−world client, it is the developer's responsibility to choose an appropriate web service endpoint. Once the web service has been selected, the developer must retrieve the technical description of the service, which is the WSDL.

In this example, the WSDL should be at the following location (see [#Install]]): http://localhost:9000/interest/Interest%20Webservice/InterestPort?JWSDL

Use a Copy and Paste command to copy this URL into a browser. Save the WSDL on a hard disk. Note that this WSDL supplies the right URL in its soap:address[@location].

Coding

In this coding section one method of writing service clients will be employed and a few interfaces will be written.

Service Endpoint Interface

The service endpoint interface that will be used on the client side is exactly the same as the one that has already been written for the server side. Thus, in this particular example, simply copy the org.objectweb.interest.Interest class.

However, in a real−life client (with only the WSDL and no classes present yet), it would be necessary to either:

• write the endpoint interface that corresponds to the port that will be used, or • generate the endpoint interface with WSDL2Java−like tools (Axis provides such tools to assist developers).

Important: When creating/generating SEI, the parameters for the operations must be identified. If the method uses a complex type, this type must be provided. The J2EE Container (i.e., JOnAS) will not generate it. A simple rule to follow is: The SEI MUST be compilable, thus all dependencies must be available in the classpath.

Service Interface

The service interface can be compared to the Home/LocalHome interface of an EJB; it provides access to the SEI (that contains all the 'business' methods).

In most cases, just using the default service interface (javax.xml.rpc.Service) should be sufficent. However, a service interface (that extends javax.xml.rpc.Service) can be written with meaningful SEI accessors. In short, with the Service interface, the SEI is obtained via Service.getPort(...). However, it may be preferable to use MyService.getInterest().

Client Side 435 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Since this example is designed to be easy, a Service Interface will not be written; javax.xml.rpc.Service will be used.

WS Client

This section describes how to code the actual web−service client: the class that will make things useful with the web service.

A simple servlet will be developed that will read the parameters needed to call the Interest, get the port, and finally execute the request.

private void processRequest(HttpServletRequest req, HttpServletResponse res) throws IOException, ServletException {

// get the parameters String principal = req.getParameter("principal"); String interest = req.getParameter("interest"); String terms = req.getParameter("terms");

// parse them double pDouble = Double.valueOf(principal).doubleValue(); double iDouble = Double.valueOf(interest).doubleValue(); int tInteger = Integer.valueOf(terms).intValue();

// retrieve InitialContext InitialContext ictx = null; try { ictx = new InitialContext(); } catch (NamingException e) { ServletException se = new ServletException("Cannot create InitialContext", e); throw se; }

// perform the lookup on the Service instance Service service = null; String lookup = "java:comp/env/service/interest"; try { service = (Service) ictx.lookup(lookup); } catch (NamingException ne) { ServletException se = new ServletException("Cannot lookup : " + lookup, ne); throw se; }

// get the Port based on the Interface class Interest port = null; try { port = (Interest) service.getPort(Interest.class); } catch (ServiceException svce) { ServletException se = new ServletException("Cannot get Port from " + Interest.class.getName(), svce); throw se; }

// perform the ws operation double result = port.getCompoundInterest(pDouble, iDouble, tInteger);

Client Side 436 How to Develop a J2EE−Compliant Web Service (endpoint + client)

// perform the ws operation with Complex Type InterestBean ib = new InterestBean(); ib.setPrincipal(pDouble); ib.setInterest(iDouble); ib.setTerms(tInteger); double result2 = port.getCompoundInterest(ib);

// print the result res.getWriter().print(header); res.getWriter().print("port.getCompoundInterest(" + principal + ", " + interest + ", " + terms + ")=" + result); res.getWriter().print("port.getCompoundInterest(" + ib + ")=" + result2); res.getWriter().print(footer);

}

This servlet provides much useful information:

• A Service instance is looked up from the InitalContext (java:comp/env/service/interest). • The SEI instance is retrieved by service.getPort(Interest.class);. • Once the SEI is here, the web service can be invoked as if it were a local instance.

It is also a good idea to write a simple HTML page that will pass values to the servlet. However, that is not covered this Howto.

Client Side XML Descriptors

With the servlet coded, the next step is to write the XML descriptors.

WebApp Descriptors

The following servlet is the equivalent of the env−entry−ref for web services: 'service−ref'.

WebApplication using Distant WebServices

InterestClientServlet org.objectweb.interest.InterestClientServlet

InterestClientServlet /interest.do

Client Side 437 How to Develop a J2EE−Compliant Web Service (endpoint + client)

index.html index.jsp

service/interest javax.xml.rpc.Service WEB−INF/wsdl/InterestPort.wsdl

WEB−INF/InterestMapping.xml org.objectweb.interest.Interest

The servlet can be declared as usual (using servlet), along with its servlet−mapping. service−ref must be added explicitly for the web service reference:

• service−ref−name is the name used in the lookup statement in the servlet (java:comp/env/service/interest). Note that it is recommended that service−ref should be in service/ context. • service−interface is the fully−qualified class name of the Service interface to be used (in this case it is the default interface: javax.xml.rpc.Service) • wsdl−file is the path (relative to the webapp root) to the WSDL Definition

. • jaxrpc−mapping−file is the path (relative to the webapp root) to the Mapping File. • port−component−ref is used to declare the service−endpoint−interface of the port to be used.

There is also a jonas−web.xml:

service/interest org.objectweb.interest.Interest ns:InterestPort

Client Side 438 How to Develop a J2EE−Compliant Web Service (endpoint + client)

It is only used to tell JOnAS which wsdl:port should be returned when requesting a Port using the Class as parameter (service.getPort(Class)).

JAX−RPC Mapping File

Because such a file has already been written for the endpoint sample, it can be copied directly into the client.

Remember that, if the client is a real−world client with only WSDL, a mapping file MUST be written. Unfortunately, there is no free tool that can handle all the complexities of the mapping file.

Deployment

Packaging

The Web services and J2EE descriptors have now been completed.

The goal for this section is to build the webapp. This is all fairly standard.

Content of the webapp client:

interest−client.war | +−− (all static stuff here : index.html, ...) | +−− WEB−INF | +−− web.xml +−− jonas−web.xml +−− InterestMapping.xml | +−− classes/ | | | +−− org.objectweb.interest.Interest* | +−− wsdl/ | +−− Interest.wsdl

Client Artifacts Generation

Run WsGen with the webapp to generate all the required elements (including the endpoint) for running the component inside JOnAS.

Client Side 439 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Installation

The final task is to install the client webapp inside JOnAS:

>$ jonas admin −a interest−client.war

Make sure that a JOnAS instance is running before typing this command.

Testing

Go to: http://localhost:9000/interest−client and view the results.

ÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82^¸•5Ægw$Ï:;ùӵċ¼€Y-þÎzvòÉÎk#¨ ¾+²04û%T‹Íó•¢#àÙ•¾Yü¬zã¨"®>±Ó'ºXƒìÏ…s3T •‹ Ýœ ù$`øcNJŒg“Îgiäå‹¢!< #Nƒµ[¹ÒḴ¼Yãk©|ÿ3©Q´«¨û݉õÎ(¹ñEˆ[¬Ç8–ÙÑLLcVmå‚’Kí%‰ 0Û‚ É5‹c7”ßgºu™òòÃäÊ÷°§¯,§¦H-‡,-c−之ÎHãÊË÷R2Ž†àœ‘š°t¸ÄVèÛmmH"ÆK²“−€’Ý2H^@ ôQEQEQEQEQE«¥È"Ï@’5¬ª»´×2Ì 26[ñ=+·Óu }KO†öÚEx¥@ÀƒëÚ¾dñô³Á©E1'ÈAúÿUu> ñm˜°Xk‹V#ᔀ~£¥tÂ’© 78ª×•¾öÌ÷+ÍJÞÍ7I"îk.ßÅ×z¬¶ñ´¯Ó_\ÝÈÈ’KÁ?L×Sð÷D–ÏI÷7·À>OXãêª?ŸãD©(Fò¡«QFu;!Íy¶¥Þi·÷‰swö«‰%²]HK9TÆËÚ½òá,ìn._!¤cÓ¥pÖ¶¤Yè–C«Ïn#®ßÞ7þ‚kÇÆÉóB «=l:V”Ÿc{Rñ—¥Þý‹÷÷3«leÃw$Œ·O”dò8ägNÓZÓnì¡»Šòç—>·Íí³iop— Fód`ªÌò–V' ¿x œ+Ÿ›Uõ/ Þ$ûÅæ–ÙD¹VPBK7—’ÞšC´à€×J”ûÆÚ³Ò5MjËJ°[Ù7eXÄ#y@ëÀÏÐfª\x³K¶Ñ ÔäyDS‚cË>aÆwdvÆI Zàn¼?-êÚRi¶úsE¼,c̈±üì]ÕpO?2 à`+sƒŠûH×eÒí–= J¿*8hsö¢Öç}¢x‚Ë^ŠgµóQ¡ I«†\ŒƒÆAz[Êø+K¼Ótéþ×B%uhàc˜@'h−¸…Ïü+ª-`ÛÙ/p¢Š*„Voˆ5¨|= ßj÷I,6q]#Æâ¦x¬ýƚ嶜–wz-r»â°²@òìÜ{òÖ¢Ñõ='Qѯ§Û−ò.ËŒHGFe,3÷sšé ÄC‘9;~ðëéõ h¬Íw\µðþ‰uª]†1@£äAó;P{– ñ“Î=“â; [Ñk‘È!³hšIf äíÈpç ÚU9ÇœP½Ä?Ä_ëèÄ ù㌄ˆŸõ†0æM¸9?.@çØÁuÔÜ[ÉÐJã–7 ®¤d0#‚Á€b™—\në#"79Ëœ1Ç$dVóÜ$k¹ÙQsŒ³3éÍMEeéºí¾¥>©Fñ:ïì’ÈÄ|lH=|ÜF˜ºaNÖ;‡ÐдU+Ë÷µ6¾]œ·yÖ"ce çqO´−OíÒj-ŸØåòÌ_´î]›ƒ³Ýsœc¹©–æ'RRHØ»\PÔV>âK/è–Ú-–巸ϖ% 1™FFxÎÜâ´¾ÓŒHd@„à6ñƒô4‘¬øŠËCþÏûNæ7÷‘ÙÂ}òrsÑ@RsV ¿y¯®-ͬ‰+$唤Û?. #ç uã4vŠ‰'U−+ÝNh¹3*‰³ €dQëßò h¤<´QEQEQEQEQEQEQEQEQEQEQEQE”RÑ@Q@Q@Q@eEq8·‡Ì(ï–T ˜Ë` r@êGz–¡»€ÜÛ˜Ã;•eÜ2¬‘‘‘Ç-Gk3‹…¶šÖâI*³ìÁ]ã#åcýõª–ÊÜiÓÝ^ÂÖ−lDw )åõøÚFwf™§h¶–Ìͦ› 8’3 -ˆ…XîQ¹†N~æ:wëë™âO Ýê·u§ê_fiv™¡™KÆî (aƒ•;A‹Ð䛇+v‘•Nt¯yõKq¥ÜßÂâ8"iJB2í…ݵG©ëTíÒÅQ•T– ¬Ämàc“¤x{û:ËPµšäH·„’öèad.N1ÔäzÒÞx^×R‰ÅýÕÍÜí"ËçÜE„WU ^YHýPõÎr-wb©ór®}ɉ´¦‘•n•cóÒ¯®®§¾·Ÿh,Dw*°–1åʳmLœŸ¸:s™¡Òw0K.£}r–ò4ÐÅ;#*JÊÊω"Gà¶Ñ»€P .¬‘Ûê7^ ²% ŒÇÀe°'hÈä’``ɼA§@Ó‰d‘DNSw”Ä9¬M³æÛ#ªœgŠmÆ‘$¶ZšJ‚Ù7®àsìyŸ^rÃݱÀ§‡-Zå¦3Ý0óŒÑFJm„µÂ\8\.Hi#Bw€R¹ ¶¬ü¨¦ÅÇ–ìQ›È|DÁö!ÇÈw‚¼÷©-µ¯ZT¶YY“pW’6Hä •;_qœc¥fÞxKN¾hŒÏp|©Þá3嶦3C· q•Á KUË]" −Bòþwë%ƒ„UÎsÉE ݆\³äÍÚ_ÙErˆé¼Ñ¾7FêJºwV §Ü±UtëCca

Client Side 440 How to Develop a J2EE−Compliant Web Service (endpoint + client)

'™«TQEQEV¶”‚L)èRO浓[×úÄÿrOæ´€óŸø4Ü™%DÜ-ÔWŠ\Z^ø~åÌÖùç¾µö−Ŭw”‘Aõ䟵Q§†zÊYj[G4àäþß•fÛϤÃ;Ël/Ágˆ§*¬rNÕaµIÉçOjâü]¯\Í+ÛD‘idòpï`3Ý×*äZ.Ÿ½ôÙƱ_ÈòÝ Lî±oråך®¥¬Úx L¶Òß^¼‹O·Öï¡’äC¿…‰ÌŒ9>i−€yÚA›HÖ†/Œ4ÿøj[;i`}etØeç|\ð§æËOFÀúN›¡iºxîÛKœÜéß𑹘ɕßkœ° çrz×O'„¡o}ªOk;ÈÛ-)dt0G—ó ÇxõÈÀ ‘¬øcJ³ö²Ão6tÚý[™f‰þgPCÁzç5ꯡéÏt.Æ”Z›−̹ýÁ ˜ðx+ÀàÕ−ÁðÝÄ—:>kgq$~[IüÅsœd™þÒ€¥øwO¾{[•àÔn– ?Nˆ»·˜±`’XîÜÁN2¼Ç=µ·‚¿×Ú´„T“»1«9E®Us-Õ|Ec¤Ý^[Ü 7ÛZ−Þæv@‰Ï.Yp}ÃêV×tèüß6çËòbi¤fFØ¡S{ øÚX/%A−qŠ-¬xjÓXÔdºšW¢Hp½6£HËÿº·ý³£6b¹ðÄwPÝB×’,3Å*„G#É’Ír6ôëùVfÄ÷~ÜÆïùlŒ8åX0È`LòkºdK;Iu± `®Í€IqÊHùÆò•È€qUï¼ØúÓrÈû]vóëœû_-gØ]½Õµ×úÙ •e Ÿ¼AÉüùw²ÙÚ]ÀiN£¤öÜÉaþ³^Í”‰q!G†äÛ€@(`sqxÈ\} ¨4g–ÿÆÓ]’QŠH(¢Ò(Z)3K@”´QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQE%−”PÑIEq´QGùÎqŠŠß9pBÛÈü”c€UHÎqéŸÂÅ¿ú¶ÿ®’wÏñŸóÝ+#PÒZçT¶¸mÇË»óâ ¨Ko–ò‡ÕšÅðõ•ý¨¼›Q³NñáB•TŒ ν?¼OÓ¥mPEPEPEPEPEP[×úÄÿrOæµ[×úÄÿrOæ´€Û¤a¸G–Š`yï| ºŒo,ióuí^®øBóL¹im¯9)þõ㢸ÃG½r$ð¼Œ$k¸ú i´î„⤬ϕâ¿{wdºR$ô‘ê1Ë?›pçå?"‚½ÚÏàýªj³êeØ´Ñí12¡¸ËÔtéMºøEi3Ö±q?•t,L‘ÈðգƗZ€uz³iâËøÔÚi’ܒ爡õÁ u=1Ö½n×àΔ,‘¹þ Oõ®×Eð•£ ZAû‘U,T¤ˆ†w>j»Ñ5‘»»„Å"üÑÄO={óÇz켩‹ZÎRÊ P{ʽ[ÅúäÆ3Û¸=#á ’ß™Q»´‰›/j}pOJšUìß0b0|ñ\›£Øü? —ÃöЦ¶8-J«ei…Œ.Ø cAè `Uªçz³¶)¨¤ÂšiÔ„R(áõê6Þ$½ÓâKf»[x¢ki3 •P¶fݱËçriðüAµÎK¨ô릇jH².YB3”%ÈiÜ@ÏWG>ƒ¦Üµé–ÙXÞ²4ç$d!OÃóÆœ~Ñã·0‹@Ê]$−$ï”O‰`à ã„æm3Ãúf ÁPKFyÁfÁ9eÚ£åÙ,xä¹Ï;æÛøFx¥ŠHàЬ¼»D·aok)•$ïm’EÉÏ}ß…D›½†¶7î5› Q1}‚+lùSØÖ\{áÁ=€>•*jVOp¶ææ™å’ãw etÆð€òûr3·89¥S½Ð¡¿Ö^öy$òÞÌÚ´`9}¬20Ê3ãóŸ…æ†æÒct$ŠKµ2:«H—s üÃÌ•°ü KœæÄnØßÚêi¾Òt—Ü üɸd^«‘‚3ÛªÙëÖФÈòA‘,ñ½ÔmxØ€¬¥€ÈË(ú°‡ôi´‰Q¦’Ý„Pˆc!\1¤,Àÿ.s§3^Ó¶־²Ó•cib[14YÄ‚#v18 °ñÓ‘šÒº×4«8åyõ+D¼QËûå>SJq។ç'°$p3S¶£b©tæúÔ%£¹c2â:‰~SõÅcI ^´ÛÒâÜ\I=¶íß7›{Ó‡þî AF3œäôÁl^¼…#+ÌVOÝ Ãy ‘÷Lu÷íSZ‹O‚‰ê[€Í ,èŠÊ«¸¹bxAòå°q¸qUô/ÛkwVE BÔ#KN³)W]ÊèëÃ)Àûr*=CÃÓjÕ¬ktÖ×ÐZ˜‘ÌQÈ©º−®„†Sò䃴~aÐýÞýúSÀɤÖYmÄŸºëÕ€§}s“oA‚=1rpxëJ×`‚XNíè\NUü»ô ½eu!èê3Óh8ý{Ð−£²Bû C¹Údçðò¦µ»yél¾0@#ãyáÍJu Ê˺1·ddð›F®@8Ÿ^H¦›¼ÝE.ÂDch·’s“ß©ý=9 iá€} ô Ï=8óÒ—ì—Y¼¢UzÃ3ǯñ2ziÑ\$º f ç¨ÆWk/¿$7áJoI#äPÁFz:ýüO¿ý–o—äÿûCüóòñÏ8¤¹2/Ðghç uÆ:ðsôÉ©ÿ´¤)åm’F×#øqÇ üÿ•L³JTteP: Ãi'ׂ¦na* ˆÊÆN‡°ïøt«ŸfýÀ”È ²—U9‘× §°Ú„ĺ©ÜW>ü0=;ì}¿JƒìòívÙŸ˜g¤¤É#8ÒK $PN à÷ÐCÍL/YmM¨Åˆ ÇëÐõé—h òÚ;‹¦OoN¿S@ÑEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEé´QGùÎqŠŠßq¸Ô[ÿ«oúé'|ÿÿ8íÒ‰Oï`ÿ®‡ø±ü−ùÿ“Ú€%ã¿JdNÒ!$‚C²ðèÄwúSÿÏZ‚vÉYŠ1Æ ƒ¼úÓ·NÔ™ªx–ÛNµi"¶»¼1Qಌ¤»aTÔäöàâ¬iÄZ¬sR:0\ð$íï‘”šC¢‚hî¡Y-äYbañÀþ#èhšXíàiæu$gs€¹®"óÃwðL4Ûh>ÕmökÃk1o([I'“´£¤¤\~f*7F3fmúò}]¢´ŒÏt¢i$ ά˱pG fî¿6àrÍ€³°RK/*¤©>„ü?•2y¢¶ gqbBîã8Vcø ±ú)¬+M*òY®%…„þ¬÷V°gð¦§5„Èlm|ÂÎ`E(lö³ÆÎ0 ‘â$ä± ¬Ä°Àô gëM‘–%v„TRÎ[€ rIôÅrÚ†…}su©4Q"É:\´‰B´ÊøòБó ˜#jÐ:D‹§ÞÚB±E½K›X¹6`}ÀÌŒÆâØ' €jZ][ßÀ;Qffà(I?¬+ë;I"¸¹ÑíåAr²\XHcw¸ŒG"!?#aÙ)ÈÎx\Ñá{Öµ+rÑÝ]6"ši%/æÇý!o½Ù¦ymªÇ;F:æ‘ÜÜ3b»ËöÆ3ŸÊTƒ‚\tï\=χuiVakiojM’×ê§æ¶)y$,˜ã!¨'$^ºðýë}±íŠÇ%ÏÛŒ$Îð÷)$JAãÇÐЮîŠêÌ„nPA+FGn+mUYäo+ËkŒü±Íq€@• aâdå˜i−´fâ %Ô¾Ó•#p븴ÚÙÚÜ7Ó©ÁéÍuØÍ늛Lñ,Ívìfó^Å‚2È£.mye¼Üçåø™ü5ÙC A …ʨÀ.å‰õ$I4üQEQEQEVG‹¿ä^µÿ¯£ÿ š×¬È½kÿ_GÿA4˜A u8¤Ü¤cpÇÖº?^ÜòGî‡ó-í›ûi5I/á¶K]:#,¯îÀF_…*÷ëLsrÿx~t›—ûÃó®îçÄ1Ø´kµ½·IX.ùLj–ÀÈ/¹‰àán x¦¯‰−öÊòCy(y róó}èÜ¿Þwx†4Óc½6·m–y€€pIÈ"=F6»s€J¶#»ñ4qX_]ÙÛ\ÝÇmlf¨ ?’rÿx~tn_ïλ…×ݤxFŸx÷b_)m¢ó?Õ¤‡,d À~;ÒEâkYš3 W’@â×D`EœÄ’ÀaA+p$ˆÜ¿Þ×ûÃó®öãYÚìtÀ,sB\N_>NÀª±É q¤F/Ät£¨Ëip¶þl‹¸2(XÔðìddÁ+ƒ°eÇå..mm§ŠÕZ6yQ)Àbá1¶'`Y”àr é-ÄúŒV+Ï™$aÎå åägIÛ’ÜŠàK(,1õ¤óûëùרx\“âÍk“þªå\Õ·Æ®|²º4_Ú‰'˧}¹~h|¦›ÍÝŒ²98ÆILP)æ'÷×ó£ÌOï¯ç^ª|£Å®Zhó›…¹ŸÉG•b−"Ê»£‰Ÿ³0è?•R‹â†‹sq%´PjI K¯.Y-JÅ$–û‹ÆdÚ…½0qß−y¿˜Ÿß_Î1?¾¿wÚoÅm>ææ÷í¶7––6zuµóß2óSp_\œ¨QÕá9¾~%諤Å|Öú ‘ïƒXý”ý¦9ö3ª4yÏÌŒde‡Npæa”Œ†}hÜ¿ÞzWˆB;Æ°n…è¹àÛyçí8h tPrùyì~Lc¾:ääÐ-@hZ,ÿÚiÖâúåŠ+[Y¸¸cÉjîcÓ9öÏj¹§j¶º-»Onî

Client Side 441 How to Develop a J2EE−Compliant Web Service (endpoint + client)

6Ébš3‘>ÚèØ*yÓ=O’kÞ*Õ/uYãÊÓ¥·‚M€~òIÎ6 ä@Áêx=ÞŸáûïì}Jy–8/îííͬ>i[¼ º‘¶Ò 0Xà©Ú#®“§Èµß‘•:¾Ñ³¬,y¯_ðüè$y5ÇË£ëG−˜ât–ùć!nBÌcRc"I¢ €!9?*†…í5F·†Mš£„k–dY# ai¥(e y9ìG—œæjvÌêƒ,ÁFq–8¥9kRÚ}>{ÛF½¶ Rh!)ó›Ë*û:Ê2:oô$Šâøõ{5X®â~Îí$QÇ–óÕÎv³mÛ‚ÀŸîôÐô¯ò£¥[·â/í ÿPXÛ¬Æé5Ý·¦_7íˆòcHÈÛŒr#SDf•ogöXï×ËÿFÆfBGT¯ç°gêqŠËÿ…ϪÐ"Ïþþµð¹õOúYÿßÖ£êU»~#þСßð65K 'W3}¦ò2²Â°²‰—¿ùÿœÔšNv%Uù-3>¨Éë;þ>©ÿ@‹?ûúÔÂçÕ?ègÿZ©Víø‡ö…ÿ³–›]@qt—9ó—;–5@>˜\úäÖtš=-´ %¶¤.."XTË {Dr ¸fÏ$·ÞîFsKoñSÄ—qy¶ÞóãÎ7Ä’ºçÓ ¬ßuDfWÒ−U”àƒ#‚öíIa*½—â7¢µoð,Yé‘´B{Q!¼2LÅ‹Ã+‘•Šœ‚ åÝé[v-cj×L—±1¸›ÎmÒ©ÁØ©Æ;aç\ßü.Kþ6÷õ¨ÿ…Ñ©ÿÐÒZ²*ºäŒƒÔàðA¡4Û4¸[Ÿí . Í,²!‰ »‘c#|¿*/#œóœÖgü.Oþ6÷õ©GÆmU+¤Z£,Dp2Oãó£êuWOÄ>¿Aõü ‘h¶08–=l,ËäÜy ˆ¹_”ß “ÏJ·„FÉU VW#ù™\¸;±‘Î3ƒÈ—/Æ−fÞSú%¼R e$wR228#ЃøÔðº5?úÙÿßÖ£êu»~!ý¡C¿à_¶Ñ¬mmíÕ5-ÓÛCLÍ(°‰Ur1ƒòÌàçØõ«¤·V³M«,‹oµ‚3Åó2ômÀduä=«þ>§ÿ@‹OûúßáGü.}Sþ÷õ¨ú•n߈hPïø…dñF±"2²4Pá”äpj+…ºE¶œ–k{~Ut©t¼—\rør¸ÆõÈÇF5ÉÿÂæÔÏ]"Ïþþµð¹µOúYÿßÖÿ >¥_·âÚ~ÿÜIðÿN—]‡S7º‚Æ’A hT,R2õÈx±r)’|©ÿ@‹?ûúÔ}J·oÄ?´(wü FÓ4Ö[Ø[Rìwbpðˆß/óãqåØŒ8ô+®ÐÎ|Aþ›}·É?+íÊìÆÐ>E>½}kþ>©ÿ@‹?ûúÔÂæÕ?ègÿZ©Víø‡ö…ÿ-™¢ÂöÅ."Ûod,”ÔåÚ¤ÿ´qŸöÏ Â[XYÁ¡¾®’,2FñŒÄ€lÎÚsIô¬¯ø\ú§ý,ÿïëQÿ ›Sÿ M§ýýj>§[·âÚ;þ½”v±kÚ–¢óÁŸj"µÂœfÆx$xœ†=ë—¾V}Fé‘Y”Ìän5µqñWÄvh$ºðзŒ¶ÐÓ,¨ Áã$uàñíUásêô ³ÿ¿-Ia*½—â7¢·‘åIÿ©ÿ@‹?ûúÔÂçÕ?ègÿZ©Víø‡ö…ÿåIÿ¥[·âÚ;þ?•'üó“þø4yRÏ9?ïƒ[ð¹õOúYÿßÖ£þ>©ÿ@‹?ûúÔ}J·oÄ?´(wü *Oùç'ýðhò¤ÿr߶?ásjŸô³ÿ¿-Gü.}Sþ÷õ¨ú•n߈hPïøþTŸóÎOûàÑåIÿ3j¤€4‹BIÀG$ŸËÞ©Öíø‡ö…×ð1ü©çœŸ÷Á£Ê“þyÉÿ|ÞŸâÖ¿k(†ãÃñÃ)Rá%)*3“‚3>Æ ?Õ1“ý•gyZ’ÂU{/Ä_¢·“åIÿ©ŸùYÿßÖ§õ:Ý¿hPïøþTŸóÎOûàÑåIÿ¥[·âÚ;þ?•'üó“þø4ÜpG>•Øx_â~¡¯øšËJ›N·Š;’àº;»cfã?îãñ¬¯ÿÈÛ¨ÿ¾¿úÖ)Ê›å‘ÑF´*Çš•Qþsœb ÔŠßq¸Ô[ÿ«oúé'|ÿÿ8íÒ‰Oï`ÿ®‡ø±ü−ùÿ“Ú€%¨-ð"lcýlÞÕ¦þ]‹1r€IæS æ.îG c#5áë«ÙoLm¼ñöÝAª=”/–NGËòã#Ÿ—ªèþÓnƵªiÖQ\—ùfxw3¾1Âw7^€œûÖµ†¥gªÛ‹‹…=ÛIPC+u”ò-êÚ¼÷T‹Jðïƒ|=¬¥¬08‚zK;hâ¸K' Â@»‰%³Éê:÷¶÷òé~5…-äyMŠÛEåHfûC‹Vùú+r†%F~@3Š˜TEtö‹•´;Ò¥z©…%qóXjÔE¥´lZ «¥Ø5´Oö¨”ùƒæ+»pN−[ÜêâûHûIºu‘ÍÆáW÷¹ŒX?Í´PšŠåtûÍaº·âßí2Ã*‡Dº$2‘AôÅSÍh−Óû…ý—[ºS´àœX< à‹‹)ï¯c†ÞwÚ$’qÜ®¡‡'#AèE7Š¡m[ûa뮈ÁµºðÈÖµ;xîÏNO¿5FÏQÑSOÓ¬„Zp·– ÿ´4Ñ©™>i ÌrAû¸îkª‹Á>™−È–î6¸›ìñEðM¥Ìò›Ï2}» Ë#(Üp›™AT xRÄn< +«ûV‡g÷ŸÙ•»¯ëäxÖ{ׯÂà—%¾"ÃK™2v,m̹o”lÝ“ÇZUðo€škh„·›®q³÷’a bŠ$;q. ûI`TÀŠÚ”{?¸?²ëwGqGëËàÿ=½Äé%ûGMÛL¤¸s„hÀ\ȬxVL†çÓÇ‚| ö‹xûE$¸UeY#×ôÝV−f.pŸn‰§F½iÕº°ba v«µy#¡ìSSºðÂë:,Ö‹§MÚïJ¡V¸U‘V!·©òÙá2GX>xM²BÜà¿ñôNçåø]áWf —,AÁèŸóßõ®E‹Ã−›û·‡Ä;Ý#I´(üM~mï´™'x−ͼ÷°¡¶CŸß!ضã î2}—ÿÍÅü2Gwaieo¬¼Þ]âïnUÉ]Á¸'åêq]t¿¼ „H÷ÎÇûI °Vb3ŒtV-_²8E−!ÃÖ·0ص—“¾õÒ Òy›ä؇;FP9 œä` úeÆý»wý§q¤5鵄Eqf«¶ñþ°eÕ£ÜFÞBàà´ñ]m×ïXǾå®"O28²nO îN2ÄƧ |,Gܺíÿ/G-7ŒÃ5»û„°¸„ïdxÖ¬m?µï>¨–kyJŒYBç±BH |´m¹ õÇCéZ|4ð„ëBg‘dA"»ÜFê¯Jo5 º?¸?²ëwGˆñGíÿð¬¼%å‰?Ò6ßkã>™§Ÿ…Þ\îK¡nþ\ÒþÖÃùýÁý—[ÈðÞ(À¯qÿ…_áMÅB\ä Ÿô£Àçüäj/øWûL6ù¹2MK$†U*¬AéÁuÚÔ;?¸?²ëy'ÅW¸¯Âÿ 7Ý[“Dðz~u|;ðbIå³ÎÉ3’nÑ−»¦9õ£ûZ‡g÷ö]o#Åx£Šõ¤ð·Ã×Id7‘Ç/8y^TYbA–x‹((;£Ü0AÏÌ3¬~xLH¹ÚÍ´µNqïÁâ©æ´éýÁý—[Èðþ(â½Çþ…7²í¹Ü£,>Ôr>µ øsàÑq¹k6ti"èê¥Tzut/íjŸÜÙu¼¾óÅ8ÅhhWBÇ^Ó®¼Øãòn÷Ê Eõ s¥{ø_áVvEK¢ËÀ]F}})·? ü%io%Äâî8£]ÌÆá°D³\±e¡oZµ—5ìDKz׶ñ;mòó$‹Æâ§p%Bn$+’Inª8ÍjKáAË"ëAL‚">Ít]• ®¾^ä,Yv†v~\Õ¿øAü‚¿ñ03 qrm”Íåð3åmß‘‘•ÆFF@È®ooA.¿q×ì1 쌋{ŸK©k−©ÜisÜIvÎ]õŠ[b¿*«ÏÌíÛ6¾OSŠóVÆã·îç¥zöŸàÏj’*[ OsnØ'IàÝ·†Û½8)“xKÀí‰%½!K‰] ®°„všVU"% 79Uù‚B’6¥¡M´®þF5pUê%{_#Èÿ:8¯pŸá—„- ’{´C J^I$»*¨ d’O@ÎjŒÞð4];_§ÎÀ+¶Þ%K(SÃS÷±[,ÖƒÙ?¸Ãû.·‘ã¼Q^¹7„| –.š¹™×r†áÑ—åˉ(7®[8"¥ø 4ífäXneóŒïŒ© ñŒÿ íÚíJ=˜eÖîáÁÿ‹…¤vù¦ÿÑ2WIãùu÷×ÿ@ZêdÖàîµ%¾MŒ¬“ ÇñµcÍ·éþ°ã ÿq¨_OJd ÁIÈ‘ÈÈÿlâŸU¢iG°ó$#æÛ“¼ñÓõÿÉ›JðæƒmíÛ½½½²ùh×WóÈRûþ¸ý -xŸÁwºÝÞ£qo=¼j¶–ìn„/…?vD\uÀf# O†üêwßõÁô*é®ç¼‡Æ6Ñ ¦6òé·R−¸Q€èöà1=IýãLIÆ«i« ÷~½º¹¾ ,LS Çš]¼Ë−ÂJƒoB‹ó6AþÅ^»ðÄ·ºÒÁsj1Ü"®BǸIojœ c8çÕ? ês\Z¿™«“ZA4“HÂFY9 ª„ð¬¥U¶@¼æ¨O¨Ýý†çÉÕ£û -üƒsê,²MÀŒ¨“K’Ì[`ás… åï7¸É?á

Client Side 442 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ÕÓI¹±777Kq,¢M¬U·í2DÀí,årU@Êg#WÃ:Æ—©Ë%ËXmã2GÊ$tC>Ìó†dW−Ý™³Èª¾'Ô® µ¶¹[Ø’Ò¥¹’Ù.šÞæR¨…aR ÞØg8ùrÆ>Àî›AÔî®Kä/pÇs•ÜÀ Ñ|Ö}¬Ì2yë€þbŠ™TrÜ,pÚ_ƒn-çÒ^î?˲–$Q38—Ê‚tóP~ñšd$à'ÞnEáPµÊÖ©n’iöÖä«Æò¼b}Óe¹ól±Ø®O}EW¶•‚ÇÔG6:öwÿÎj·µ mç‚MW 4E¿%Š2DÐÛ°ÂÆFäêäs]í½´¶SÎõCb—O’gûNäl¬äú’ãg^Ñïõ}FÝ#Š[[ZV>\ßéòØíÈ ulÚ»8=eý¼¯på8{])J,E˜Ú−ŒÄ[ÿ¦²ö‘Ç,ºl²y7ù®Äosl'€ 4æEŒ±Ûöãmöo4œghˆmÇO˜¹×uE ´–Ácö7v>zÝ[˜K‘·þùµ/÷×ÿ@ZöûÕãþ1ÿ‘»Rÿ}ô®ºrM²YÙQþsœbŠ+q[ÿ«oúé'|ÿÿ8íÒ‰Oï`ÿ®‡ø±ü−ùÿ“Úˆ2#lçýcõþ#K.|È:ÿ¬9ÀÝj“üç8ÅEú¶ÿ®ß?ÆÎ;t©jŒ‹”òdb]ˆ ÎXã¿¡ÿh+´oss~`…rÌò´JŠ=Ë/AÂ¥³6ÿaƒì’¤Öâ%:8ue`‚89äuÎkŒ–âãÅHš°iâ·ÿQh F1I$a’_œ…vPW!¶¨ÜØÝ…−.Ý¿ˆãÛ™ãÿV3÷:|Õ•:´§uª*PœwZ®IÈ'Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¢ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¢ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¦ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¢ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¢ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=âÿ¾Å¬.IEGöˆç¼_÷Ø£íÿÏx¿ï±G+ ’QQý¢ùïýö(ûD?óÞ/ûìQÊÂä”Th‡þ{Åÿ}Š>Ñü÷‹þûr°¹%Ú!ÿñßb´Cÿ=¢ÿ¾Å¬.L¿z¼Æ?ò7j_ï¯þ€µë‘͸ *zÀבøÇþFíKýõÿлpÊÑ%•QþsœbºEocë$è1ümDØómóõ‡?qúŸZ−ÿÕ·ýt“¾ŒÿœvéY×Ý5û¤ixÈ“SmƒbX±øϨã=¨[¯JRppG¥ajr½ïƒ/BRk-Iv•ˆÜJ‚Š»@−óŒb„u[Øœ–$ýj3m8¸( ʆ0ç¨RA z@Ï®¥sñkšŠÜ*ÜÅdPKn",dˆÈ$ñ³'~s¶ÿÈRûþ¸¯þ…Y"ñmÆs«ÛÇm “Cnf³ß¬UCIæ`ðe#ykOá¯ü…/¿ëŠÿèU−õ¦w©MitÉw42Jñ³Æ−¾S1çµöþ9î¼F–ÒÜæÊg?8BU×t¦)V)üÌ1“Π⛨ë³ÚxzãQÖ1qos¼Èù\™‘ =˜q×_ z÷Ú®×nÖËKç4‘¨‡.¨ø ®Syu9BÙm¦œ×º1²ghç)%Ú»B−'2™ÁÝmßü!þî1ÏC@bñg™¡8‚/³CsäBd”DH†−’yÜ®QéÓ’4t-zßW»[xa‘iyã÷jB4yìw¤¸'ƒƒP]ÙhVvÁ5£”ªG Í+±‘‚¨ mÙÙ*Hl†æÆœ4øu;ˆí%4"DklTˆmÛ‘‡*N J“†Æ1@Úvµ¨_ií4³X[ak¨‰šÝÙ!ŠQ!(È.Ëå}àW;‰Ú1ƒ»a,×u¬÷0ˆn$…XÎÆ “ìx¬²øi¬Ò™V ç1 KÉP†ƒsyjC‰Ö!¸È`kúU¥ƒHe¼[ .d´¹wXðq#nBÅ0„y‡‚Aç9 ŠLTvó¥Ì *,Ê-‘‰¡xœ`ã•ptî=êZȺÕå³ÖM«Z™−vÌÒ©£K+Ä23“È^ù‰=Ïÿ„’ù´ Û¥±‰o ²’î!#þíÕK esŒäêOsév77©y5º½ÂU“q+PFp@c»Œ…=UHM‚ ˆb´UŠáS{U³¸ Ÿ”I;q’IvB.p¤e¹Ç|_–ÒÞy`’XQÞß÷r??ŸµBt»3sÃFï,`^g`p8vf‡-cXøŠî]ööx!”ÛZ‹¢·ƒƒ¾Ü9bÃ( H>VÝ•û§3¾¯i¦êòΖÓͧýäJÑ#~å%_³¯½Î3ÇmD{ xš(àÌMÃ$’4ŠË´¨BœÆ#?"ç K‘c¼ã—wšË[€É8c ÿí]F)£·‘m%1êBÊyÑY5pU 6ÏXýß|ZëœÚ…²ÍkiœúŒö`+3H«Lsœà’Ñz ?0Õ‹M´Š$cf /œI^G/ٙؖcŒ˜å°µCXT§{„äü²8pÌ=Ϙÿ`Kn÷’ݤ ƒ#²). 2 GŒ’*ÛkW2ØØjé[Op¶ï‘;–c/–Åd*/•˜ùQÁa›ßغ~g"܃1ÉįòÛó?º;À|¦ß˜ê t{`/» KI4Œšþ ꃮ¼¯ ˜_÷;çüÿ?ï1œñ³ÓÞ…ñçŸf²¥ºÇ$ñ[¶ vóÝ®šÝÊØŒ TrÆ|Å\‚CìM8,Ê−Ø H')†Ü{…–X¬qB’˜Ãd°21G’rFÍ»q£‚FsŸz¢ÚìMâøôXÝãû3ÊïæÛþBª£?ÜbÇد¾njšŒZV%äª £"` ³º¢äöa“Øg-K−´× p𯜨ñ¬‹•eV6Æ>èär1Æ(šÆ ˆÚ9D®-Î ïÁÈ`ËÏÊÀ¨*ÃHÊ‘@ÂøšvûÑCVó:†W_»š—NÖ5 A.†!‚M†X7ÚÈpŠåXà>eÆ=#ÉílŒ‘“ôçßùS±4ý›DÔ_29]$K°!à ™$%ÜÛÛ$äÕ¸−¡µEÂFªª¨ Ú Aøuï@Ö¾#7OeiÒù·”‚UÇ—,rÈÄãBù^qÆ3œTÚn¼š„sJÖ’Á ZC|ŒÌ-æC/˜T€9œƒÐã“j×FÓìÚ’6iŠ¬€I!B»€ƒå]Çš«¥xvÛKiÜHó¹ßœc¶N™ðþ˜aX¼˜IâöÈù† ZçG´ÿEUVX-ßxŒ±evÃŒ¶ìå˜å›«óŠ‹þÝ/fßÀ x iºÂjÎÏmo/ÙBFÆf*g9B•Î~ä©ÈÏ 1“›?ˆ§¶¶¼iVÔIdŒ²’ØYe2yp„ä•RÄn,HBÁsðš]”Sb·XXÆ#ýÉ1¨PU ) ÈátPd؇³ql»ìÙšÜr¬ßx“Ÿ˜“óÙË|Ç s§ÅSI%Ž¼ÐK,ƒK¸¼A+Æã18Ú¡£ {+F/í%Ón,d[Å@'†':K䉊8eÁÚb\œb¯Þh:}í³A$ ‹çÀ‰%Y¤RA 褂>˜¤›@Ó¦µks Á\of26w‰2Åó¼ïÙÏzͳ׵ /ü‰ ŠEgTQä=¾×ty#™Ÿp*™$ª2†RTUaºñüŸz#µÍc−Ô«å Š,u«›‹ï±K§‘pg• $‹ˆãÊ Ä“†æUÜ㧑¤jz•ÄÖ+zöR ¡p߸¶xŠyn}éÎ{UiµýA²bÚ¡iÁgµšU.âhðîþĤÈà©ÜÄ F·K³{5µò™"F.†)^7F$’UÔ†Rw0à„Šdº6Ÿ7–Û‘ˆ|¸äxÑãÄr"²''åpËó7ùÈõ‹åÒt›ËÖPþDEÕíÝIçnX¨Éàg'Y–ZÍÞ¬¶ðØÉf')+K+DïòäòÈUÜyÎæÇOš¯:âK”’ïQ’æ$“ÍŒ(£p9S¹@Öê;ˆî−‘…Ì−ÇYãa‚¥†>µÀ_k'Q¼ÓÇ4òõ6»yd}·¶ÑM/–‰œh _j䌀Ïʦ€:š+”]VþãWo³Ë|m¤¾Û_²ùeÛ'ýní…ÈǶFAÞÒn¥»ÓÃÎCM²ÛÈÀ`3G#F[²S?]¢Š(¢Š(¬È½kÿ_GÿA5¯Y.ÿ‘z×þ¾þ‚i|4ÿ-÷ýpúZº°iu¸®Ð¢¢[\@ÿÞ−#BTôäwô÷ÅO†¿ò¾ÿ®+ÿ¡Su+¥OÛAo¨8»9wµ2®Õˆ+vfÀOá€Ý#K¾±@Ó−™•`‚Ý ÈÎD¢NPrÅ€+Æ~cÒªMáû«˜.%–ÒÁîå¸y£W¼•…¹hÕ7,…2Ì d^

Client Side 443 How to Develop a J2EE−Compliant Web Service (endpoint + client)

3JÇRyÒÂ)õiEÃ[›«´mòÝíçw_3ø>xãùr1œq»®•¨ßÜj:L×÷*Ïsmýš9Ê:1¶2¼’C€9bÃ=I¿«è“ßÁ• ¡¼H¤†;É'tx‹ªp¤Úº¿8ç2iÚ=Å–¹sw˜Å¼p䬮Í/›(‘C!P'Ì Îæl)$º(·ð…Ô:¢]í™æyöXfU•Ê@ÏQê3ºLôÚMP}X²f†#wbm`O¶Ír¡Ê:ïß"îE;×ä.GÞ5ÒÑ@ Ä3– Ȥ¢Š(¢Š(¢Š,EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPÍ+þB}[ÿA5ÀøÇþFíKýõÿлí+þB}[ÿA5ÀøÇþFíKýõÿЀ;*?ÎsŒQEEoþ-¿ë¤óügüã·J%?½ƒþºâÇð·çþOj ȳŸõÔcø,¹ó ëþ°çu¨OÓß8¨íŸI¾ŒÿœvéRUxæHу–;Ÿ¸zo>ƒÿ¯@õÿƒ¥¾TUÔ!@±„ek2ÂL(Efă¡FAPp2;}?H‰1º’+™f‘elCµ)Ü¥CI‡û*ÃÊ−¸§ÙcÚNgÆpïÏûGÔÖ ÏŠ®aÖ.4ÁFEÔí−ÑÈ8ÊÀ6yûÿ,˜ãB*ô~#iTm²]ÓùFÐÎdƾaÙò@Ü(U´ÛšyÞÆÕ¦BM!…wH¾Œqóœ'Ó¬n]^{YYeóÕ¤…X‰8ùÁ#ïp>n¼ ÉÓüC$ð´Z•”=²°Ü¹éíLþÿš|‘Ú̬÷º·È‚¾y¶«†ýÑòŸ ¤ …E©?æÕÿfGµÛ퉵í)÷犗õ “”GÌ=¾nk’·ðüíi} Ä7ÑYˆí"&(ÌÒ´RHY_zÊH1–`qœqb]PïJ−hñÊÉj²2Û„¤s36Ù‡”Å,02@ ÜÌï¸/ödE¶‹è÷`œmÀ8Qó}9æ–M%"ÉxªRË€?ZämtmNÍ:ci PêÑFmUÔµÊìNà|å:°PA*çä Ø[NY5F–Òîâé¬Z3ö¨Ä‘ ̹FŒ8*@hùFÑ€ 9·)0èÒ‘¶âñàJáAÈqÍ8hÙÑÿõë–Õ”D á;ƒ×[£¤‘i–éÔ3鳟çY=òXhvظ÷Ïb²²þÆÿ§Ÿü‡ÿצÿd®k‚2Σ¯Öv€5˜nä“[7ò]y Ç´Áé:›§‘mdé ÿon$'n ’î”°æHÁ+ÿP~Ò2× Óš9§üñÔòóïþ¯ÿ¯Iý3µ úy|ÿ?zǺµÖ “\ŠÚmJ[Ÿ+²¼¢1ùqõ~óÌóÏÊÁ…˜Úv½"é —á—|B|2É−wfH̬Îv’ŸŸ$€r1G4ÿ˜³ûŸùx?÷ïÿ¯Gö8Î>Ô3ŒãËÿë×'{¿¦Y4ÂëUØÆâùÊΊ·±%¨C'Œ−'ÌùߟÞÀÂßE«Zéó]Ç Ó"Û¼)%ÄŒmÍÒpîÇp"ijd€2zQyÿ0BiqÈÌ©x¬ÊpÁS;~¼Ðú\q¨i/Qœe”üëÒìöx– i¶-+•‰ZÕlËÁå7° Øw@ ÉPŠwe‹5‹ÝìxKC†;k¯µÙYºAh¶ÑM ¸Ú¢5•\6р˸c Î7.F[”“K˜§û) ² Ä,ƒ,6Œ¨õh·DÌDdr\Ëü#*r Lº}ôZ쯧]]}šËPHí匚3l‘dmæ8Й 1bÇ4¿˜”iq„^¡ß˜Qó×óN:>~ÓÿÿúõÎÝøpéícci`e+{hmä†/–)}ò·ý3ܧ9ïÓÛtŠI ÂÀ$Mµ›Øgü•¤“VabŸØ−öþчiÎ:ãæ§.0›ÍêlÀmÛF0{ç=+½Ñä£Âì5[9#¹«è÷çÄ¿Úmaoý˜Ò6Ÿö#Ì−@P®vcÍMãþ™¶~ñÅW4¿˜ ¤Ó"”‘ò9v¨?ÈÒê5(ñ¹Â‚ z`|ÜœÖ6™¥ÿbE¦^®–È°›¤− LI'îÛjŒ°Â㌑¸qŒ‘™y¡^Ç¥ôÇ–{µã…¢óFé.'”Gæ!gp%PÒFHÚw’)I¿ˆÀhǯÚ?òÿ^˜t¤TWkÅ Ø JŒôÇ5G[×4ý_O»Ñô}gO¸Ôn·ÃvŒñ†8w![pÚ»G#Ÿmaujɯ¥ûKcRÄ_G8K[qq´Ë8†xä åÆ’nWVÚF×çóÇPj ·ÓlÞo5-£i7™7ýíѶ諸?𨿱tà“ ´@³_‡#iÏɃÏËŠ£¬x="îÄÉû;‹[›‰øF±²àwÈfÓðÁM7ÄMuŠÜY²K2Â'hØ…ä%Uzå¹SÈôyt=1M±[EØ©‹ Ümã\à8ÏP+?Nñ'ö†£o´–(.¢·{gr2ÂT¸1Á .Ø8î j±ñ´V«w:$pL!6âY’#‡‡Í!™Ø.@ÈÀm»ÀÆàW¨ªW^! Ë…X"0e-í²NénF¸'8 Z@ cøsœ0 ²,-¾ÚׂûK!C/ñ!x>ß"ß4Ë]>ÞÒY%„0,‰©#¢xé’Oãèíߌš×O–åⵊH¶BÐÏ?”ÀYh·¶‚›þöN äñËjóÅnñÍn.a†Þ§NÆàÞÝ ŠßÕ‹–¨ O ëV§ÞÓÞïO0$p‡Ì‘A4;Œ^PŸ?v°q“œ‰´o O£Þé^JZíµ†%¹¼Yf¸Ùmäì1T.U!¿„|¹ùiüKem%ÊM¨Ì‚Ø1‘ÊJ Á_kckmbm'i88¦^ø–;MMQd»–åH™]$Vi² > ¶H t¨tæÕ®;ÁÒŠà!ñTÉzKÆÚa’ä›Ím¹%$A8à©ÏJ¹i-Á}4q[_´- r»Kà… ˜Ë.ñ‘‘ÍcõWÜ|ÇgEyå—‰nõ2ÞÒc#Á ÔJ÷ATÁ.âÌ~éýÛäpJöÉv:”—öבÉ:$ñ,ª®Ä0 óך>ªû‡1ØQ\¿Úÿÿßfª¾áÌuW 7ˆ#¶ÕÆŸÑvñyíå9—äØÏ‚G à![%Fr@2Ë ü÷qÜÅ%–ï64È#YVqÎEU}Ø郞xe–(%‚ån ßØäU²FÛCd¿e÷$0¤ˆíüP×7ðÛ¤Â9®å³IÜ2.øÑÙ²sŒç©#£ê¯¸s…Eyô>*I'¹IZxÒ"À2ÈÒ1"A .X31’ÀñéRÍâAk4"ym§”Bd2˜Ù\¾Í‚6ÃîVp õ €}U÷c¼¢¼ìx®FRVɧٛýhi|¡»ûŸ1¼P+g–ÂLx¢˜´øòÞYÞ ?÷‘¾zaFpyú«îÇ¢Q^jþ5T³’wà?+àpI« â‡xÃìq÷Šsª¾áÌzç–>›(]IN¡J¯$ô'ø Y?‹f²ÐµVöÞxÒÎGŒG ǘfeøC€8mÊ} 7¥U}Øôj+‰“Zòµøôq$í;[½ÁpÇjª°P=NN?Ý5 Ÿá\°Ëv=¨ú«îÇeEyÌ^−ó®,à@Þdÿx¥\~ñãÊ÷ÁhØ‚ùv‘’@(|b±«øfGˆ F!£+½~YdŒËtæ®]kIg2$×R(xšU*]‰£L*¨;‰i$€ÏÕ_pæ;J+„(±2Åö„áå…1Ê üæ?Ÿ“ ØÃ`HÞ!¶O7uÝÒ˜ˆfËå¶,mÌ™bäÝÉ©£ê¯¸s½Å¾²©´¿iGq/–¦BèA Ä‚Ê‘°ä61ߊÍ>2µó•ïZ6™a "”¶Z'b=»ÎBqÎàGÑõWÜ9F¢¸Ë}j »Ÿ"ÞúI[bɹ7”*B°ÃýÒvº63œ2œ`Š¦þ%d†W)u¾Þ)â0ç12¡=ÙÏÜÆ(ú«î>c¿¢¼â_ÉæA!CKn'"æøA·,Ë´dTçÒ®Åâ[IDy»¹‹|bOÞ¤Š©˜üÝŒøØ®#ùŠgpãÑõWÜ\ÇuEpÍâKd·=Íê©m¡Úq±ŒsšY¼Ieo³I©8Šx£ê¯¸sÅÄÂEk™ÓæJorRPÀ8Î0[ §hù°Êq†Á'ŠmahÌ—71ÄÈåD‘ÖY"Œ#FFðKL@õéÍU}Ø郞x³NòäêS"Ä¥œÉ©·¨Ã9Ve ½T°ÜiO‰¡ÜJËtшZRJº°*â?,£aƒî`0qÏQõWÜ9òŠó«_îL.’‚r“r³²œ1ê‡!›cà.àJ¶LË'‰.A‡WKk—¡7¡œÉ“¹Ï8ƒƒÈ8ÉõWÜ9@¢¼îãÅ‚Öæö)|ݶ«!fß» Ëü’6’N@Ïj–/Ãö8®.n$‹ÌÞߺv¦79dj Ã,Û@ÈÏlŸU}Øïè®ßÄÖóµÊ‹ˆå·’txÊÈIò¥1±\

Client Side 444 How to Develop a J2EE−Compliant Web Service (endpoint + client)

1ÎÓµrFõÈäfiuÅM©ÏPG}U÷c¶¢¼êOj d·1ÙùËö˜íÙ£¿ „ÈèˆUÀÃrã=1ƒÖ¬~èêOXe7‚Ý—ùsÿïaéÐŒOª¾áÌw”WŸé¾"»¾{ušÞKqr%1‘sæqÚÙàc“ÇZ†O¸•£)]•¤ -rßlÒEˆ—þZ¹1°cï'?5U}Øôj+½ÔZÂÊâêY¦1ÁHÛ– à Œ“ÐäTW_¹™aKH'šíÕÝà3ìض?Ìx'vg©ÛGÕ_pæ;ÚZóÙ|A¨G g+C, r²½Ñ„hP6ä+ÃÌ_—Ô* ¼b!ПR1]Ve6ÂO›"qק0ýxÈ_¼£ê¯¸s”¿xWøÇþFíKýõÿл/ j³j:†$xF#^‹…åO\•ÆøÇþFíKýõÿк)SäVw;*?ÎsŒQEj"+õmÿ]$ïŸã?çºQ)ýìõÐÿ?…¿?ò{QDmœÿ¬~£ÄieË3þ°çu¨J 3Îyã5•¯ëèKq,Ì\•DN!I,ì~ê2[œ•‡cãre·]BÞ·,¡>ÈÅÚ ÏµYÔÿû`ç=òFr«ÉE½Yjjéu='ÄZ†t½&G¶’Î(TKÑeY−Ú,Œ±È,ÃŒ·[yXßÐsŒþ=ªÄE‡l dor¥Dk ‰>h=ÛÆ;œŸ˜ä)cðý”6†ÞáNØ”Kæ|êc$£tÆA$ò1íRjÏÿ¯ ›¹fÚ|º ½rÃN«I AÃ;ä2¬LXr‡Ìù0ÊËÏp}(ÑéÑjl¦WÀܦRÁÈM˜œ³ I‘i“è:}ÌRG4;üÙ%’GÎüÀÁaÉ]-´ ðÀ¥Eb\xZÂòÞâ+©¯‡D ØÓ åëÉÊ·†-¦7Ææ{‰>ÖÓ*"cvÐsƒ€Gg';TPbè6jò¶f"I„û ‘К»EdÃá½:*Êa†5A Iò±ù!Ï}Þ_É×íi«áËe€º½ó †y«½0^ÑòãIÇC[PðÖŸ±U ñ‘$Ãmò㌮q Ã#+E\M6ÔÎ ^g˜© ®ùTÎ3üã¦H€«”P}¾“½Ü“î.§ÏÆF,Ì*~`]7{n#¦1OĶékáK xËâŸbî98@çé[•‘âïù-ëèÿèð×þB·ßõÅô*f¯ákZêæYÞQ%ÄrE•ÆB´b3?Ü?P; þÿÈVûþ¸ý ¤º±'Å1^ÇØ]Bò$^‹Œàgk1ÐÓÐ−®¦™ÅÜWvFHPª00r$~H´ù,áÔnÉ}4XÚ¥¬PIµWnìã!O¶ ¶ïÃvWÚ é7;"£¨%)!wVV•#s6ö'vC$ƒ[P[èV¿ÛUŠK˜®ÄO?h‘Õ‹*(fVb€‹Ôs€NH§½°7ÖÏ—²º•Uá•ÕÔôä½jíŠÝÊ6ºÉîk^ŠÁ‡ÃÛÚ,0]É ,ŒêÑC*†MŒavŒ¸zÒ]xVÞæ9`û]Ìv²#ƒÚpÍlm·n#923í[ôPeÞ‹ëjBIåò5ûøÒ¥¶¢nädü±¨ÁãƒÇ5Z/ Ù¶ÁËòxCJ[φlíEs9Á=ù-Ê( ûË=¶È.dICÌC1y×QÜ?cÈ1€¼¼æ™wáhîlåŒÜÈÓ¾X»¡ÛÎY‰;FW,¸ã '®+ ¢€9+IÔWV[« â%u•ÅÃÄ~uËM¢1Î?x¼+dí¿6„_L²°†þxbµ*~â?›·îî tÈ-Š([\ÏtòÍ)IÖQ倿)‚Çv2Ü€r>µ ׄìïŒR^8¹™^Wy'·ŠMæM›°¬¤)ýÚ€@sêk~ŠÆ>šà½íÓ ~ѱNÜGçÌ%tù”²¨Ãdc#øKa¡Á¦è²i–óKnÒ0x‚ÄP»;BxV¥•‡[Ë·HòÜÃrî−£(Ú ?vã¹¥]Åo×Pò×û@\›ƒw寚ÃDe±÷d=s,SÛ™ SíV ;À‚0Aϧo®a¹ðôWÿf— o"4s¡ÚÞfæfv‘ػ˃Èþê³EdÝ[_jÀÚê66+`ò“Ë»iLŠà¥$F6?[Ú:l-a—b«I¶4m¥‘TŒYwg8ÀP/Óbià—Ì—0ÚËj»œ±+!Œ’IÉ−û±ÉÿÈVûþ¸¯þ…Sê—–º¥²¡·x¼Â–gß»jÀÆÓœr@¨>ÈRûþ¸¯þ…[RøcÌÕ£²O´ ‘w"¡Np ØG'¨n0@Ê©Èl€šÇ¯Â3Ô‘«É²¥¶ÈÙÙ@`²*—r»jûër^Yh²Þù:…ÅÔkÝíÃç•gHДœ²mÜ72¢’Êx»ÜÑš~Õv jš´Ÿgº/«N˜Q¾ÖÃìÄÝpNÑÿufÍÁ¦k_¦¡¤¿’_:â$±AxAx~Úé#ÿ—€ÖæfýìEcvS™ tU¶òrp pZ÷‰5ïì-æêÒHf¸¤¢ùˆ’9€ÂÜw£Äk~Š‡8·{?_Cm¡Ë(‹}äÈŒŠ±‘"5ǔ盃òÄEæÏ'iRf¾—S6Úåªêò«ÿoZÚù˜ÁXeÛti´©AûÓ‚îzä滬š*½¬VÈ,y߇õH¥>óµ6O-«š“Ø,pzWŠõ=J}*îldûdð¬Ò¤DˆY ¸–K~ýbS9äoåzUx²ïRû_Úe´yRÂÞá−ãBòyåíÎIÜÉåÀŒ6Fzv¹ªV:e®œ\ÛDÊÒc{¼#0ÀÜÄœ œƒ'ÔÕsÁ-‚ÇÞ+¸−6VÖì!„ß*I|÷u¬ÎÑ¿ÏŒ£*ƒ’0q‘š†ëÆšµ-¬·cH%’eÊJÊHm−¤Ÿ:D KHü/Íòä!;zKg±æ¡‚Ú;v”ÄW2HGWbÉ=ø})ªì+f½¯_y:„q궶[j‘•1’ÐÆ×®÷;‡ÈáÛƒŒ€pO8ŒøËZh'1ijÓ$J‘ª–2#o=@'‹…‡Zï³E/i[”vHÊc8mÃmw´f©ÕOG±ÀÇã+™4d¹:…œJnd‰®æHü°V=Ê’VF,x&{¦êÞ9»±µ¼MÖpê %KY‡Î"]9%u.ÓɶGÎÂG|ó÷ ÆWgKš‡U>ƒ±‡á÷¸7ºô77or`Ô£>Õ6ð¾Ðç¯rI$›:óɇ~ñ\gXX‰‚“³ß€Hú{V•×5ÇcÍÑ¢¿ÐLÑj7{aÕm−ÑìµÉî"),Ð,Š³†V“!ˆù(I Š¾·wâ!kGþ÷s¥¬Âë dP>q(“ÎÞ$Y"WVÁ tëÚ§¦K*A–F «z“ÓÜŠØF6‰£‹àÈ!\N¡4Ϲå @−¸ OVËd×.`uÒ−tWÓïmâ³0¼·³º›Ëx™I–8®ÍÏ´deFÁ`HnîÊæ¥ò˜YÛk!S·QÇWTù~R¥Vá ‰Ç‡% ÛÓ2³5Ñû9ýæn“çù>g#üc¾I½¹§M¤\ê‘Ü´¶GyÙFZ0ƒ−;€3qM¸×ôûygÏÔãw™Ó¶:œñ«EQEQEQEQEVG‹¿ä^µÿ¯£ÿ š×¬È½kÿ_GÿA4€oÃoù ß×ÿ¡Wk5¼ÚÄo)Gm4 #æIÒÇxò€Sí+á¸ÿ‰ÿýp_ý ·µHVçÄÖqǧJ’FxYB²dŒÞò}°Yøz −Yï’y~üÇ UۙĒœã', òx Ø(®wRVµÇc™ƒÁ|¾K‹¡(–I¸`0ò ˆ d·”÷fQáHßOÕ−n/îÇ'9ã=+¡¢‡RO¨ì‚Š(¨¢Š(¢Š(¢Š(¢Š(sIERæ’Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š)sIEQEQEQEQEQE9~ð¯ñüÚ—ûëÿ −{ýá^?ãùµ/÷×ÿ@ZïÃ|#²ª÷±I5¶Ø€.$À−Œíun½ºUŠ+ F£M§¹F’/7/½î‹°if`g¦9ÉÎIç½qÞ Ó_…ªhÖöÂòí£‚Ý°Ð–/‘\– ÝvŒr¹ O§Q“ŒTNcó19 tÔSϾsæ£Å< µÌÒÌçvY^ᦠWî¸ÈÃc'Š=”;Æl”l”ú(öPì°zQ°zSè£Ùð®Dæ8”´Œ¨£©cPý®Ïþ~ ÿ¿‚›¨®`ŒGŸð1\ ø¶öÎy®ncYm£¸¿Bˆ-ʈߩ“å\ƒÛqìH¸Ñ‹Ù:ªö»?ùúƒþþ >×gÿ?PßÁ\猵´C−!;‰åݸÖ(VM¨^% Ø'oPqÓ#âùRîÒØèl’ÁÄ¢Ý_−%ªàˆ°pc»hì Å?«®Äªñîuk²?òõýü}²Èøúƒþþ á§ñÔòÃz\Vw?n‚×Öö§â §ø|þ!°,çKyn‹ ʹF#‘Aà):ì ´]ìuk³ÿŸ¨?ïà©Q¢•CFêêzlŠæ[_k?Ûø~K(?ˆdƒ€q¡áÁÿ!_mJ`>œTº1] #5−ƒÒƒÒŸE/eÅ\fÁéFÁéO¢eÁq›¥¥>Š=”;Æl”l”ú(öPì°zQ°zSè£ÙC°\fÁéFÁéO¢eÁq›¥¥>Š=”;Æl”l”ú(öPì°zQ°zSè£ÙC°\fÁéFÁéO¢eÁq›¥¥>Š=”;Æl”l”ú(öPì°zQ°zSè£ÙC°\fÁéFÁéO¢eÁq›¥¥>Š=”;Æl”l”ú(öPì°zQ°zSè£ÙC°\fÁéFÁéO¢eÁq›¥¥>Š=”;Æl”l”ú(öPì°zQ°zSè£ÙC°\fÁéFÁéO¢eÁq›¥¥>Š=”;

Client Side 445 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ãB€kǹ5ÀÿÂS¯ÐVãóÂS¯ÐVãó\M'¹Ý'†/£bÚøt.×R>Å'!Ô+¿Ü°,š«4°K$^w· ±1³” r |ý#Ò¸øJuïú Ü~bøJuïú Ü~bØr®Çw†µ[tvÞF,€-”ƒ ¤²‘óñ‚Iæ¥þÄÕ¿³›Nòô±6soö96¶ãÆürN~µçÿð”ëßô¸üÅð”ëßô¸üÅ+°å]@}W{“ré 4æT˜ÈläÉ‘Wj¶wõ€}+OC°ºÓà¸[É¢–{‹™.Â…TnÇOoZòÏøJuïú Ü~bøJuïú Ü~bØöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöš+Å¿á)׿è+qùŠ?á)׿è+qùŠöšñ¯ÿÈÝ©¾¿úÔð”ëßô¸üÇøVmÍÌ×w\\HÒÍ!º1ü±@‘EPEPEPEPEPEPEPEPEPEPEPY.ÿ‘z×þ¾þ‚h¢MQLŠ( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( ÿÙÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82•-XÅZÌçÃÔœÛRZ¼~IfàÒáˆÍ"˜c#%éÉÿ HWÿ—Z;¶Öl¢à/Rxãü9éUï|.o"½·ûj¥´ñÎ#S^7–$±mØ`À9þ*¹s¢}¢ò{…º14·-w•ˆLÙ›PŒïÉvÇzÄê ᆅÜ;qßfV‡Ã¿Ù²ê e¦Ék³4‘Û#}Þ ¹'¶$ñÜVzxBCor“êm3Ü4¬Ìé#ã|PÇŒÉ#1ÉÏÌÇïc·:wZT¯e¨,3+\Mv·ÐïU’3"±äíÝäðpN1ŒÐN·ÙÊæHbqr1„бøi§‚o¤§A$IäÇ—SèJ°úŒR^éwÚ™»E·)¥G‡#þ>ƒm“ÔÃt÷ÿF2vœµ;þ)s Ó´ƒ ¶GFB“À;öõ©ZÓB kÿÛè•ŠU¶Œ«6ÒÁruV#·ÊFA*Œ>¸íú³Ï4ëÆó,¤ÅåH ‰C)"SÄf5X-h¾Ÿ;[é–)™−åIgμ¾W¹−·þ-Îq@ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€(ÿci_ô °ÿÀTÿ ÔÓ4=Š™t}8¨G'6±ú¯µCWa%lÛŸ−ÿô%¤6¿¨øOA·GÐôÙIV5ŒZÆ8î~ïa],‡§…%FÓC)‘òNÕó·õ;„ÕmšBLi# 霅z‚¼W#iZÁªePwpCœâº#K[œu1•[KcÒ%Ð|; åôm0úôü*˜´ð›^Çh4½0Ï!!QlÐôë·Ú¹m^òðXËy«Æ"Œgd ‚}³š¿ðóLâíëåÛ$ãÑ‘ÂGýï©þ_Z.XÞ@±.u §þ- þ€šoþGþÀjV tûýBÖ+Š¼¢ÞÓmÙHʃ%3ÎëÞ½>âQok,Ìp±¡b}Á[BãOÑ-‰ÜòÜ[†'¿!Ûô¼¬]YEÂ0vmÅó7Øß¾´ðn™'—}i¢[¹]Ûe†%;}qœ}ªä~ð챬‘èú[£€ÊËk„r+Ìî'A¨Þ−à•5FteÚäKÂf26Ìïqåùa0 ‘Ç÷©·^éâ;Aª]Ù‘¤µ†á–8‘›vÆÚF3¢nì"8éŠÝU}ŒùI»Ñü/cn×zf‘*@i%¶TgÉÉ4ï Cb·ÒXhËjà˜ÁÖÏLs^sªêš†¥¡ÛéöÓÝ]\ÙDe` I*îË+¹Á'dlƒ‘É«Kª_Á9#k… ñŸ—pÁäSu]Ýrye¥xWQ‰¥²Ó´‹„VÚͼmµ½µÿÖƒÿ@M7ÿ#ÿ Àø{nÑé—3˜G,‘ùR6rÊ#^𤕠»JÒ/™\–¬Ì¯øFt/úi¿ø øQÿÎ…ÿ@M7ÿ#ÿ Õ¢¨FWü#:ýßüü(ÿ„gBÿ Ôu „6–é¾Y “´zàOáUµÏèþ´[-cP†Î&SÌ?3œ…Q–n£ 8ë@ü#:ýßüü(ÿ„gBÿ ±èú¬ºÅËÅÊH£›cÛ~aÎ1ÍnoÎ(þ þ€šoþGþÂ3¡ÐMÿÀHÿÂ-j•¦•§Ü_ÞÌ!µ·ŒÉ,„GSÉü)lõký>ÞþÖQ%-ÄK4Rô Œ2=8õ ŸðŒè_ôÓð?ð£þ þ€šoþGþ‘ÄÏϨ¥„Zõ³ÎòyH@o−›¦˜Ø~¹Á®«=(þ þ€šoþGþÂ3¡ÐMÿÀHÿÂ'ˆ4Èuèt9.”jsBgß,ƒ@¸ù·pr¸ ÉgE%ÔG öW2’•]»ÑäB‰*ÿyðÑÈ'¯¡Ë»KËBó¢ûsE>êèÛ°00CpHÇlÖ\m!4ÙP $ð8 ™5[ã´ÝDÑÝÊ!‚HÎõ‘ÉÚ#¼}xëMW´–ôZ©—sHñ#˜˜G$‰»r+ã†ÇÈÿa½+.ïÂÿÚW-=ÛÅ …ÞØ[1FÜ ,{¾Zm#¦_®F'´Ò¯¢Õ–îYmÐy%kwuoä1‘@fpË7– åÚ€4šþÝ Ð.qk´LBð„€Àg×iRG`Ëê)ÂöÑ¥une‘fŒJ7DÏ÷Cª[°={f²n´ë¦Òu‹áÜn'h‚ãÃRÝLRw¶{Xî$’4e−椷±]H®ÀÇ•°c!·dã¥nhYjEí¶.ÿãØùËûþù9ù¸ ñ´äº·•çãšks¶h£pÏvVQÈø'eÿ¼¬ñ–©i6ÒÚ験€³É$·¢œ„ydiYAî¹\ñœg¥] Š( Š( µ4èüÔ{Ç'þ„µ—[×úÄÿqÿšÒÈ>"xEÝå`Ÿ+wkËm®®ô;¯"à0Lü-_^ê:d7ð2H¹Íx§Ç§D'ºéÏÝO©ëŸjε¾ñ¢D—ºä–Áº$_åýk‚Óì Èÿ4¤ä±õ-_í ‰á«ê©á£æ|n'2©9ïdz%´ºÝ‚ùöz¡ÔPrÐ\’=Pk§Ðõ«]zÉ¥„d;%…ú£zé^Q¥ë3Ã0ÃV¶«−¯Ä[h£m±êÈëêB–ó\~5l?ºßc§¼ãèôÔõl`SéƒâŸ\Ð#b–‘8Åq?.¡¹øaâo"x¥òàhäòØ6ÇeN:éPé¶ñ_|`ñºŠy³ØÚZ.œ’Æ0°,îœÏ@FìçŒvµðãK¿¼¼‘¯µHl¯§šl7m®$ã,Ë·wÍœ0Î+G^ð…†¿wûËwc©Û®Èu |©•7ØNeÈû¬äà ÐG−àƒTð¶©n‚=TkVöñȈ ¼ReeCÁÊù{¶3Ú¹‘»©éÞ4Õÿá*Õ−±õÓc»€ ÄpÝ×5«¨Ca ’?”‘ùŠ6êÚxsÅŸP¸ÓôÛid½ÒI±[\” Ýò»²ƒÏð“÷«»Ññë@nª„ÏßfPq ÀPUT+ç#‚:ûLšÉ´;9¬¤?a6Ѽ2HÌO•´,_æû¸Én}kš_‡ÂÜXÉâK¥ƒÎŸ%ꘙ2O–NÏ0§8ÆîœfºkÍ2+Í}−Yí`–·Ûj´jF>N ½ñ;[ŸW{|÷>4ñBé¶:í柢Ûið߉tÉZ’:df³¥_Mà½oÄÿð”j0Í¥]_Igo)–)ß嘙3·hT ¹îí¼§[iºMŠOvbÒõÔ!b˹¤c!!¾\ýëpLì;ùÉ'Èç7µ?ZêZËj‘ꥄòÄ°] Ÿ−n£åpy`v° phÎ.#¾ño…ü¨ê:¾«ÜºÃÙH`B~Sp¢R %Ä`å½jþ§®kzgˆµ½ËUŸt׺V—msrÞk[ amò…8ÎÜöœ×]ÿ ûOOZèÐßêpEg|×Ö“¤Èf·v.H Tî¼¼üÝzS¦ø{¤^lIª‚¯Ü™ì"€2í£Ôü%â«MûjûUÓõKK™—ûEüÉíå„í¼áÏâ}B{¹Æ)−Y·xeuŒ†SËI‡Ü\¶sè0o¤x*ÏLÔ.5ï/õ=FX~Î/5 RI#‹Ÿ‘6ª…$2MXÿ„FÃþ};ÃþuÏÙ, ¹‰÷/˜|—VMÇn9*3€? èqE ëK@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@eQ@Aþ-¿ë¤óügüã·JY«Âûàý6±þ”«n¿ë¨Çñš'—ç?0ãåoZ¥¨ê7·úe¥¹¸Ô%h£2JcŠ=«¸—pŒÀÇ4—óëÖn§|úf–é§FòL©©É¸…ŒHBæßå"±|Km¢x—Âú…åÔA áóÑ(vÆȲÃÓ*Ãê=ÆgWF†åÝ×·ùþ•Íø›Â÷Î-uqÑG¶±ÛÄ‚ÁY@XƧŸº\õo¼1{s¡ 5k‹kˆÖríæ7™oåÛ Âù³“þîk3S¥¸½¶´@óÊ?¾A+÷•z>óùú›rå†á• 7=¡®[Qð¬“ÜÞx,ZÕ‹˜−d$ ö3‚kyIÀ?|NðÅÄÆd–;?−§ƒn”]¤ä¸Ú>`ˆT ¶sÔ éÒTeOñç

Client Side 446 How to Develop a J2EE−Compliant Web Service (endpoint + client)

x?îz‚29§œpqô>‡Ð×3†eKÙnYm8Ó¤³¿óÕNcl¡¨´QÑVX\ƒÜWmªC•f%Ê•Nu±íZ¥ÊZÂNŸáý&Y¡Xן\…ÍyüÖ7Wº‹I#}¦èäˆã=‡Z¢|CpɇfÇ~išN¿q¥^Ϫ.Ó#®Å°ÿ"º)ÑTöGzò¬-'¡~ËS¸¶–ãNk−¼Ç3JW2C…Â…ÿr}sì)©'lûsUôíI¡Õ−ïoX²™?Ò8Îän~Gô‚º»-%€duŒ—îù¶~¨ü{ ·QR–½Ng†xˆû49ôº¾‚æ9,Wç^ì£ßý[×I;çøÏùö¬MBÖíµx$ŠI!ˆ^ù²\NŸgÛ´g© 3bz¨ š¦²4ÙíãX Âh]êX… ѯEV'Z¤$kæ|µ,@sÃÀµ©‚3ÄŒú ضø/$¬K(¤S*F7ÚÂÄ¢¹l1+–'8ÉÝ{ö‡+=†‘Ø™£Ë*å\#e‡ ØڧܖõÜ=E*²¹;X¯Êvœàã¡÷ä~uÏjº Ú±8R©e4 ÓuÕÔ´ùÜÉI2ÜÎæò™®IÈ•AýÑ,í“î|»p ±r2È£`ÈÜ‚¤Ö«Ú_Ùj æÊòÚéP€Æ –@¾™ÚN;õ¬o Øßiìê àaEe–a"´˜î@áv•z¸É«gáëØñÁK`C0’+ÖÉûJ-×7 $³U–'s@ €AÈí[±´¿ƒ_.ñÎmŒ@y>Uù HAäÚ5Ý@Mö¶„³òî>| P~R6“ƒè§ÌÈÆÕQEQEQEQEQE‘âÿùí?ëèÿè−Zõ‘âÿùí?ëèÿè−Hr8f`€£$– éÉ>ä GGÊ2÷ùþ}*KwVt‘™VXöU݃¹OLîÕ¨ob‰±™!L`Þ*–ÊxpõéÞ˜ùã>½(±c®:Z1j;,¼» ÈÿeW??ôA{ v°ÆÂBÈÊ{œc9Ç8î:ï´N(ãÈÜ2GNÕbâèMoå’Ī‡A¶2-ø•åF¸A Û$(Ï##h\{? ô Ÿç*ÑŸQV´O(wÞQ*ÈÁG'€ò;šúÜÇtª®ø©ý lM¤H¿˜•A>û”“ýMgóùÒ…fV`–öÇóÀüG-h›ø6Á·x)œ³p ½Ûýµ\K¸¸”ÚQ€V9,X`~_{œôðh-H−å1| ÔgÆq×ïTZÉ^ýo Œ\}ÛŒŸÌZÔÅö!,”/–8$’n sÓÜúÐSÅ.Ó‚}õçü+JãT ò½¾øÙ•¶È(K£c%)Æ03Ð oö„YeUhÔWhûŸ,€‘ôgº:Pu{í±‹)aù™˜·,ÍœrpØÏÁ¨ï®Rå‘•œ·$ç sè >ý0=‡p ´QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzmQ@[ñqÞIÐcøÏù÷¢_õ–ùÿ‡¶¿/¯øÑoþ-º¬“¾ŒÑ7úÛ~å¡ïàoÏüúP½j¼ö¢æk¸í!æS²Y„@8ÞY‘Ü…UQ’ÄôÞ•¡•!Šg‰Ö)så¹Rààà÷Á®â(–ÇÄZk¦§Áaö±-Ê^d(pIÏÍØî\:rGBsâ„\ÙMÀn,bšD…v¦òHº É¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(Óh¢ŠŠõm×ýcõÿ|ÒËþ¶ gýaÎ?ÝjK~"n1ûÉ;cøÏùÏ~´Mþ¶ßùh{gøòúþèZÜ‘ëþ±úÿ¾jAÚ;2UÊfX”° `O±5‘¢]ßM0ÛɱºNà³Gã¹ç£gpàзúVcw÷î−ãµSI−Ë"Ƨ?(ç§\Üà Õ³»µ¾´âÊâ‹wQ²HX2‘_óøWëÚôšÍì7ZS`ÛDÿendB]T¬¬K"ÆØ.Kà8®iMyÿw‰u”óm…̓˜q…s4Pº¼ùCÁgG÷hSŒ¶z¡r8½·;²Š\9P\¡ˆäŒ€}ä=(UTjª†%2O-qóê¶ÐøwWŠÒî´Om:ZÉgªËz¡@-ß Ù[ÞÜ\%ÌK"ª»³Ç8ìjü#F–{¨äѧµKU−H§`9jL¸Øü.ÒÃͧ—œ‘ ‹™%NÑ»Aw§E†f’d†K −*¥Àº÷_ ÇmËϧ−¼Ä¬rµÈ äuîÁ¤¿ÓbºkŸ²+Û[µÌ‰s'–rvO`=s@U=@¥Ú7gÏJëü"Ëo%Ë˧¥²H"óÚåB3mØèÃÐûc¥6ÞQÚ–±cdFq½òÉÈ þ4ÆmyÚ’Á¥XüÒ‚à Û±˜9Ï¥TÔí4‡Ò¾Ó§-¼€N±™!“xÎpËHÏ-s4W¯7„ü?ªC§IáÛûÛ©¡iÖ−>ÖIÈ@ÁI!O$ÄU«8| {§i—ê,a‡SìbâcLǪ¬À–ɽyµë¡ø>=N=1ã°]BDóÕ®1+'?0MÙ#ƒÎ;„i¾9^Ê$ÒÌv−²í¾Ö1nÙÆ$;¾Szâ€~2 Ý’‚Bïé·Wr_´Æ.+¹ „F¤¨Äe‰=O cßýQ@Q@Q@dx¿þEûOúú?ú V½dx¿þEûOúú?ú R+Â?ñ÷uÿ\×ùÖþ‘queâ(¢ ©[´P–' L_ÍÇLóߊ‹ÀV×·÷«suX”€Iö¡¼à•vS¦jRF|±ëþýiJ ¹œê°ísIÔ5+Áöy"KMаâH¶l1܈1.@o8^ÀäÓ7Ù-¢dµu‰n÷ÆÛ¶9™÷ƒ?S׸Í'ü,/šf¡ÿ~ÇÿGü,/Ð3Pÿ¿cÿ‹«ú½_åfZ£üÈdº>±−ŠÂ³F ™·©¿Ÿta‚…ÿH $”.Ö$›² °BÏìGûSÒÔÙï−HYZGÊKöD¶À]¸)ùÎnÎâsñ ÁôÍCþýþ.“þ‚?è¨ß±ÿÅÑõz¿ÊÃëT™−--.®±Y=Ü—/)¶7r*…h ŒþóÊ'!¡?ÁÈaÈéPXønâËK[A,ÊÚoÎ ®å¶0îÏü¶ÛîÝGZü,/tþÌÔ1ÿ\ÇÿGü,/Ð3Pÿ¿cÿ‹£êõ•‡Ö¨ÿ2$Ö´+-FêIí®E´ÂHfF+$NÃ0 pvHÀÏ8èMS¼ðíùÓ®,l>Ë ´¿hT9å·+ŸÝóå•GëÎsÅtš}ƒXʳ¿áax#þš‡ýûü]ð°¼ÿ@Í@ýcü]W«ü¬>µGùiöÒÝøFÚ¡¶œ±$ÃrE‚Bœ}pqèi¶Ú>«o4R¯Ù‚ù“£Éy4émÇa c@‰¥_*Š±?−ô¿ð°¼ÿ@ÍCþýþ.«ÕþVZ£üȯ‰¬Å¨ÿh1¶’}ö¬#’þi7y~~ó¸Ç„Î" Q‚“fÃD¼²—MÚm×ìâ1¯WùX}jó"µ†…«Ù®—pßbk-:ÖÖ‰n\,†(îbc¿ËÊån‡Ê~é_F-ì»±©ÚÜ¢[DˆÜ43H…vù8Ø{mrCÅWÿ……àúj÷ìñtÂÂðGýûö?øº>¯WùX}jó"åÛâ}TÂïY„îl-ì£yá"Ùl˜('jÉÀg+ÇFàƒÔ´»š´¯WùX}jó"ºxsP’ÓJµ¸V™&±‘Ÿí³Û;3)@•¶À@_%ðN’Ø´åš5’FRIX BœÇ¤™#?yzòŸð°¼ÏüK5zþìñtÂÂðGýûö?øº>¯WùX}jó!—DˆÜ\Ý+‰Ý›ÌšcÙ·Ë¥'~rBýÞx³-Åö}p DÑFà ¼qíPÿÂÂðGýOõcÿ‹¦·ü àÒo˜ G?«ÕþVZ£üÈÚñ€á−ñ ÝÏr`·KšÚ!–D–+†ud|)”r äãã›ÖþkÚݾ•,—:|71i«¦ÝÛ[\IU‰›#sÊmP00x-ßø\ÿŸmKþü¯ÿGü−ÿ ÿ϶¥ÿ~Wÿ‹£êõ•‡Ö¨ÿ2−Çá;øµGù‘œÿ µ‹ï½¶£ªFÞ$’ö+Ùîâ•öÌa#BûC…Ú3ÐáÉ`Jµ¡|;¸±»ðìÚˆ²¸]=¯¥¸åy¿y9B¥ ¨Ý÷X’@å¸ÏZŸþÿ†ÿçßRÿ¿+ÿÅÑÿ ÃxÇÙµûò¿üUW«ü¬>µGù‘_áse©ëWòÇoo;éö/4E °¬Òͼ™‚Œ ƒÒ¸xÿÕ¯ÐW ÂßðÞsö}K?õÅøªÈöøz…sú÷_þ.«ÕþVZ£üÈæ(®Ÿþo‡ßô¹ÿÀuÿâèÿ„Ûá÷ý®ðøº>¯WùX}jó#˜üEÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü

Client Side 447 How to Develop a J2EE−Compliant Web Service (endpoint + client)

·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€w?ø ¿ü]ð›ü>ÿ Ïþ¯ÿG°©ü¬>µGù‘ÌfŠéÿá6ø}ÿ@+Ÿü_þ.øM¾Ð çÿ×ÿ‹£êõ•‡Ö¨ÿ29Š+§ÿ„Ûáö?äsÿ€ëÿÅÑÿ ¿Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™Åçšî4=wÁ> ÕâÓlôIiCªÀð •Íx†Þ_ß[ÁÇ ríD^Š08g(J.ÒVf°©«ÅÝÕQRY¿ýä±ügüç¿Zÿù}ô[ÿ«nŸë$èsümDßëmùëSþÃФŠ9Ç,i"7Uu ~†«ÙZ[[î–hb“s¦äˆ)Û¼ñÀö\fŸ{,ÛnŒ€æHÓ%w`3ª;ðMehz¬—²ðÜ,[îTÇ%¹VÝÁ ç±ËdvéÚ€2o>èךÓj—W»1ó[yŠ"ÛÏÊxÎÜ™éÇJìR ®Ý¤¸èGl~¯?ÖyÈJÿþ¸¯þ…Y/ð~è™6ø%mÅ~ÊØnN?µÓB¥(_Ú;lqbáRVtÕ÷0ÛBÒ‰•i¤Þ] [Asqþ˜À¶b°ª¨Ì@/Ðd’Ý‚óm|−¡[j−iq äÞv¶Út³ìÛ6x;ˆÞqëÜÖøE|²‰WÄ`KýñnÛ½;óÓŠÂ+﯉F‚¸·o”àGÏÁÀ¥mõªNÖ©ùœŠ„ìÿwùÓxzͼڔ·uL³ÊïÞlÂ/c üYÎ}*þ¡á 'Óìîm$̳[Ùüæ0êˆì‹’ĔʂÜâµOÁûß/É>!,çËû3mÏ®7õ§7Â÷7‰7A·c‚:¿ØKë4ÿççàÃêòÿŸŠ2"ѬÃSOøFïá.-NÙ¥ß−²H„’p§åwc!€lbŸ„´Ë¹µbâ|}¾ò#q¢Å§,EŠ´‹‘߇ŒqAð‚ü;¸ñÌÿ|ý™²ßS¿šiø?{ûÐ|D1'2£·ÏÏVùùêzÑõšóóðcö3z:‘ÎË¢iØøK{¥¿z¡œÏ” ]T¨LwÜ{öâ¸úõ/øS÷§øH—îlÿfû¿Ýûý=©Ÿð¦nè;þþ.·¥¡ù§¼ç«ƒ-+rÂßqæW¨ƒ7ô‹ñ´?ü]ð¦n ã^‹ð´?ü]ký¡†Û›ó2ú†#ù#Ëè¯Pÿ…3sÓûr?ü?ü]ð¦n?è;çZþ.í 7ó~aõ GòþG—Ò~uêð¦®;k±à!ÿâèÿ…3sÿAØ¿ðÿñthaÿ›ó¨Wíù_ùÒãë^Ÿÿ fäÌv/ü?ü]àÕÁ¡ˆþS ÃV×/á…šÇB¶Ôî_VXdó¬„؈Æ2 #ä\÷È=EXƒÂÚuçöûCg;ÛC5ÊYÝCrΪQ (ÚŒtfÈÆpkf?„7ñ°ø“ËVøi7‡|Eoª>-ÂÄ®h;£ØÀÒ*|³ZµQ\çaêÛ¯úÇëþù¢_õuÿXs÷Z‹~"n1ûÉ;cøÏùÏ~´Kþ¶ßùh{gøòúþèÒ“Æc‘w!ÇÇ ä~¢¡²¶Š ƒŸëÖ€9éÈZ$92°n ÷yeJÕÓ4W±ûx»¼k߶°/ Fv¨KcpÆì’N•_Äš>³ªÍkk”óií Ï2«2,²`yi!R FrÙ©À8Öo†ZëìZµ½½ÃÇgl±%³†3,2ª~ú(ÙÉݪ=2Ãè£ME]“nÇU=µ½ÒH—ð̲Q5´ÂÖ~ÕJÛÉå.èA!r 01ÅrÚ‰ïg¶Ò’í K-$귺ΰ,H ©P»pylå™F2IâªÛüD{›¯²¦ˆLÿ3×EchþÎÓ¬€¼a°UUœâ˜‰Ó¬ S Ë™.#òWlÎH%œc Iäç¥/Ø,¾Êö¿c¶û; ‰¡òWc è¥q‚§Jæ−ür_ Lv’›Ü…oŸ#9Æ*+OÏy›ˆP‘ßdrÝ´q²,`Ûš ÀÀPz“@{[[µè½h"k°P¸( ›3»ºíÏ8Î3ÍK\¾9½³–êkë8üˆo®áHà˜RA6”çêz±ì>k^§à-rÆ{ÙYb6p4èR Pè@ûÊ$,p8%F28:z-Ñ>1—Q{œÛgÜ“X]#I|…BæÜFzç¸Q^‡ö;ùáýð(û¿üûÅÿ| \ÏùHöO¹å>%[K«Û¹4¸ÛsÚÜ¥ÎçDó hŠÀþô0VÊÇhM"ȇKšÜK/”×Í?Ù×j[Çoÿ>ñß±ÛÏ¿ïOÿ(•¾Ñåö—–Ö¶s\iÎt÷»–’Ú$tKH•[i a¥sœ1CŒìÉ*2Õ“PÔ¯ît‰uYc ŬÅƪ£ì®$läm0¸ê1p6õŸ±Ûÿϼ÷À£ìVÿóÂ/ûàP¤×ÙFWø•ÄÑ}—í0¶Äõ؃£ \³\ã+¡§¥ˆìæµ¼7;¼¸{è£ÌvëoµYdÈR´êÒ†ÆÓ¸¬a—äL1rI¯Dò¬¹où−'•cýÛÉk8®VÚþfv×cÌ¡ñ²aÒüËÙU•Dyóí,¤ ˆ€bdÉ9çÚÅÈq2JŠx Œº©+À^-åYvßòZpµµa‘ Dz…¯™-¢G±—YU¤}ˆÇ¡ÛÞk= V¼P^BG1BŒ2#Pv0Üu+èú±Üh–RÅ−ÄÊÑ/ï.J™[×~Þ7g®;æ¯ýßþxEÿ| ‘bDP¨¡Tt`V5a*ŠÉXÖœ\:Œ¢¤Ø?É£`ÿV˜s":*Mƒüš6òhú´Ã™ÑRläÑ°“GզȂ*Mƒüš6 >-0æGâm/Uºñ=ĺ|w›+[)Ý€hL“´Àc£ÚuRãn5Bvñ−¾,6qj){‘F‘°‰`.8Ùæý«ë1Ûg5éÛºf•¬‰º8ëûùü9âm2¶]¡ÅlÎ?y,m LÅH?;IŒtÆ€1−−üA Æ©yëÜÍocËuÜbiÒB»T¾Òß8Ø3‰œØô̓҃Ғ„×@º8M®ÍªYÅ©Ï,j–i{u‘½e¡Ô%½Ñ.§ŒE(¾‰,ÝÜ-p,à~ûåî7 @ȯDò×$ã“Ö—ËrNú º8{- Ü|+¼°Š;‰k‚Çø«‘FÀ2ÆíD#…UÓõ†ñìW«lò·îÝ®åTÜÞq2ã÷x¡—që¼p;_,Qå-%N}‡tpwÖz½Ï‰−î µ¸–Át¹à¶qrÑÊ¥£S¹·¦RF`«ótÙ¥…Má; ¥Ì2[Ïmób1mi−’ÝcåPƒŸ˜Ÿ™¹^ÕÛll”8M«X.&E𿆡6Ó¬ÖWçÉË,,¹çu9ÆM/‰ìõY|Cay¦, −´¶ÒÈ™áeeQÈÏFòÜTb=k°zQ劧pºï˜-‘Ó ÷®«`£`ô§(T’°hyœv6¹»]é4íû^t©‚¼+ʲâÉ−f–\ûpU]À€Ø9Ü~fí×TX£`ÿÉÜwDtT›ù4läÔ}ZcæDtT›ù4läÑõi‡2#¢¤Ø?É£`ÿVÊ/ç³°›O†Y—e£ÙIlBýâFçc’Ì3ÆÀrFOY°Q°U*I¡\´ýƒüš6òj~-1óâŒT›ù4läÒú´Ã˜b¤Ø?É£`ÿ6 V˜] QóWø§þF-Kþ»ä+Ù‚€zWŒø§þF-Kþ»ä+¦Œ#fK;j(¢¶¿ú¶éþ²N‡?ÆÔMþ¶ß‘þ°ã'ý‡¢õm×ýcõÿ|Ñ/úØ:ÿ¬9Áÿe¿Ïÿª€%¨-Î"lcýlyÞÕ−WŠh‘Y^@w8fïŸOóÒ€1eð†qs$Ík¹¤vbF¡x2O=lÃa[v¶âÚÂÞшq ) ÏpªëõÉ뺴ú”a-™×HTbòÃuåµË•Ìq–ÆŒ2w“•é•4ÿêwk¥ë =âÙ[Ç%²Or‰ Eš!䪲€$'ùÊš˜¸5x»¦š:XtË s†Îò û2b1òÅLcýœ€qÓŠ-má½ÍÃÛi6‘8à2Äû…?ôWèk9¼LÖVìnä‚gk…‚"ÖòØrQßçI·2ŒFØnA'«cÄHö—W‘ØÜ[x‘ÝÜ…`ÍJ©ä|’§¯!ìM°š«*ivk ŒDˆ}Лÿ¾>_§*3á}ÈhgåÜWÊ'nßýãéÅWÔ¼Iö!z‘Ú»=¬7r³’ ¨#bJä“*ŒØò:„°ñ“]5Ý¢År×ÒÛÀ±É¸H‹,˻تÀ䃌‘ÇP´¡g$Ä9ÊygóC·éÅ2?èñGåǦZªm‘0#‰+ƒþò¨Ô+JŠj"ÇÆŠUÀê( Š( Š( Š( ²"ÿ £ÿߤÿâkŠ`nÂcâ/ú ?ýúOþÖ¹ÿ

Client Side 448 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçüýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþÖ¹ÿ ˆ¿è(ÿ÷é?øš?á1ñýþý'ÿXtPçü„ÇÄ_ôûôŸüMaÑ@Ÿð˜ø‹þ‚ÿ~“ÿ‰£þÐQÿïÒñ5‡EnÂcâ/ú ?ýúOþˆŸË¥EEzmQ@Aþ-ºÿ¬~§ý³PQóϾsÁÔеqq¤OqwpXÁ¾i$xÌ[#ÜøÜY62°É ¡$ò)GÞ2v—+−Obå’WwG™™ÎãÉbrHòbö*6ðõ›ImΑÇ:çs»J0ì\œçº`üÆ ÅVbÆ;‹¸'·”¬ï4YÀ"*¾>è èã eXpr’ëÄv¶ëxK_0èQdd :«‘É€G=reäٴ…Ìd“"HrÇ’©åÃojKm0{v{Ó Ö−î.Mº¤- ’U.6p%’0[—q‰ñו#= Ï¿ñe½”E³¸bA"ʥƆ*ŒýEºð¥•Åáxí−d·šíí¶Æ¯æyJÜ€#ÚÝþéJƒRÂ7 Ïz÷W3Éö™ Œíã!A$™²cÒu Bh"ÛeÊÉÊM¸"–Þµ™±÷;¶®3G‚´Å´šÙ ’@bKd›x¢Ê+¹mZ9¼øïà±ÙÆXÊT+ö9`Oª*Ø×4â²2Ï#*0¶òLJín¦¹yGÞ$Ø¥¼ðý¥öñ,“…’á®T©ª@ʼ(Ã.×^v²æŸc®Ø_[¤©6Ðæ,p[‰fhc ‚ÐN.Ç_±½·²“{Ä÷PG0VŠ¦ôÞœ ¶óŒä1@Ô´¨\ù¾{Â/*Sˆ$FRA«ÔCçú%½Û+j²É«ìª/ã…•CmÎGðã8Ï'x RÊâÖK¤œ¤.ù$6ˆ*c;þp>\C”†¡}a!†ÚK›iàó-ä¸(ã@«/fÃtõâ€ÛF‚ÖÚ8Rk‰)–u’W‹„T;9 «†õÜHÁÁéÖ†ÆÅ gó$ÜòHøÆùË»c¶Y˜ã¶k2O(6iªù· 9dá!˜dHÜeºåœcÔ ÕÝ7V‹RdRD|¤™CãçGô`ÃðÍhQEQEVG‹ÿä_´ÿ¯£ÿ µkÖG‹ÿä_´ÿ¯£ÿ µ 8š(¢˜Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@›EPP«n1ûÉ;cøÏùÏz%ÿ[òÐöÏð7åõÿ−ÿÕ·Oõ’tÿ}¨›ým¿Oõ‡ÿqè_Z¯ ¼ K 6dpÛr7>ŸÏƒV*+q˜Û'Ì“§®ö z}'Äe%Kí:þêP˜E2ˆ§nŸ‚ ç;¹è8Ç®“þ– ê:eØxc¼…àÊÆåpù*¹8Æü Ü’¥Þ«> ñu†ŒÖaïaŠ9.Z)Ýɱ·c…Û¼±éÍZÓuèît“{;Å'ïW−lÁ—Ê’M±Ë’riËÆ6¾@ÛD)ò§%Ô—QM¥Ø'Ð$¹´šÞMIÕ.á˜Cn‘«Æã 67z?U±÷ˆ©!Ð#WûyŸx[™.‘JÆåÔ·ÉðÁk:[Ïv¾W”ÊŒ8ß¼Þ á$úPÔw¶ËôKþ¶?å¡íŸáoËëþ4−W†$pÌÛÏÎãýao>‡Ÿ‡OZ±QÛ©(F0LÆ1üf€Óu Ú¢y…qc…c'>¸«¶šÒ¶‡uª]¨H-ÖY_˳商 ÎäŒÉÆx-çVu"œí¡„i·R´þµº‚fšB‘ÙIjÅ8,]ïƒÈ fà‚ qŸº3ü"ÒùGn¢‰d−á/÷6nü¼ØÇãìj¯‰®"¼ð¶ŸsnŠ[ÈqŒ-ëH:Š(¦EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP¦ÑE¿ú¶éþ²NŸïµ-·éþ°ã?î=ªoúé'|ÿÿ8íÒ‰ÖÁÿ]| ~Oð j8í£ 4Š ' !–Én Ç ÜÕtªêÖ·²NTA$2ICÙ[ؽÜfÝYÙPï2‹/±ð3»~~yÏ*EÐu’k¡−ºi7ªÁò[»†KÀDá#•sö™R]À©Jëϱ/ˆáko i?–Z9‚íRB;}+z²líùJ¼IỨãÓ‚5±’v™¥pàn˜Ë€ Xa󆈱ôŸâŠ(¢Š(¢Š(¢Š(¢Š(¢Š+#Åÿò/Ú×ÑÿÐZµë#Åÿò/Ú×ÑÿÐZMQLŠ( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( M¢Š(+õmÏü´“¾ŒÿœvéX׶š„š´S[Ëw )x'”Alg¨R6`FÙýãõþ3þZ«ªjÐib’çv) ½¼{ä”’p=Iqõ MOO¿[Mt’áRÖ“EFVR|¢p¨ ªºgïãî–4·:Mõç%œ3Y−ÁfŠA¨Ë„¶O˜Ð³;ý¹çÄ1ÁÛÒõH5hdx£)!*x.#Ù$O€v°ç±‚Aãr9U°ñ•Nw{š*-G•šÎŸ{s©5þ™hÌo®u± qH.Rê4HÉöˆFO%# ¿:•M¾èÊJ‘Ï2¿SŸãoËéÚ¹‹ð~±4šÒ]DnKϦÆ1ÀoŠŸ˜†VïÁõ/f¸ýÒ]:=BdH'Ô@¶ìáb Ä0±«>7-Ï,Ñ:l^íåc †ÌlíßÈ=¹®‚ÃMÓ4ØÝ´ë+DxÛ@‘Æq¸¨ã−Éé“Óš´ò$@´¨$±ÚãþJ/}A}ö•®%ºØÂïrfšW’K’ÅÉ•ÆdP>@1Àp6Œ’%»Ñ5#ä°}§í¥,_é˜ýù›uŸñ`…ˆtnp+¬VVPêÁ”Œ‚9 ø÷úÒþ4ÎëP^\x–5´á•a‰‘Ò}‘ÄÞqË2’|—Œ@Ûƒ‘Oû3YëL[ s©™Äܬfåš@?xÌL?…‹FTªç®Ï”Áé^¾Ó´¨é—#ä'·í7;Gl#ÝŸ0 9ûÃŒpzV´Z%ôבAç‘úÐ-Â@ ùÈœã×MEaøzËP³Eûq”´–¦c$ÂBnÿyç§þ™r>Sõ¹EQEQEQEQEVG‹ÿä_´ÿ¯£ÿ µkÖG‹ÿä_´ÿ¯£ÿ µ

Client Side 449 How to Develop a J2EE−Compliant Web Service (endpoint + client)

8š(¢˜Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@›U51›È%|È·€ ù|ÅÝÓœc=*ÝG^ÔÍè+}ÖéþËöö“˜ tMjù`‚q÷q„ çœ×¨i6z~¨−´y.ÜZGöi Ф-+†?7!T“q98?!ÚúÞxêqT.t]2îóíw6M9K:ä6SÁPNe äÄšê(¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ Èñü‹öŸõôô-zÈñü‹öŸõôô¤ES¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(ÿÙÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82Ñ,é ·²ŒI†p={WI£ié¤épZ#™6/Í!êíÝÔÖg‰ I©ip‚6£KrÃ×jl¬ƒò®LDýœ%%Ðí£[,áíâ–2 b Ò6~é-ø¼+áK‚ë •¬ŒŸyRRÄ}pÕÌj—¥¶§"³%¼—qٹߴ0X Š…»+Èê‡ëõ“jc±º7º|giç³KŒÆD2`m¤0€‡‚P‘œf°¡ZNœ\·5©Ììz'ü!^ÿ \_÷ÓGÿ‡…üß(éöþf3³ÌmØúf¸ëêv:„¨ksj$feeæ€,㜒L ‚?¾=j†Ÿ;øÎ JàÀg¹o .XHLNº²¯˜«ÀòÁêÕ·µZÈÎõü+á8æXd²µY[îÆÓÇðÝV‚¼6s*/Å›ükÊîu¹®BO3NîTJ„ ¢Ò«à— rÛv ÷Ldœq“ÔÕB|×V%«ð„xoþPÿßMþ4Âá¿úCÿ}7ø×AEh#Ÿÿ„#Ãô ‡þúoñ£þ ÿÐ*ûé¿Æº (Ÿÿ„#Ãô ‡þúoñ£þ ÿÐ*ûé¿Æº (Ÿÿ„#Ãô ‡þúoñ£þ ÿÐ*ûé¿Æ·ÉÀÍT†îÞâKˆá)ZÙ*#†1¶ÚÀt8 àö"€2ÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ©ŠüÕ´¯œqŠÁÿ„#Ãô ‡þúoñ£þ ÿÐ*ûé¿Æ·ËcÞ©E¨ÚOyqg Ü][lóàYAx· ®å까õ ßøB› ·#er>*ð|Ð-áˆ$•÷Ë ÝÎÞ„û㮨µæÊ\õíšî|MáÉuß±Og}.›©ØLfµ¼1 BWk©Fáƒ)#·nzƒ^ÇÁ6±è:™¬]ͪ>«+M{q ™€Õ_¸*ãé@Ï‚öÁÀ©.¼©%ëj?ŠntËéÑ>Ý‹d– ™B™|¦áàdƒÐ-jxoá}ªæîþmGS¼e77’¨Más±U «¸àS@çÄ}N³Õ<=¢êwÑÚY]]ý®îI*ÑAó¬dxwØ3þÉë'Ã^0‹Høy«C£ÜÁ©¾‰x¶VrMgöÓÃëoâK]–ešæî(-áÌAM¼(2P7VÜä±—9x,k嘙!O.K\äü 2I–ãÀÂo x›F]A”kws]L9òL…~P7 ØÛê:йüA¤xÚ #UÖSU·¾±–åIµH FèM½P‰ IzúòÚ½â]KIðm¥¥oo.§¢nækXøÊ¡YT ê ÀáI9`Ý£ÜhþŠlµŸ!ñ/‰-¬ô½I4½>ëB¶Ô\˜ibiþæåÁ$S»#àdäZ¹ø}3Ísie¯ÞXø~öC%Ε†Éc™IÝä¨õlc8¶ŠÃćU·aK¦Å§Gj‰…DÝ>Œ1ÛÞ€*ø+UÔ5−"áu9cîÆúâÁî#ËùNSÌ+’¶2@ã==+«¬=B:ñý L.õ ‹ÜìÛ·ÍrÛzœã8ÏA[”QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEv¬mWþ>—ýÏêkgµcj¿ñô¿îS@ôÿøð‡ýÚšd /¨¨´ÿøð‡ýÚ°Ý) >~ø£`Üaz©íXß—ýÏêkgµcj¿ñô¿îS@üxCþíX5_OÿÝ«4¾"Ò†§béq_8øËÁ÷]"B$O»Ó‘é_SÁ¬MgöºœM¹â=*“¶¨M]#èMjÞMÌeXqȫϨGyóJÝW¢ø«áÕÕÚÜCcùØÌe—‚G8Ïlô¬ˆþ]ÿfÛµÊL—E“ -ééÅuC$¬Îà£)]µ¤ûÙ¬c])%m ªao®§¤|O·çG'°üëÆ?á)×è+qùð£þwþ‚·˜ÿ `{¶ˆ¾òƒu)…XÔýkÇ?á)×è+qùŠ?á)×è+qùð bû49ÿT´õWî¨ã_ð”ë¿ô¸üÇøQÿ N»ÿA[Ì…{> ì*œºe´Î£REy'ü%:ïýn?1þÂS®ÿÐVãóìq°¦ÄPHï^1ÿ N»ÿA[ÌQÿ N½ÿAKÌP´Ñ^−ÿ N½ÿA[Ì…ð”ëßô¸üÇøP´Ñ^−ÿ N½ÿA[Ì…ð”ëßô¸üÇøP´Ñ^−ÿ N½ÿA[Ì…ð”ëßô¸üÇøP´w¢¼_þ{þ‚·˜ÿ ?á)׿è+qùð hÀ¥Åx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓEx·ü%:÷ýn?1þÂS¯ÐVãóá@ÓHkÅÿá)׿è+qùð£þ{þ‚·˜ÿ ö|J0xÇü%:÷ýn?1þÂS¯ÐVãóáE€öŠ+Åÿá)׿è+qùð£þ{þ‚·˜ÿ öšÆÕãéÜþ¦¼¿þw¾«qùð-ÝR¾¾³y.ï¤yB ·P0?S@Ö·ÿ!Ëßú誆Þu„La”Dz9Bþ=*Ö·ÿ!»Ïúéý+̉cQ*—„^X Ä0ëŒ`n¯j?ÏJLQþÏò-AçŒzOµÀÒ«3µÁR |‡=¿½Ôà¤s@ä¡ Nǧ-AæF׆2Iƒ¨'ó‡ãõ „‚AŒŒ¿ç§áEhC,Q$Q„`³mÏc’8Ï$úgß´ÀQ°BAß“Á'oŸj¡‘ê?:vn지}ÏiýªÛí¼ßùf´–b²+Ïá€$cE[' FZEÚ;ðOê(ø§¼2ÆŠï¢7ÝfR}=j½£Á¼b—â´æÛ̃œ3Çåÿ¬¿°oCÏ¡8wÚaûVLŠ?v¥]ıÉ'’¹'@c¶Hm§Ó'µQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEv®¯Âßò›þ»Ÿýk”í]_…¿äïýw?ú зÿ!»Ïú謻‹ˆí£âUD.ÌÇ U’Mjkò¼ÿ®‡ù ‘l4øîtë·²ñ4“Ûl¸V´Ò^hX´|€àr0Äd`äu¤¼Á˜±\‘ášÞæÖæ0 \ÄQԇЃ Ÿæŵ¹t¶Ó²CɪIÚ*ðC,–½µ¬W V`¦Mîd S¸p½{“]—¨_¦ƒ¬*_Ý(†(DAgaåæUnËÇU;t¿S ”«²0!”à© ôÅ'¥tÖöÖ×2è°›¹º¾Všie¹e2ïÜgêx9è1Vî´Í>ÚCrÚvå[ ¦h]e„UPv±,8'ýàsÆi 㨮¶ÏM°¸ºQ§àM§Å>ØÒIR722“µ[y(èN:*͆‰húêO¥Çå%êBB¼“ì íÚ9ÉvéœH é•Ò*(ô‚öúC^³›‘4æb¦Ûc£Ðp|ÝsVõEŠêÚîF´û$GwN¼Qí]„ú=˜ºyëÀ •é»ØÖV§ŒšT×öZ´âØvmɱÌIÆr£¦(Š( Š( Š( ¹¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(í]_…¿äïýw?ú ×)Úº¿ È:oúîô =oþC—ŸõÐÿ!TÌÓ:\È®kò¼ÿ®§ù ×û‹k§ØKw É’éh‚9¥fm›ËcÓS>còó=9§5Äîiå`Ýräç§_È~BºØt] àfQ»nc¹ÝÏ\pzãšEЖXâb‚Y †ç ÄrpA…r+4ÊÁ–Y‚ì!/§ÓÚ4ªd"Y™÷ðÇçë×שüë°BÑ%•¢Œ+ʘ,‹pK/Ô‘P¦…¦>½£[$e-®Ì›öÊNå àç§Ò€9_>b¤Ä‡.7Ÿ›ëëG›'—åù³Û¸ãq¯5ßO¦øÖòâÒvd¸¶ y#ß1"I¿Õýìç¨ÈÆÔïVÿLË›»Œ×1‡›äPFÀeÈ‘‘@)æW>_ÜË“§ONƒòÝîT©v*[qõ>¿^O5Úhßð¯¼A{–šn$XŒÑ æù2T¸¾ðÞ{Û›‚’¶'q*AË>s’ÜsÔ×Sÿ KÂ_óý7þIþÂÐð—üÿMÿ€²ñ4{

Client Side 450 How to Develop a J2EE−Compliant Web Service (endpoint + client)

¿ÊþàúÍ/æ_y€©ßêïs¶Úm|Ä“ÈvÁÚ¯´†#œk?Xð¯ éi•c @÷FMÚxü”ó\²²¼ÑH»”q n;J+¨ÿ…¥á/ùþ›ÿ¤ÿ ?áixOþfÿÀY?ÂaWù_ÜY¥üËï3ü]m=Ÿ‚ôk[™Iáh£‘ä˜ÊÌË— $ƒó`g®Ják¼Ô¼uà]ZῸXÑ÷¨L¸8#ø@ìMfm|0þíÇýósþ4{ ¿Êþáýfó/¼å¨®«ûká÷n?ñ£ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¶¾vãþù¹ÿ_í¯†?ݸÿ¾nÆaWù_ÜY£üËï9Z+ªþÚøcýÛûæçüi?¶¾vãþù¹ÿ=…_åp}fó/¼å¨®«ûká÷n?ñ£ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¶¾vãþù¹ÿ_í¯†?ݸÿ¾nÆaWù_ÜY£üËï9Z+ªþÚøcýÛûæçüi?¶¾vãþù¹ÿ=…_åp}fó/¼å¨®«ûká÷n?ñ£ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¶¾vãþù¹ÿ_í¯†?ݸÿ¾nÆaWù_ÜY£üËï9Z+ªþÚøcýÛûæçüi?¶¾vãþù¹ÿ=…_åp}fó/¼å¨®§ûká‡÷n?+Ÿñ£ûká‡÷n?+Ÿñ£ØÔþVY£üËï9j+©þÚøaýÛÊçühþÚøaýÛûæçühö5?•ýÁõš?̾󖢺Ÿí¯†Ý¸ÿ¾nÆí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿOí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿOí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿOí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿOí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿOí¯†Ý¸ÿ¾nÆaWù_ÜY£üËï9j+ªþÚøcýÛûæçühþÚøcýÛûæçühö•ýÁõš?̾󕢺Ÿí¯†Ý¸ÿ¾nÆ—ûká÷n?ñ£ØUþW÷Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿ?¶¾ÿvãþù¹ÿ=…_åp}fó/¼åh®«ûká÷n?ñ¤þÚøaýÛÊçühö5?•ýÁõš?̾󖢺Ÿí¯†?ݸÿ¾nÆí¯†?ݸÿ¾nÆ—±©ü¬>³Gù—ÞrÔWSýµðÇû·÷ÍÏøÑýµðÇû·÷ÍÏøÑìj+¬Ñþe÷œµÔÿm|1þíÇýósþ4¿Û_ »qÿ|Üÿ?aWù_ÜY£üËï9Z+©þÚøaýÛûæçüi¶¾ÿvãþù¹ÿ=…_åp}fó/¼åh®«ûká÷n?ñ¤þÚøcýÛûæçühö•ýÁõš?̾󖮯Âßò›þ»ŸýjâXøKXðÖ¥©è¶ï ¶I;I2í(nŒyáôª~ÿl¿õØÿè+Y5gfks+Çc\ÿåçýt?ÈV§Ä_ù'>úÃÿ¢MeëŸò¼ÿ®‡ù Ôø‹ÿ$óÃ?XôI-°¿Å‰ÏŒþ'ÂPÙIy¨I~–-¾Ÿ$Ëö¨HÕ„‘€ÅSæÛ½ê(—S¶Dh–ú%¿‰]pTcýg'§=}èQ©Ö`ç7¥ð¬^‹V:Š}-í–ìG¼m œyaqœïnÆAï\¸Yì‰Ø3l]ªNæô§‘ÅZ•õ;°O%ý½¼ƒÌû,Œè ûÛ$uÇjÜð½Õµ¶v—W¶ðÉMõXæâÒYYYTF.y·mR¢5^Aa½†Fx·¬ë–—šv³me~Våm DY¯·ÛÎ\eü¤$"H¤cÄá±É8-JöQ/ê°µÜ>Ç8ïGjïõsá$J“OŠÊXÖî/”͇ø—oÏé’ãŒÐòÉÓÃëâYÞ]!™¬XÛ¬éÛ$ûË!÷lvä}¹æ«ëÝdýSûÈàèë]ÂÛxvïQmî´¸!‹W·˜´ìZªåÉŸ—¦0OÔz…ÖiÖßfÓ^ÚmFçísBŠfHã(¯* tÇUàqMbo´Y/ mä/-×siýˆ|B?µ±lÏ•ö//ìþfóû¿u»fzñÓ¾+™ñØá ½þÌT[−àƨáÔ|£v ’Ý»â®~yrÚÄÔ¡ÉkÜÌ¢Š+ æ (¢Q@Q@Q@Q@Q@Q@Q@Di")gc€ª2I§¬:†X¤+†9q…ûÇðïéO²ó¾ßl ºKI¼ÅÙq$›#·`:×[©^iW÷3ÚÍh¶L½[{gÚUÆ[gbìASÔ€û¸Õk8I$šTTÕÛ8ÍŒÊîªÅS˜=2{Skº¿¸Ò#ð^¡6–«4VTq9r2¾dóAäÙÆ:.;W ZQªêQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEõ†W ²'`ͱp¤å½¿#ŠG‰ÑT¼l†Wr‘¸g~5Ôx^êÖßO»êòÞ'r¶>aè·YÿH?Ü\]þ w"m4éX N”׋¦Êí„EÇšÿëˆã;:nï·Ú¸åˆq“V;c‡RIÜäšh[Ë–LnÚÈAÇ]ÑQÃEÞòÙmNi FàƒÚ»í6ãF±°Òæ’MKȧµ˜º,BHÓy†_¼J«)ÉêyPf§² K.ªÚ§ö\—/rÅͻ±˜Š †¯æ\šõ(mƒ%dž…´7Ú£¼ŠÎEmyܽˆ£p=M{ÔZ—‚fŠÑã´²d»ò¼¦k`ù®zÜŠBW¦E{†™©øOR±Óî—NÓáûZ«´sÚ„1††I³’˜+ˆœoÎÒQ¹$b¯%Ç„ŒS§ÚF¦_'lšk#«cvJ oÌX€ sœsGö¢_aû._Îx `GQÅÖ\ú~ÂÍæ¼jW(2 CÈÈ àƒD—ÞU”C§ÙÍ"#º…°Â»*(¦Ýå°\ä® ¤ÚŠÿì¹9àû‡¯Z Q^ú“x^móWƒMÓÚ 8ZiCYíÀTßS%Hä0r3MšçÁ–òÜÇ5¥Š}˜1‘ÚÇ …pµöm}®Ê-´¤á±KûQ+ö\¿˜ðäÎ2JŒ 2’j+_•ýè?²Ÿó~‡î_Q@eƒï_@\Â5s«Ç¤ÚIonŒî¯d±:íûÁ•Ô#ÐU'¿ðµÝ´Ré–©ÑO#Jö|Ÿ)¢ $R›bPŘdœÒYªaþý•/æ÷zŒsh¶v°éÊYî−£D+óeÆFBÉÆq‘•!Œ6K¤j:,z¿†cY%Vu¶¸µ6L>Ò$b6©HÉ €H§ý«öÞƒû._Íø‘ê(ÈõíñêZ Ïgü#¶#ÏdF>L|–™¡/—÷ªK‘„*ßÅŠÒ¸ƒVÒtÑ¢Û4šp§ìh¢ œl`ÃzQý¨¯nG÷¡eËù¿çìQFG¨¯rÓïü=wi$òøzÞ¦‘ßǶÑ$−o"Èèͅ¶"|ƒÀ;FâXSÖãFKQçøfÕ%û]½«$PFêq@¬[hA‘¼ ÓþÔ_ÊþôÙrþoÀð¼¯÷…_ï ÷mVûÂzMðµŸL³Ê; †[V°µs b;U‘šA2ÉP˜Ã;©Són\20o½Ï†Ìm4{îD‘ıٻ;mR®È¦só®Gÿµ?ºþôÙOù¿Ár¿Þe¼+è©Ádâ¡−꺕œš−¬KeoòK%¢es'*1“,ä÷íÒ§ûZ7·+ûÐe?æüŸ2¾´e}kÞä»ð|V¦éìm’5vI´§ÐŒ‰åîB²’Δçe·—²ÔoìÎ…k#YZý¦YÖ=™ÈýÞq÷Àeb;+¡çu?íEü¯ðì§üǃe¼(ÊÿxWºÜK¦Ûé÷á[hÀÉdfkçÐìïðý¤Š»LîÖ«EiL@…+–ùôÁƒOûQ+ûÐe?æüÊÿxQ•þð¯v¸ºðý¶Ÿ¬]É Ú Óî–Ð$¶Ñ§›#Šc#å fQ–úœ m-÷†ù−.´6†#x-ÖhÏ›$‘¨Þ˜ÀË`eÕzõ?µò¿½öSþoÀð¼¯-_Z÷õ/ Üi−{o£Ø™WË –«©vÚ ¦Ý ‚ €A‘Šµm7†dK1.“kÝ0Ù›−Ñ©,Qs M‹¹†’7äc“Gö¢þVÙOùÊÿxQ•þð¯jƒVðô¿ÖcðõœðÛ@.V8"…Ù¡q¼`ylI ð:Í‘Z—BÄÑh‰£im)EyD î−ªWæ?)éKûQ+ûÐe?æüÊúŠ2¾¢½ù'ð›Á,ɦÂÆ[ ‚¹ùN ŠçÃwš¬6VºN—ð#ŠXîô)õ4³‹ÃÖ½"?6ÑÌÿgJíá|¶¶xcŒw£ûQ+ûÐe?æü ù¼(ù¼+Üã¸ÒÅ„w7µO7P[5òbDÊ‘y…öÍ€9'™ÇJt §öFœ;sjŸáRóh-âþôÙOù¿ælQFG¨¯sóE–,¯†¬÷Ê"kU1G‰VG(…ß“r9ÀõéH·ú“B«áÛ=Ÿ¸[†0Gû¦šw‚0ߘyˆÙFrsÄÐÞh—2Úù~³û™ý³ý—7‡´8fI#A$ñùð~E)—àL*M5ô«³d×>±µƒP,¶rã“{gÚÀ(ÚJ#0ê>R haæ‹ù?e¿æüwá÷ü“×i¿ôLu?…ÿä/ýv?ú ×i«Y[XøSTÒÚtky¬Q„ÛŒàwÀ•q~ÿl¿õØÿè+\^×Nk©êÓ¥Ëƹÿ!ËÏúè¯WѤ? éÿ®‡ù ô¤ÿ‘?Fÿ¯xô]e(óFƈ]Òmuç´·¸º„Y#LÓâ\;‡‚HvNzvšâIiÄ»ÃÅL¤Æ6Ä=òsT5-Z=.fWh7Ë愶ԷšcŒ‘Ïî±Ôu¬ÙuíJÚöê)¬a−m,Ë$I.B¤vðJXIŒŸõJna “JÉç]övÓ$¹ŸJÞá¦`ßd¹»D§ ¬ÛÕ³…^1¾µ éçTµêWBÆéTÄ‹a¨UŒ† ‡(„Ý“Ç g9QŒë@ßÏpÙ…´M°JXd¶Õb öáÆ'8líÀÝ þ²¶:‚ZIbèe%UU]Ÿ%ˆ€œdàäd¨ Ê•· šºw…ô?NšÊ ÈÒ)o ¾aŇˆÄ@U@)òW×r!$+'ÌȬ{à¸'©QÍ“}BçBþÒewgÔX¿™q4M¾h‹ïç• äîÉPìßóÍëÍ 6ðþ§§A« eÔ"h%šá†?( •^qÆâ0H‘#øoM’îIN¤þYi(ĉˆŒ³¤ò`õ;^ƒ V*ë3ͬÛÚÇm²Õ¦’•Øn,±o ¯ðõ\»8líÀݳG²}Âã5? hú¢„ŸP!Dòܘ›k»nÊîi€Ãæ-ÛéVÖzÅæ©o¨F³Üòà0ÜTeøU›%C6:œ×¢—²}Âãl¼;oo}_cÀ°ãŒ¦ÉZ"YzŒ’zc5§…4ë{E‡Y˜ÜYÇV×,Ñ8£’5\ciùf—’?ˆz šŠ~É÷ —¯ô»M™ï/ÌŠ"háU•WÉfÇï’ £kõ^qŒšÍÐöFë\•ý“îðåœK G¬J.-äF‚bc…ôÝ>ÆkMZHÞÞx¦†}ñ–FKeµéŒÆ§¨êÙì)ôRöOk…Æ^øKC½¼Õ.e¸eÔ-ä‚Y!óFøü¶"B»¾èéœ{T—^Ò®mî−ßQ`³ÛêìD‰·’‰:©ÝsIEÉÿ0\d~¶[ãwª3

Client Side 451 How to Develop a J2EE−Compliant Web Service (endpoint + client)

‡¸1ljˆ„¬ ##9À^¹Ék.ëCºµ¿ìû‚ë%ëßFé< ¢Fgl>õfLʆãÎu¿ Z¥OÌ.[Ó´ëkÕÒö8æ[%´Änic¸nÉ'−ß®:TVš=¬ZJióê¦ä−ÜW^{yjìé*Kó``îdÉ=~cÓÑRè¾áq×þÓõÔš“,7©.cGO‘ä‹Êg'g@r*[½ÎöêyîuW}ðË I¾0"IÇæƼ6F2A5{'Ü.Km iv~¹Ða¾1ÛÎdËÄc»;€«‚N?:‚ëÂú}æÿ;X˜¼ÑÜCtÁãzOå‡cåùbP ãµOY¼—OÑo/ PÒÃtRÉôê?˜¬«¿\ÚÎÅ´å1ZÁy−ôk6Lb!‰FÀÝòJFld¨ˆ©5Ô.v—:~™wqz×!Òõ#IO³FÒ¤099È=ª=.ßOÓŸg«ÏäI$Ë4›šBù,ù$rFPO~kœ›Xm:ãZ“Sò’ÒÁ#•|£ómÝKmÑŒà Ø'ÔÍ'P½Õ¼;Üsش쉦\ëV´·ÏöÛG½.Š,¸I@ÛN[™I 1 ä¹áT ³à}& ›+]Oì¿jI¢‘ HPæ4‘…P|”9 ç֪Ϩ\Ûß:Ã−©¶{–SaŠ5PCfÀ,Ù6üŒFmç‹'þÇ¿’ÒÅ õµ½Ì®-#yJ!7,¥Ñÿ×ÅÁTÎ….*Où‚çm6º„׫-²Ja’8 ˜¿q¿#› *¡Ð−‚4†Ö¤6ì’Åqþ¨ã“ï†8ÎãÉ/÷‰bNI¬¹çÔ#×þÀ¯Iâ‘áÝn@B¤ÎïœòIÈõ¬»_T‹OéA{8Úy.5-Ñ—ÈoÏ°È89r –%cʃ¸½“î;¶¶µ77—)¨§º4Ü®‡Ë)»‘ü]óY’xoO–5«1w-Ëî3¬ÁãåÉîâ±n/õD›[†XåÝ#6‘EÉ;÷X±PO±•ÈÏt¾ ¼ˆÀ„È|µ–K¶kUÌ{$C“ õBäöœ ‹]BçRÞÓñçmNCþ‘öˆÓz„Ü¥Ë ã, Æ£œí¨í¼!¡ÚÙ_ÛA5¢¥à ÄÛ[œ¨bØ|§ï9ás-6p!ÔZßS0Í}p·Ed¾›ÊÌ5iHgŠYãó#Û3Çq%ÈcÆFeœ¬Y/µfµÖ– hä¼µ½K{xáÆÜw¨•˜‚T|¸ÈëPZk·−£šB«Å4—RÛ* !ÑGW!›*TšÚAs¡¶ðÅ„-ÕåvU ‘Þ2bTràca¸¹ãµ2 é3\éÓ5ùg²hÞ=Ía’o4•$›ClÆ@PxQ\Ü^#¾—KˆÉl!º•!tt_0²‡ÄzœþÔ5%H–ê−55ã"Š¨é#qµ‰q˜Ø ì' çföòúßÄ0Àb’−4´qùæ$e’G$ÎðËü#!Xsɽ‹þ`¹j?hÃq¿..(BË)ŒÈA‘JâV>a%œ1,ªÝ@«šw†´Í1¬“-#…V6xÿxÑEå#ŒýÞÃŒó\ì^)ó œ¥¬^zš53·–Éû¤3.æFYø]CR¶hbxìgH o„re‡ÍUgÝ•lqò«Œ’2¹~Éÿ0\ëE±{-âÔ|—†òkØåÝaåiK¤`¯ïœG`zŠ‡OðÖ—¦êK¥+Co*MJŒ¡ÖØ[œn?»›#ªXªöO¸\ëJ¶‹C·Ò-õf‰b\(YSVpÉå fÝî·.€ |Ü“÷³šDðîš—1Hº‹ìO$ÌbbfŠf =W; é\´î£2À7À¯z°k†+Þbás¦Õ4«]VèÉH,¸$þ襽Ѵ-AîEÕÄrÁwqóA##$XTƒÕrªØõ„Šåõ}NöÓP)¤vÑÃŒÍ H¤³8>c)ÌK…m§9oîš‚çRÔ´ñ¬Í=äGe²8#[R¦I$UòÁ!>wQÀïõ¥ì_p¹ÖZèºM‰µ[K˜á¶³½{Ë{xÙ‹ÄèÈt™ñØ·`RÀJ3©IöxšI−áYU|‰$WVuqóg>2xÝì1ÉG©jWðhóÚÞÃÞÜIk*µ¡m¯N]†X½p}MLu›¯ìí:åR ÷7Wˆsµp‘Ü2òOËÌ+’{gð~Å÷ &séÍuaqk©^N±Å'Û.…²¬i¼®~÷Þ ØÎ2=8¬´ðF‡ö©¨8/h¶m(‘7ííŒáÙ¾§ÓŠÏþѺóšë1ý‰5°0y9Ý2ÿ~xù›;pxÎNkœƒÆڅΉ²ÞG¦ËupJ’†CÉÎz~ìï¡ÀÑìšê;Ûo hö—2Où óG1DÁ(û}„O÷PwÉ7eÓtùt«ëz¢;¹$‘Ø:åK¶âl}k„‡Å77÷òAl‘D‹öH‰uÜVIpXõå@tÇCœäT’ÝëqhúèÔíKZK,jŸaá¶6ÜŸŸ½'FýBçfúl-É©E«¬~l‘¼˜âpJ0à v>♦èöÖ?dYµSu‘j"%Ys•±Ú̼ÿx÷æ¹KcQ±ÔÍ£®–+€’²Ç±Œ~O˜Ì£'‘×ÂàrE−¶µ{©#‹7÷fyCÇnÓc[™bŒ*+$çÀSö−õ Ö½"Ká}PÆêà[H2§cHUÿ„ÏËòÚÊa—sÊìÛʪ“¸ä䪅kµ‡m¢³«—„«0 •;êVïëÖñìfFÞñ ¬«½÷ óØsÒ™‡¾³f4«½R e.-−¼¯måË€â>^øçâ‹0æ]ÊCÂQ ‰ê¬qÅA9eÜÏ“À¶/löïajл³:³1ÞYB±cÕ²s“ÉPO ½?‡dºfiÒ FbmìNPœ‘Ó¡ÀüªK-Eí–Þ[kèî½ÎP¥œ+—£NØæºJESørIÀ$ñÅO/…yc–Xay#bêLÔ¶î}@n@9ôÅuÔP%/†Äw0Ë —$”n?;¡[Ø€‰‚1£Š‰|l·Î¶v¢X¬rd–X°ÉïóÜç−óì¨ .?ZÅÇckrãr£0Á#n>ï9§3 –œÎÐÁ晥·î ´Ë"ƒ¯Û`>» ýÄöYÚH¡BUW9$c ·6âßìv¦/ÊÙ“_•¦Ï—é]•ÉÂ*g™ä[ïÞdÉcÆF“=:ïfo©4öðË5¼¶í¹†ff‘ ác’OÍuTP,|6ÿkûW•Ú7oó7îÛ·=:íâ«IàËi-’Ùìí|„weŒ£çbÎ8ê¬NJœ©î8ÙQ@æ§m5·„µu˜‚Í sü5Æø_þA²ÿ×cÿ -z‰äXÕ?ëÚOýןx[þA²ÿ×cÿ -bkò¼ÿ®‡ù õÿȵ¥×œ?ú¯ Öÿä9yÿ]òÖi¾?µ±Òí− …ô$Eƒ® U?¥E¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh·=+ñtp][]Ø\Í$òU%[y mÇýö´Ÿð²í?èqÿ}- ØM]Y˜ÚN“s©]]ÛßK Ë+2@Ö*ª-‰)µJ†à £¼Ñ4ÉÖhmõIâ·f™Õ—pJ™−E¾3ƒþõÒÂÊ´ÿ mÇýö´ÂÊ´ÿ mÇýöµ|ò3öPìdêVÚeýýÕàÔgY%þS ð´K"îVP?¼ÏqÁj´Ú^?Ë.³tË$Ë)þ˘RÙ l¸Ê·N0EoÂÊ´ÿ mÇýö´¿ð²-?èqÿ}-.y£Ð¯k>›'‡®tFñÞ9-V×̵Óg¶Âd’§'©•Íà¹[)SÎüŒtÆ9«ð²-?èqÿ}-/ü,«OúÜßkG3)Ó‹V0l4*ÆKB59¤[{«Yþm.l°†ßÉÛ÷{“»=º{Ôzf¦XGjªË!‚{I þËœn+½;“Ÿozè¿áeÚÐ6ãþûZ?áeÚÐ6ãþûZ9åÜŸeÆ‘¦iÚ]í-×ö´®ÖòÅ Íö«Ï]Ʋˆ.5hšH™7¨µ·R@`w+ÀÖgü,›Oú\ßkKÿ *Óþ·÷ÚÑ)9nT)Æ Ñ;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@ÛûíjK;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;š+†ÿ…—iÿ@Ûûíhÿ…—iÿ@Ûûíh¹¢¸oøYvŸô ¸ÿ¾ÖøYvŸô ¸ÿ¾Ö€;šCÀ®þ]§ýn?ïµ£þ]§ýn?ïµ

Client Side 452 How to Develop a J2EE−Compliant Web Service (endpoint + client)

¼]V×–»I¼‚’-¼“’Fb@{Ô÷®fûIÒnu;«»{ÙaYefH …Òª«@"`Jmc’¡¸#‚A-ÿøYvŸô ¸ÿ¾Ö—þU§ýn?ﵪRkb%ËtswšS%¨·ÆqÐ`ÓÞ¯jVÚeýýÕàÔgY%þS ð´K"îVP?¼ÏqÁk[þU§ýn?ïµ£þU§ýn?ﵧÍ"}”;iztÿ,ºÍÓ,’C,§û.`IKf°àg*Ý8Á¢¯i/…/t{C÷“Ù‹Hæ‡Kp{Al‚Xç'¶:UïøYVŸô ¸ÿ¾ÖøYVŸô ¸ÿ¾Ö—3¥²2d¶Ó"ÔÒïO¿–Iu…ôÙØ OpqÐãïåKá−íšõ©‚˜*[Kœ‘þç§û¿{×Wÿ *Óþ·÷ÚÑÿ *Óþ·÷ÚÓU$‰t ÷F¡§Z^[_Bº´£í¯æÕ$opq‘צÿ…•iÿ@Ûûíhÿ…•iÿ@Ûûíj¹ägìc§‘N6ÓSÀáŸí É6¯j·NŸ¡È®Þ¸#¶Ô4›»5°xš0Å×#ª>ÿtßõÜÿè+@Zßü‡/?ë¡þB¨QEŠ( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( µu~ÿtßõÜÿè+EÿÙÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82Ï{e¬’K3,íi²Ê~Y :€$xͽ¿˜‰æ2yÇ*¿Þ#wOzXô−WTŠÚf¨Y‰$ÚHç³p}ø¬ûï \\Ç}oÛ,SE8V'y2[ù!Bà(ûÙÉôÚ95bo †¾¸ÙlàÞ4 ›pÀDl¸B¼Îí™ù5‰ÔHºO‡dXÚ8 ‘$ QÒFd;züÁ±ÇÖœú7‡ã´’í-àÑ£Hò‰XªªçqÎz ú`ÖWü"—ÒÚ^GqqnÏpg!K— £ HE݃ÉÚ2Nµ«s¤Ìºv¥ºÆZK´»·…>PB˜FOEÜcÁe¢D~kLˆ}[$cÜGzpÐôѨ·€´€4`Lrà‚AóÀ'CQê:uÅþ¦n!…B¤0:-Áز2Kæl8 ÁÆG«Áá™bLíleÍ¡ Ìb;Ǹ‘±¥\(é£!zP³£xyRg0Û…ŠÊÞyÄgѾn±¡´M%‚3ië‚DXg!ÈRØÎÐHÂ’3ƒŒØ|3ÛYæ´‘`XÉU1´„‘¶2#Èq¶M½2Ø Zap,t«¨Z)ã’i¢@©ŒïÀx€¼c‚Í6ÿÂ7£ÿÏŠßmþ4¿ðèÿóâŸ÷ÛjQ@ðèÿóâŸ÷ÛðèÿóâŸ÷ÛjQ@ðèÿóâŸ÷ÛðèÿóâŸ÷ÛjQ@ðèÿóâŸ÷ÛðèÿóâŸ÷ÛjQ@ðèÿóâŸ÷ÛðèÿóâŸ÷ÛjQ@ðèÿóâŸ÷ÛðèÿóâŸ÷ÛjQ@_ðèÿóâŸ÷ÛkXxSÃÏù´Øȃ˷]Ì=}©*ܲ4ZTŒ™È„èOC#R¶ðN™seo>{¹|´›åÿhóÓ8nxoþQßmþ5ó׊µ¹›Ä–Ægo−P¨9èrk×¼;âëë-"!յ܊ ~õŠ¿â{ýkcÍhœ’ÄòTpÇJþðÄ{L„}]¿Æ¡_ øEîE²ØÛ™ˆ$ vÎã\滫jØÉ{}w¼+Ñ"bY¦kWÀ:mÃYjùJÍt£É¿åœ}Gâzý1IÒåä ÏS’ ÔÖ> ðÚ©'J‹ççoñ®û5 ÷cMÒSMˆ¼‰‹íw >o7ÁÏJô-já-tBáN;iO¸SÖ¹8âx.4K4O1Òa•Äq9ÿЕyõ"¼ÌUYBp„^ìô©B.2o¡ªþðœ2¤RYZ¤÷¥ ·Ðn©á ðß?ñ+‹þûoñ¯3k{n×W¦K‹™¥‡ytÜ“©@eVÈæMû£TûÊB`µ¥ð‘+6â ¿Ínz…Æ;ÖÊ·tgÉØî$ð‡…¡]ÒéÖñ®q—‘€ýM$ð¬1ù’éöñÇýæ•€üó\¹®Ë¬E£Åw$3G.C¢²o`¦W`xËô,þ•-|׺fi1¹–h4õV.Ll®WÌCÈb|¢§¦2>a»—í·²Nç¢Gàï JªñéÐ:7!–F þµ'ü!ÿ T_÷ÓSðB− Mª»ZêM²F1 `oQØ©ä“]X-"î®KV0?áðßý¢ÿ¾›ühÿ„#Ãô ‹þúoñ®‚ƒT#Ÿÿ„#Ãô ‹þúoñ£þ ÿÐ*/ûé¿Æ¶í¹»{E#rˆ$hC꤯P ß³ïôÙ^kš]½Ð Wÿ„#Ãô ‹þúoñ£þ ÿÐ*/ûé¿Æ·ƒîÁ ÷Í;4ÏÿÂá¿úEÿ}7øÑÿG†ÿèýôßãZÍ©X®¤ºs^[‹æÎÆUóLyÆý¹ÎÜ‚3ŒqM¿Õl4«cs¨ßZÙÀmÌËäô列ÿG†ÿèýôßãGü!ÿ T_÷ÓiiÚÆ›¬[5Æ™i{¶Æ’Úu•C`¤ŒàƒqVÚUE,ä*–$ãÔÐü!ÿ T_÷Óð„xoþQßMþ5-c¨Ùêv‘ÝØÝAum¤º»¶²€ÏuqU2JáT!Tdñ’HÔ‘@¿ð„xoþQßMþ4Âá¿úEÿ}7øÖø9´ÿG†ÿèýôßãGü!ÿ T_÷ÓlÛ^ÚÞ…µÌ3$0Ê#7–àU±Ñ†GEHòÕ™ˆ £$“€aÂá¿úEÿ}7øÑÿG†ÿèýôßã[V÷PÝÛÅqm,sA*‡Xœ2ºApAÅ,·0Â𤒢ÜW$|'?•3,À^3E¹w2;Áöhà3‚rú ågˆ¿áœÝ_’Ëà7úÄQ$_kI@;cJF…³¹!pY×I,p@Ψ3݉ÂÏCokuq−½¼é$±½W¸¹»»c ³Lí,Êû^é^î9“q$d\“ß.u›['å(ñKBÓ‹>mÖØ⦵ÿµfÎC~µôðÂÆ+mO¯™ÎsÑÙyôZ’Éwmg¨YÍþ¼Ã$Œ=ðnüê− Ñu-6ÞX-−'µÆ- £pkÍ4zXßc¶PŒ05¯àLZøºóIGÄ(fDôa×ôþUÏ_”\-±Û‚ǹMA»¦zJƨPQ€T”ßJuqØöƒҊÅñ7‡×Äz3Y™mzûu +ÆήxËP³qÄ·hÜçåo6pÇq=ë¦Ðüá›Ãce{ ‘−Ä‘,†è²Ò3çw^½ø¤Ñ|%5œú•æ¹ª¾µ{¨B¶Ó;À°Æ PØQI–bNyÏj̇ÀÚþ›oýŸ¢øÞöÏIQ²+yí#¸’Æ6¤¤‚wƒzç Ô5/ éz¶áËØdKZØÙ Ûz$sÉ›æ!T¹L˜{×S£\kúoWDÕu”Õ¡ºÓõ$6‰…ÒDB /U>g|‘¦¬¯¬àЬt«;™Ñmõ(u'œù²ÜJ’‰»deœOoNÕ.¿áIµ»ùï!Ô~É,ºMƘ?p$Ûæ²6þHÎ6cóÔb€“O“ÆWOT§Êì¼.x#yjoŠšÌz_„ѯ…ö-ÌZ{]æµ4 ]éúœÚ®³¬Ë¬jm‚9š!ˆ•%U‘’TO\œæäþ[¿YëÓʲ Y!µƒÊ»yß |ç%@\vçÔÐá?hZ40´Ñµõ−:Âݵ›X£ )Re~P ûy€cƒšÞ Å÷> ²Ö5 nÒâÖöîÊ{‹jmã{ˆÚ1 €J¿9äqŸAÖ¼−m¬k:^© g±2£‡ˆH. ‘ ¼L$ƒ“œ`â5Î?ÃkÙ¬#ÓG@Qµs€¹Î Ô/½ö– .—ýälÈÌgßœûãühΦñ^·k¢ø~æ÷VºÐôgÑ!¸mBËIáeœ… ®‘ (qç€)׫®kÚÇ€.×ÅvÆyÜIw¦Á‘H¥Ì£zýæP”ü ƒŠêSÁΟg¥Å¢x¶âÂK;ìf j³C0Œ ®"fÂ7\NAüi'ø{4ZV‹“¯\ZjZTÓN—ÒÀ³™d˜0•™ $»Ïýh,'ñ>¥â¾µ ÛiwM-”¶ÈV6èÀK ‚`~^~öIKñ– Gˆíî®x5ÙYæ@» jФL äó…'>þÙ¬kj¢].KÿÝße\G−œRZÆ‘PWç †wØÌ7nœzONƒZÑü5ñPmyîÍ-ÍÚ´RÙA²Y„1½qÆß»í]CÏâ¯jÚ´F¹‹m¥m¶@¶É;ÜÎÑ$›Ÿzˆ7¨y?6OJëÀWsÂMm¼ÑéºòLïjÖŠÆ)äDS pA û¼uëÞ¤Ôü~ú¥ÍöâK¯¢ß"@Áox—^ÿ„:=6æÛL¹ÕMü˜ŒKh>C"nÈ*Ì àrdz?jZ«ë Ð5ká¨É¥Iô±§^óÃH¯4jbA$€¸ç G`v¶ ãå>†¤:«) -ч c\Ÿ‰¼=©ëSZ…Mc¤‡pÔI,¤ÈŸöÓ=Óo4}^H¯–d[™−fE¹¨VSm±"þàD¿6J€!³Åflur\C ÄÓG °áxy÷eRSR`úä5mòo·[Åm$ú~d0@gp?d`>f—àòz’I†^ú6£4“¡Šd\!¸\ûJý²9)VÈÛ ºœí”î{Œ}k–MP;,›£¸V·ÅÏ ¿o™Û »ê%GqIá¡3ke£›jCåÍ3HÅ%›Ìc¹Tð>\ ðH«òü¨¢Š(¢Š(¢Š(¢Š(¢Š(¢Š;ŠÞѾïý²_ý ë¸-íîÿÛ%ÿÐ#PŠóJöO Q

Client Side 453 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Ízs.²ûV•.?ºió.‰ªÍ øºYá8+T¶Á µÕ³æÎ|-uS^â{WÓµ±qŒv·Öµtfk@ ÓÎ+º”cV¬òëÊTjs.§«kYYÂVÇÃÒy§øç”Èú‚ä×=µÄ×out Ê…>m£ð¢OÏ,x’GÀ晢ø–]í·-¼· UCí[S¡Z¨êqâ+ʺ³zZê°›i´é,Nw4«|2BöÆp8ïÉîE v \Çp>„ú×A7‡£óð’vÜ‘Î2A¦«ørùï¼`÷oyqiEx†ïùçÓ½M¯K–ÞBZ4Vg=ÉPHô ãëíV~À—…ô’®Ð'€#ýµÍD䦔h¸û»5¥ýOrе µ=.+©¡x™‰:•,°yëŠÕÀ»@éOZòÞçÒÂ.1I»‹E™¤P¸£€æ–€ QIšZ(¢Š1EPEPEPEPŠ(¢€ (¢€ QŠ( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š) −Ph¢’ŒÐEPP«l’xýNˆÒÊ™3̇¡Çð·çIoþ-¿ë£öÇñŸóï\þ§Ãk14kn#`Îg°y·ÅätRã~8뜀‚o]}+ε‡SÒbÔ¤’GæÅ,JÕc™Y@Étàr É»_ Ù}¡.É9ä`ÜØQœ×7á ϶Ç},w»âG¡ÁºßL6TñC$áHn#?(PJàóòƒ×“Ò£µøAªNàI ñÿ^»üÓ−™f¾W»Ïo»ÿ|ô¢¦¡rŒmÚ\±#É$×¥ø6æ?í„\³\dZ>3ðJÃ%¼@0x½/ÖÚÚ1~ìÝYtƒPû−¤öÍo$0ÂG˜ "0[,T•êP݉Åihw1æ«ØÜĺư/ü-ýü·sjŸ>Hgš$„®é"‘v¶ãµNᜆ—EÔä¾:€¸yb’7 Üîåa¸Ç˜ÀúñŒt#Q¶âR©}´*ÑEäVÿêØŒ¬“8ÿ|Ñ)Ä–à‘Ÿ0ã9þëÿõÿZ æ6äŸÞ?|ÿ¬ Jk„ÖbHšÜÃö°.΃bŒykÁÊì?7£ïÉÁP µtTQEQEQEQEQE»£çoóÉô'¬.â³ßx×ü%šÿý'ü—ü(ÿ„³_ÿ ¬ÿ’ÿ…0=—'üšH#›ï¨5ãßð–kÿô›ò_ð£þÍþ‚“~Kþì+*à"âÛBzÄ•ãÿð–kÿôŸò_ð£þÍþ‚³þKþì+k÷cZ“ðã_ð–kÿôŸò_ð£þÍþ‚³þKþë×q\®$@i–ö[ª@+É?á,×ÿè)7ä¿áGü%šÿýþ‚“~KþÂY¯ÿÐRoÉ€=’¼gþÍþ‚³~KþÂY¯ÿÐVoÉ€=˜Q^3ÿ f¿ÿAY¿%ÿ ?á,×ÿè+7ä¿á@ÏŠ+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=ŠñøK5ÿú Íù/øQÿ f¿ÿAY¿%ÿ öz+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=ŠñøK5ÿú Íù/øQÿ f¿ÿAY¿%ÿ öz+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=ŠñøK5ÿú Íù/øQÿ f¿ÿAY¿%ÿ öz+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=ŠñøK5ÿú Íù/øQÿ f¿ÿAY¿%ÿ öz+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=ŠñøK5ÿú Íù/øQÿ f¿ÿAY¿%ÿ öz+Æ?á,×ÿè+7ä¿áGü%šÿýfü—ü(Ùè¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð g¢¼cþÍþ‚³~KþÂY¯ÿÐVoÉ€=’¼gþÍþ‚³~KþÂY¯ÿÐVoÉ€=—x×ü%šÿýfü—ü(ÿ„³_ÿ ¬ß’ÿ…{7J9¯ÿ„³_ÿ ¬ß’ÿ…ð–kÿô›ò_ð ÒŠ( ÿVßõÑûcøÍ,¤ùuǘ{g-ù‘Þ’ßý[cë$éþù¬{©ÛûJTÝ ™F$Ô±|´ä(=_=(VöþÓMµ’îöæ+xÒHØxõR)‹”¦í#F å®BY›s¹=W`Q×c¿'œ{W'qwâ¤P¨×ÚM,(?h[\º1Ú2>Ϥ ¹QÈ −þ§ªDºzé×Íq‹!óÎpÈ[p ¿Ü“îÖ~?‰§^]ɯßÛÏ;É (¢0 >â°%Nyií, )Û óÍPEPEPEPEPEPÜV?ãÛKÿvOý ·ûŠÀñ§ü{iîÉÿ¡Rr±A4äˆa’R:„BØüª?óþÏ-O–öÓDò¤eŠ°.¬AÆr8¬5Ì™a÷Y[rÉûµU#ƒÎàXä½ézsôæ”e¾è'‚x‡5£%ÜìÍ…œ«åÛÇoïsúÒ”¸8 ƒ´œgf´^öܼ{ö¨ ·vï›'ªÜtöæ“Ï´V"¨²Æì„ãåq8$ó»×ƒ@ÿ…›T¾yRNüîÚ>ïË÷»‘õëÅ$Êc}ÿ/'þ»TŸÊ€+QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEé´QEE9·9ýã÷ÏñŸóíDØó 㬄qü−ùý?ˆ?Õ·ýt~Øþ#D¿ë ëþ°öÏð·ùÿõУڲ-¼?¢C¨¾¥o¥ÚÇxX4 Ê‘òå{/ªàõ«UáwP@…ÜyÈ*3ó94%ÅÌ6Vï=ÔñÛÀ£−$®@÷'ŠK{˜ní㸶9 q¹$Ã+èGæ·—ðÝmOL@ƒ—wË2;€ÂPH*1ÞÊzt5½¡µÞ™¦êÚ³ÛJ‰4p›x$Œ@×7Þ™6ôÍv@ gš#w“Ì›²;ÓïÖ¸Y5ýWJ¶û Ôâ+ËxneJxV5zôfÞ;¨ƒB—*±Â…$P ®[¥mkiÓõ•]6[¡êyðÛ−Ø‘3±Þ ª.YÒøQSûsX¸´2¹ÔÊ©’"!á‘ì¼òrNr¯ò\öÀaš+‚¸ñMÔ6mw?ioì§“Ì [3(“r¾ÿ˜¯H݃•` ‚e@IÎ Ã’s…ôÔÑ\æ«ßêv1´ÐwŠæVu æeGP†G(>ûgi#Šè袊(¢Š(î+Æ¿ñí¥ÿ»'þ…[ýÅ`x×þ=t¿÷dÿЩgëUPü·] i_ËŠìÛ¸†Gά˜ÁÎxì{ZÖ¶–7³}¸ê{XùkýŸd÷ È9ÎÐvû-UÖ−lŸK·Ó¬£‡·†Úy/ì×DPƒÒà±Ú9É#¹¥n¢w[«9ÚŠÌzáFM9¢•sÅ"¯©R,73ÛMç[Ï$2 áãb¤g¯#§zêçš]OĶ–WÓ\\Y5ªJðXÂض}yÍ!œ…ÙhzNŸ«Ú‹‰´Å†+‡•Q£’i £¿ÝAybrOLª–ZiÊÔéàÍq¥}-®Æ …éÕú€9z+¬»Ñm‡¢º·Ó˜>Ø ¼èà±PH'(ÊÛ±Æ1ø5rïÃzoŸe[V{óo(ŒÈ.Æ`I÷‰ ÊÉ8é@?^ÔW‚>â»>—ÙðÃÁ+éÒ‘l^F2‘Fçw9=öä`cm6 Óý‚mJh--6ÛùÏÑÐe¸98#°Ï JŠêïtý+I†õÍ’ÞÔ²y“0¦0ÅISÎG-`ë6ÑYë—ÖЂ#ŠfUç(•Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@›EPVÿêÛÿY'O÷ÍcÍ·Î?ÖqŸ÷ˆ9¹Ïﾌÿœv¢_õ×CßÂߟÓü(^Õ¹Â1ÿ['O÷Í2öI"¶Ýms$hýçU·˜ïOóæót`Cï9Æ1Œúc¥u¿ØZ'’f¸õ¡Ýårò;;±Éf9$ú“]ˆðîeh€c*Œ²yÿ2R;S?°´Q˜¸ò‰À´pO ? >Ší†ô±Ÿ’NïOÓëÈüÅ7ûFÈä°Aûþ¬z½O¥q´Wd<=£´Üd%üÇ8üGçRø{Ã:^¥«Cr’¶‘¸§^Ìð[nâèƒrîû…è'‚x²t]a¯˜ádò·Ü©ÆXœºJ#vrI#ƒ‚ Q·ð¬.ÑG¨Þ‹3ÂÛ¦ÐT ÎI sÎ1Ïz颵‚ U´H$Œ`u÷ ÔQEQEQEQEÅ`xÓþ=´¿÷dÿЫ¸¬ÿǶ—þìŸú E .´=jÚ% ,°²"ç©(À~¦§¼Ð5¬î

Client Side 454 How to Develop a J2EE−Compliant Web Service (endpoint + client)

mBâí¤°–f£O²ÊÑ”Ïȃp9ëÎßCœ®‡€´ûkÛmA®|ÌFÉ’2ö>†ºo±èóÖëþÿKþ5«|NÃQ”¶G ,kÏömÔÈ—‚im.^×|Š!–1…lC "['ÑA’mW¸– 4Ègºµ™n#E 1¬áçùR®‘(Î76;o±èƒþZÝÿßéƱè˜ÿ[týw—üj>³Gù—ÞW³Ÿc…¹Ð/å·S3ËpÖ“$Vá fV¶\ÿÏ\¡v%7îÀo)NS-|;lŸP€Çl¶N¾lÒÆešg”°eQ—r¶TmRã'¸û†qûë¯ûý/øÒý“E"k¼ö"yxýhúÍæ_x{9ögb..anõf]>MSGÒíÞŒ(òÜÄûe‹@#=C1³Gù—ÞÎ}™ÂC LoïͽÄÞcÞ8sn®v®]o¦\Û½½ÔúI¼¶§Ñ–ØMóˆpò(+AQ•9ÚéÔ–Çqö=þ{]ÿßùƱè™Ï›uŸúí/øÑõš?̾ðösìp¶zF©cgo`ð−Ænt뉮Ö`DÙdûß36`f`‚9ÝòÑi ½¢Æt‹{‘ƒÛ\Á˜Â‰ßÊ>cÕG–à²å°ß*°Íw_bÑ:ù·_÷ú_ñ£ìz'üõ»ÿ¿ÒÿY£üËïg>Çc£Oˆšæxî›mÔ÷ 9hEdßµFÎb€bH'jƒÐxjÜÝÝøšÛvÃ.È÷œetükOìz'üõºÿ¿ÒÿO§¦¥É³Gù—ÞÎ}G@Ð|T4ÄÑo,4½)4ý"]6×U‚O6y$`eÁ®;rN? −?áÖ´òßÙÆøF|#ÿ>òßÙƬÑþe÷‡³ŸcÌ(¯Oÿ„gÂ?óï'ýý—ühÿ„gÂ?óï'ýý—ühúÍæ_x{9öòßÙÆøF|#ÿ>òßÙƬÑþe÷‡³ŸcÌ(¯Oÿ„gÂ?óï'ýý—ühÿ„gÂ?óï'ýý—ühúÍæ_x{9öòßÙÆøF|#ÿ>òßÙƬÑþe÷‡³ŸcÌ(¯Oÿ„gÂ?óï'ýý—ühÿ„gÂ?óï'ýý—ühúÍæ_x{9öòßÙÆøF|#ÿ>òßÙƬÑþe÷‡³ŸcÌ(¯Oÿ„gÂ_óï'ýý—ühÿ„kÂ_óï'ýý—üiýfó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5á/ù÷“þþËþ4}fó/¼=œûaEzü#^ÿŸy?ïì¿ãGü#^ÿŸy?ïì¿ãGÖhÿ2ûÃÙϱæW§ÿÂ5á/ù÷“þþËþ4Â5áù÷—þþËþ4}fó/¼=œûaEz„~ð¤’*%´…›€hþgk-§U• ü®OÌ+ÐG†ãP LI“¼¤úþ4ó HÒ¡‘A¼¾@=F}ð?*áXj‘“~Ïò:=¼−ncÍ›VÔoŒ÷P5äJ~Ïz5ŠÚgUfB |²6צìq Í€?¼ÌÅIûÁ¾^œ„»‡JÆÅÏam{−°;JaB¨eO²\J##s‘†~~3ýÑ‚¡Ÿƒ:Ͼ32‚¢CÌíœç‘øm!ˆÃÎ_䈘ð[øã>”G 8ÆζZÌqVÚýì‹N,â=•¦›£"¢?*$,ø³}ÝØ9À«g¯êiz–’ù¼xä“Ë ›Éa H6íXò8rÀ…àÍß'†b41F½a+zØóÖøF£,Ÿ¸ÞŒÎä «¼AìNO|U}^Zþì=´?˜ä´]RëPÖà…¨•!Bsïpùï…ëÀ9û£ßÑd¸—@Ód¼ßö§´‰¦Þ0Þa@[#-ôðÚE+Ë…$åÝbŸê{Ó×@(Š‰**¨ÀUL==\%Yü0±QÄS[ÈË¢µ¿°ßþ{ûçÿ¯GöÿÏqÿ|ÿõëìúÿÊ_Öiw2h-oì7ÿãþùÿëÑý†ÿóÜß?ýz?³ëÿ(}f—s=Çýóÿ×£û>¿ò‡Öiw2h-oì7ÿãþùÿëÑý†ÿóÜß?ýz?³ëÿ(}f—s=Çýóÿ×£û>¿ò‡Öiw2h-oì7ÿãþùÿëÑý†ÿóÜß?ýz?³ëÿ(}f—s=Çýóÿ×£û>¿ò‡Öiw2h-oì7ÿãþùÿëÑý†ÿóÜß?ýz?³ëÿ(}f—s=Çýóÿ×£û>¿ò‡Öiw2h-oì7ÿãþùÿëÑý†ÿóÜß?ýz?³ëÿ(}f—sÿëÿ|õèþϯü¡õš]Ìš+[û ÿçºÿßýz?°ßþ{¯ýñÿ×£û>¿ò‡Öiw2h-oì7ÿëÿ|õèþÃùî¿÷Çÿ^ìúÿÊY¥ÜÉ¢µ¿°ßþ{¯ýñÿ×£û ÿçºÿßýz?³ëÿ(}f—sÿëÿ|õèþϯü¡õš]Ìš+[û ÿçºÿßýz?°ßþ{¯ýñÿ×£û>¿ò‡Öiw2h-oì7ÿëÿ|õèþÃùî¿÷Çÿ^ìúÿÊY¥ÜÉ¢µ¿°ßþ{¯ýñÿ×£û ÿçºÿßýz?³ëÿ(}f—sÿëÿ|õèþϯü¡õš]Ìš+[û ÿçºÿßýz?°ßþ{¯ýñÿ×£û>¿ò‡Öiw2h-oì7ÿëÿ|õèþÃùî¿÷Çÿ^ìúÿÊY¥ÜÉ¢µ¿°ßþ{¯ýñÿ×£û ÿçºÿßýz?³ëÿ(}f—sÿëÿ|õèþϯü¡õš]Ìš+[û ÿçºÿßýz?°ßþ{¯ýñÿ×£û>¿ò‡Öiw2h-oì7ÿëÿ|ÿõèþÃùî¿÷Ïÿ^ìüGò‡Öiw(ØÿÇô?ïWãŸù®¿ÜÿAèði ÂHf)Î6õ¯8ñÈ?ð–Ýqüÿè"½œºŒèÁÆháÄÎ3•âuTQEz¿ú¶Æ?ÖIÓýóDßëmóõœd°ÔAÌmÎy'|ÿÿ8íÒ‰ÖAï!ïáoÏéøö ¸ˆÇX¡”N ŒÊò(ÉerT{jÝVâÕēƤ;“ºA7ŸóÝ(š¸ð-þ©¤iú6§s±¶…!³Èá˜$ #åd¶H,AA«úV4k©Ëkq¥±àXü²þóäv?wœu4$þÕ–{KK¯E»Å4²ÉhJ3²²/0ån$üÿìàrEUðíÞ£$:˜ºgkEˆÅ5ÙûA†B¹x\©Rå6›9Ë œƒ™…%Þ çwftW6·fCÌYé¶ö¬rF«!_ãlÌN$óÎÏZç¼A®Îø†ÊK‹k®Ó_ÂcB+E³†l7ÌWoÊOuðö·tö:¢³O© xæ…ÈS+–Œ·Å@S Ú2qü`´¢“WLÍÞþÒm–ŠÅÃhÖ1«30£!‰''ÞªÚø?A³g†ÅüÕPêiQDÜç€Ê`}…G‰£Õ¦¸û4Ù™`…¬®P¬®U˜®e(…F9bà *ÐñƒÛMw[H-Öv";pQd Î%ÍŒäÂ# æÚ~ô†/Ÿ^ôÁàÝX°³˜HH>oÛgó#òð~àYû[2¹`ˆB¡èp«œñØŒiÚè‘Æ·¢êA?Û!H#Cùcn$Þ79Î6÷%î-qmq VQÍ-´wW›šA„]„1;Ë,‹!ÓV'w–DÙ·rdÖÿß−E¿ú¶éþ²NƒÆh›ýe¿OõŸì7åþ}hZ¯ 1>ZDÏÎãŸMçÒ¬TVÿêÛ§úÉ: =½Ð¯lÌY[_UW,ïòdP21ƒ¼Œ>l n®‹OÒ Õ«±Kok~ø(é´¼lIm?2î ÊI ÙfaÔ»âr=;–ââèBÍ*3›’¨¤;•F÷±ƒ‘Ig®£hWz•ÙB¶©,ì−ÆíЮæVQ¸ýå_Qƒ‘ØÕ¯‡C¦õß_øb¥×…7ÞÊl®~ÉgqoX—œàÀv9çMõ‚ÂîòöÂîÎ;XÚWY„e™UK»‡cÔi‘jñI{öo²Ý"ÚÙ.SËyUKbݹ*•Ã−´o²_=Ô’ ™¥3¨@K†šY@ò¸38ÏS…ér‚×É?´¤/9ùÜÄG“4'¾I+1bI?0Ï€5%ñ›“Äó0– ¸lù²íرÜ9íƒô«?ÚÚp[†7öÛm'>hÄg§ÍÏñ@÷~[³t-vËË6ÕÈò€³G ri×Þ“M*]´/−Ë\XÁhÉD_‘² °òÁ ’2yS‹Öš-äbH®c \ ÜàšV‰O^ŒêÁ}qÅ2×Y°¼[O.æ5–îš(]€©−WÖ4gÕ$}¯G=»[ͽ7`n¤‡ARFAëÆ𽤡ú;IaC!ÚÚý™2áT± Äçh#¯Fö«k}g|ö·pL±®ÑÈi÷ô¨Wµxm%ýâGuËšcäUݸ£+Î1zÀ£ká{KgŠà”’ú9ã™nÌ*$ùcHŠç® ©î9ojÑÒí$³±Ù1CAùBKæÿ?ÍÏ.Þ+f[ëh5 k e sr²[Ò×#í6[Ác‚1Wtí:{kÄ’fF[{D´‘y˜ù™ö Cq¹’]{L†ØÜIt«‰NqþÉ>ÀdàRË-YÁy=´Ÿi ¬sH−¤1ÆÌ€ií:¼f€4(¨-®"»¶KˆX´m‘È ‚ yAAT´QEQEwãOøöÒÿÝ“ÿB-þâ°Ki“ìOéÜ©+0àÆÀ3‚ 1Öp?v¤~{ ŒÔ_I·–+yåefPÁp'j§x·ÒÿÝ“ÿB¤äh¢Š`QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzmQ@Aþ-ºÿ¬~¿ï%Ï™_õ‡?÷ËQoþ-¿ë¤±ügüç¿Zÿµp7˜ÜJ ±8%³Wðühxm yîV§/—gx¯!ª:4làeC¸{®G½Øo¯í¡´v·–áv6Û6È!ܩ眀«ÚRÓ¼W¤éבÜ@mµ¬‡ 2G#`È£a¤ mP=u÷Z“ap°^^ØÛÌêcšTF ’Áçò5x.ap ñÆjiEÁ5{ïøMI¦sš—‡'¸[ä‚áæYŒ ºœÊáQ÷4Y‘\llgæVå›9–þ¹·»Ò%U…¢¨w™Ñö#9UPÇ @1˜ÇMÁ•B×Q´çÔ˜>õb9K/_YäX- Ðrdaö¹"2n•ÛnC¾ñÙË×ÑøZu¶fšÞÊ[9î+¯ÁéƒFîÓ:Š†Šäl¼1{l¶ÿdY ·†6»W;ãÙk䘗åÉBÿ?QôÏ4ëP±•.a²±I!š9º\²âÞH™·lùI2nÆp{œ×YÐäùÑ1@D¿}2+V–#·j”GP?ãÒÞÀ¼NV…ȆÁ"òÝ®‘5¿‰f¿ •"üÎX3±Ú(r;»/ SÈÜ¢€9¤Ðç¸Ô_ÌšêÕ!kÜ\ÛNÑHþ|‘I!”Ãd−xÆ)"ðýðšÒðÜ%½Í’−à…‰öó+32™¹’EàôÆKdŠé¨ NßÃ×^‘j„I}$Z_ÙZÝçyNQTÃpªÙe9´ü 6lx®çœfºJÀñ§ü{iîÉÿ¡Rr4QE0 (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€

Client Side 455 How to Develop a J2EE−Compliant Web Service (endpoint + client)

(¢€ (¢€ (¢€=6Š( -ÿÕ·?òÒNùþ3I>KÀ—8>ûóÿ>”°«n¿ë¯ûÆ–PÛà qþë=»f€0¼I¤N;!q×–ÑL]ÖHÏ–Á]FrHb½3ô#5ÊØè×:‹$%ìËoy¾'‰ 4YIY@,Å@màŒuÀ±®«4Ã,bO,Èøù sÎqǾÖÿ¾O¥s·Z5Ö5X- Ø%1ˆeó¾ô åþãa8' (ùˆ¼Æì;•®º−úA¥lÒ[’H ]XÇnô£ës#)©Çn±Ã|mä{3–œ ¤Œewg• gv9Î+èZ£Úé"ê[ýðÚÚg{ÖÌ3ùWk+±ßÑ^H·zï 纣üæ€3t#s.•Õã9¸»ëJ— ç8æ’€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€â°AaÆG®ÄЇ¿µ)Ôáš[ IäóÀnÌó”P6Æ6ŸRs¹EQEQEQEQEQEwãOøöÒÿÝ“ÿB-þâ°|£$}p*^æÙ•y9o3$uP§¡Éï£!ŒC*G„DQ€ªéŠðr:ÿõê⬬Cww8XîuË[kH¬ŠÇ ’ÎcÄR,mûÅØLR8B¥¾\¡ÿhU»K]mfòÚØÜ,|Á»·/!+†ýÙk®êì;qHä€ÞÊzýHªËÉ{¬C%˜iîEÌð°àÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82A$¿,a™¦R}ÌÄúçXøÅEÞcœKlè¦HÍÙ5v3ùL−îdXÙŸ‡›îe{‚Ø^3‚Ê~îãU¡ðݲN°Iu™#+7ÜT,U@#Û‚xÎHÍX:\b+tm¶¶$ò±“#/ÜÉÏ@ß7NJ¯@ 袊(¢Š(¢Š(¢Š–Ûþ>cü•hÝké¶vâF÷kŸÈVu·ü}Gõ?ʹ¿ùÉa!lyC‘ô¤€ÖðgcñŒþ5Û´¨ŠK0õ¯’ü−-'V1\¦ý@ù°~ ú×±[kVZ¬j¯}c?8ÿvJ‚•¥:§áSsº¼ñ5íî Qœ¿ýj½¤ßÿjiñ^ˆŒi.J«u#7mIõÀ¯5¸Ñ5−Eou-)íÕ€Ak*±Ç?0äã%€ “JËIÔôËãsi¥¼sF*y×\g>Æ−EnÏC·ñ6Ÿu-É¥Eç™Ðºù_îÙ—ïÝÈéõÒ¨¿tT¿û6ùÙ+ˆþNN븮xÜ;ç×)¤økZÓ5è.—N,²#Ç—VXÐG*m”ç9ýà'çù&+Úëêvâ}9-Kç*p¸5>ÒvÕ,o¹ëC½:˜þ´úè (¢Š(¬Ÿkðx_Ã×zÍÔ2Í °RÉw°^2@ïTõßZèÚ”T6Wš«:y©ebÝcÜ{’B¢äõbtTW1¥xÒ íetmCLÔ4}FEg·†ù …P¥¼·RUÈ È#=+¢ûD@àÈ™'n7¾ŸZ–ŠË×uÈ4 *Kûˆ@"(ñ¾Y‚ª.p2Ip=p*−7Äúv¥áH|F’yv[}¥šB– eƒv`ƒÛŠÙ¢¸¹þ!(ûPðηg¤–]×òÇØѺ; rê:g+‘ÜW_ Äw$кI¨dtl†Aî1Þ€%¢¹·ñ®š4_ —íE™°´−RêõíåµD¶’qbØŠuLjm`)ä?•*”ØÐ(ÁgpyUPÊIÑ-I§¬P|’\òN¿êÛ òy§íÃw\$Š»k¤Cg©Þj;¼÷9Ü"ƒÎy(¡› ¹b£!p È‹ Å¿²åQ£Ý•hß‘Ô•u8îXqVj¦›fll#œIo‘Ø»¶;ÌdzV袊([oøúê•O®è˪è‘.2|¥þB ¶ÿ¨þ§ùWMh3eýs_ä) >\ñoƒîm.ÚX†ÉAëÐÉÒµi’o³ÌZ9—õ¯§¼Eáë}BÍÉŒnÅ|ãã/û2ïÎQ†‰Ç> šé¡UÂG+°zjz‡ÃkŸìï øŸUŒ#]§(Xg$!ضã]Ÿ¨ë ®YZ]êÜG0º%¶Â¯\î=Ȯ –Hdòíµ o³]7QÀ|’cÓ'Ÿjé.î−¦†«Cwer‡p1¬ «‚RXÆHF×÷ãÜsüë‘‘æ¶c ŠÑ²ÿ ã±Ü¸`wξÙ+Z'ÇK.{Ï_SÑàÖ.|5,Fk‡¼Ò%`¤±ËÁùêG±®î'TWBYr¤w¼^K÷:¢nbt;Ié‘]ÏÃ]vßTð´åêØ2$Œ#*õí÷Ïz߸ðw‡î¼@ºíÆi «:χ´ŸÚ‹m_M¶½ˆ6å %OtõJål£þÏŸÌó`çkobÏïÉbóCÇŒõ˜®ueÒ£—ÂÐÆoYˆTÍÙb9ÚÄ…8ìÆ«hº%•l´=oºe‰¾³•#:UÈ{KèÕUÏÇiÉ yÈî9¯SŸDÓ®ofšÔÙÊλ·ÀIú6‘ke,©±ä~b3œdçŒþx‚€äŒrØbÌ£å%ylw6^ðΜ۬ô;H1r—`F¸Tݵ€è1¹°:rjƯá= ^¼¶»Õ´‹[Éí¿Õ«sàïÝèÿØóé²iÞqmŠüˆä’Jáêßw“êjx|5£ÛÃwZmºÇy Asܬ±¢lU`z€¼}(‰}7KðçÄ(tß*ÚEw¥\Ë©X[ãÊ]DRþw8ÏÇ牧øoLÓ~xC]‚)°×:ký½¥c0S’qór;w¬]f}bëOÔc¶ÒµS,ðºÖÌKf Ò— ÏÍ–Eñ´f={NyÒÜÜlÝ‘celñ+E“ÇÊ ¡^qó½X®«c{s%½µÂÉ,cs(|¹Æá‘‚¤ä SOÄ;}¥ÿ}2J~Q€VîK>™¯ÐQhšMõüÒÝI±yÑGŠ(¢Š(¢Š(¢Š([oøúê•töñçýs_ä+˜¶ÿ¨þ§ùWOgÿp×5þB’ó.è˜Jù÷â‰ã Õsùúû×–üHÑÌ°´ª™æ˜šº«q}$qÉ34£¹àÞ1å\¨â©''Î÷FÄ’êW¶Óê2™™ }§$™W$‚x#Iöçšj3“…nÜdVŸ†/!’ÆâÎhѾÎ^uVêÊpͦÃÓûõ¥wmg£ÚÏ3Æ»¢Vq$üÄÊ€óîþÕÙÁû;X5U{noS‡Õ滳Ðn−ÍÓÊ$eQËR0IÆzœI5é?|ëõµ³ŠÊ(−Ö6}Á?9Œÿ®qÞ¼šþyµ‡–8Ip§2?lç}kè_´cK…t?÷É ÿJÊ´-c|−>iÅMë«;èiôÑÞ^qï…Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@eQþzÐVø¼“ Çñš¯qyÜÇóã—¶ò> F8‚=3øX·ÿVßõÒNùþ3þqÛ¥dj:KÜê–× ¸ùw~|[5 mÉo#Ë!•j— P8èHû¬ƒÔ+ÏAÔígÒâ †(¾Ë%ÓíM¥¡v`Í‘Ã0À\gøÍ«o -®›«]™f2Åb \%—Ùp2ÇåùÈǽnZ_Ùß«µÔ3„8c†Ú}:UŠÄðíý¨»›PDIf1…@ª¤* A¬Ã·÷‰úpÝQEQEQEQEKmÿQýOò®ÏþnÒÂãÊ"ŒÙ·oÍÁÆåõ®o鳋‘−ªŸ´Î—Ì ‘…pAÊ‘µpF:T á]"8LIlȹR…f4[s´#nÊ–)ŒsZóBÛü•o£1¥ñì"UŠ=>I%1ÄÅDÈØi™FWp+À˸u-ß_ͪøNÔn"X¥º·fD9Q¹Aãóÿ8¨áð¦‰o$/ „qùHˆ¨ŒÁPBîLíb7ûÖ…Ÿo§ZEij†8!]‘¡bÛW°’p:Ø:S'h‹‚©{Í–E−T…Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@zV6£ªOiâMOc0ß Ì¥Ü6 a·œO9¶gêÕ§5¼×+'o»É’)qµõ«Èå´œÅo$ðùŠA−$P‰˜cÓiÀ9ê: }Ï‹|X½û¤Út©†G#²¡#?/ï¾;gŠÐŸÂ:4ævkAæL®¬ÌÌã,›ö±#yQ‚ØÉÉäÒé~²Ólom\›¨ï¤/p'PÁò¡H#¾BòNI$’rjïO{Z-÷3Ä·Znºš6©Ï$°GÖ¨c\H’™Y˜ðan„ä0éƒN🊥ñ=ÍÛ 1mmàI/¹É3öèÇxÓ_ i´*Ê^Wy² —bXár¸'$t$TÚn¦èç:}²Ûþí"!Y°Us· HÎ2yÇÀ§ m¨Ôjsjô4±E.(¬µ58Ê(¢˜È Ï–ÙÏúÇê1üF î#.ÙòáT¶Ü©ëǺûò=ê{|ÛÞIÐcøÍcêdÓê¶×çU†ó툮 >Acâ9ôã½nBâxÑâmÈà2°èAèj©h–ÝâÄÍÉÏúÀÜtí·õªWZ−ÍÖ›i\C‘@#q2K ÎÕ/—,xèzîÏÎ]¯„n!–'Š ÃË´Kvû4—øÛËxy>å¿ñ'+«!«Xèn5‹Q1}‚Å»åOccðF O@ô5*j6Op¶ÿj‰eyG`¦GLoßÛ‘œt9T¯toõ†¼F1=™¶xøàüáXdc M(ϸÇ|çAáiḳ‘®Ä˜1½Ð2:†‘.ã ¾

Client Side 456 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ÈÀ#h’ÄlFýý®¤í'IznPÃrddFGxïRþFŠmF(Þ`àZ}˜¬Ÿ»A†óA#î7Luëš]W[‹N·¢Eºšä1·gDw,O2Ø8Ü8äT‰mµ»‹«#Áj¥…fY”«®åtuᔡö¡áéµÚ5ºkkèmZ$cH©¾=„ó);sÉÎÑ\ŸöuÅÍÅ¥••Å¶¡Öï//ìegœÞ¸çpb-(¸¾ä6Ó=ëU²²œCq1W*â6eI 3°F¤ƒË˜èEc¸ÜT 8$0À€rsŒŒƒÈÏ4¯tNضÈcX™Ëdm @9ôüç½3$«å€%Ü[’NæebG>@1õ昵¤êÁ^=„çï¸Ç©?w¨ë£ÔR‹IÛ8N™−’Ð’x$T†ýŒ¬íæY$àò íéé÷ZI¯šàJ jŒ:ƒìjÎõ[O%AË>ç'Øù¶J-´P3¼i‡¼ä’OÔhô¶o†0èò(Êv‘ׯþ@ÿh};U{yŹ # êC##?˜ç§ZSlÞ^íË¿hs pAÏN„¹æ¶7å`dÈsÄuÐû}=i¢ä„á™°!|õQ€>€ þéæþM’*.ÆwbXz ˜õãÜÐbØù"F‘•,ªs’#®0ƒÉüE0ÆÂ%ÕÎ:Ÿ¥XkòÂLdž“vì>–ûèO'é…ô¨|ÄhaGÜ 1åF~SÉüsüÅ8ÙÏœÏϳ¨þöÜã®3Æzg´Ÿeœ>ðXo^¹ÈÇ\ñSÿh‘7˜±ûøËpWÌó1õÝßÓµ6ÞøÛ´," å(PIÇñýrsn”‚UÌ)…÷##ßqÁç§Æ−—|Œ¹ã ¬á#(âA”äsÆh{Y‘ˆØN Çr:uÆr3ÓŠ_µ?—"$KöÂíÏâ qþ×°©Pf¸[)|Քȧ',[™ëÿë IÉ!Pc m9èÎ 8< T?Ê-‹óç3˜Ë|¡@g'§¯b9ë‰äÝÇ?:IÀþæV°%ð¶«%¤ŠÖ6û·…Ðlv¶¸œz#BwY‚©'pÚ;ügÚ‘ØF®ÒŠ€³ É'Ðb¹KíPmKɈ,ÓEp¢àLÊ® GAÜ6zàÕ¢ÚD¿Ùú…œ"„Þ$Ö‘–;/”ûrWs+ç‚rÅ°s‚«iwoÎxî"$€ñ6á‘ÔqR±Œîv¢Œ³çð¬+ûKEb¸¹Ò"’?´«ÜX»ÆÒ\Æ±È 9ÎÆò8RHœáW5|3|ÖÃíEnn™R ¦yK‰#û”ãÍ(äe¶©?t`-2ƶæáœBoóM¸Îsô©6‘Ø× qáÝa¢tµ³†Ô6%©Ù"«sjQ#,9À—@¬;ˆÑ¼Ðo™¯¤¶a×fãæb@:œCI\æ‘¢Mmye4ñlŠÞ;‘Qå3¼{@DùGʲtÈë“]KmÿQýOò¯5Ôä)yÿ_èF½*Ûþ>£úŸå^k©ÈNóþ¾$ëþñ¤·:âyVh--ü¡Çl ÄF;ûU{»µ›ËÁr6ç̵1:tÈïœU¯\Áe¯ÚÜ\È#…7îcœ £ÓÜŠ[}Eí|'qiÁyn—z)Áhü¶ŸLà~” Îòe?u'Ï÷>Só}=i R ™Ç™÷2§æéÓרü뼟[°y−·ji2Ç} ûäi ì H*O#…`¸¬«−xɬ—šúTz›Htiq˜ÈáF0»8Æ:ö gÉ—ÌùRy„gfÓœ})R4†5̃ª…vM«YÿlÅ Õœ(²t'Ï s !ÒÿkÇšDùvL9*¾_|¹éŠë©s`]@%sÈœ{àóì} tgdWRë÷€#+™ô®8é:¬s\È−g‘å†(D†äŸ‘'¹À JŒß#ÃüKÁ'%VšÏKÖ®OMI®”„܈î¶e…««U³4¯N§µu½¨ïï\Siþ¼Ý¡¼ü·úàp; hE½´p†‘‚®3#—b{’O|н¢Š(¢Š([oøúê•y®£ÿ!KÏúø“ÿB5éVßñõÔÿ*ó]KþBwŸõñ'þ„i *î_QFåþðüëºÔï¯4ý2 ‹K{y‡îÑÄÓ4xÞʃVÏ−ÏN•'ö£Åtl¥³K¨àY¦û*™pI%çœC‚Ü¿Þ—ÔWk‰m§ °ÚÝËrÓE¼B7pÁwòÊåÊs’Øìy⦃^´ºº¶‚šCqÊ(†ŒŒîìyÜŠà÷/¨üèܸÆáL×n¾$µå%™aäp×ñ ®¢ÖÇMºÚúM«µ§¡ÚFI௓¸bÅî\çp£rÿx~uÚŸY¬fY!¼H fXdòƒyñ‡D,Š¤±Á‘8 ˜`V¬¯¦ß]}Xå²%·›heeA ©eåYNA=}x rúÎËýáù×f,°"ñÇrÇ÷{;H$m¨@F8ÉþñR;€3RÝ1}FfFBÉ)(øÊür3ô$P¹¼?:7/÷‡ç]£ëse¬’\$ÉK-“º±\ȈFÒ>oïdí=úÊã]R÷N»µ‰”´…ŒecP3»vñ;W/òŸ—¡ åþðüèÜ¿Þv)âTYnÕœöÑÁ$éæ6Öó.¬¡I=úc=ùÃ.üSötYMº0›«·‘šµÄÐEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP¦ÑE¿ú¶ÿ®’wÏñŸóíDßë`ÿ®‡ø±ü−ùÿŸJ Ï–ÙÏúÇëþñ¥—>dÖàîµIÞ¢·Ï”Ýÿx㮌þ_NØÅC©ÿÇ‹g;|È÷c?wÌ\ôíŒçÛ5¡ Óu‹Ÿ³yٸǔ.Ï5|¼çýœc¾:󚱨GáýfÔ®4ûd»¸b¡¡´îÑÐIÏ$úà ТŠ(¢Š([oøúê•y®¥ÿ!;Ïúø“ÿB5éVßñõÔÿ*óMOþBW¿õÞOýÒ@vs½îœ–ÒÞƒ÷Nq*ç(ÊÝÏû8üi—i÷ßHÚŒho−ã·}“(Ú¨d {ù‡?A]ìS,:u»;dœrpú’jAp Íe.ª¨Õê»Ï¥G%ÂÆÑ«2©‘¶¨' ÀõàøRúÄ;…0¾Ò4ëئûa#œå²b| N[hl…aٺ⪵¦ux£[´ r.\ý¦Œ|-‡ý°Ý8ÆÝÚ½b{¸í ’yäH¢K;»U©$ðCcªÙjq´¶–÷q«mf·™dõÁ yýiûx:´Ól−-â€ê°ƒcs¦ 5Ô1y2[‚D,V7ì¹È þ×SÇ ¯X2t¦−Ài^0Ê]@%Aäœgò?•X‡p±æËef·“\ eAgšHÔµêþaô£Ì>”}bÂÇœ$vñ½×—-"C;JëhˆG‘˱ÉÎï˜$zbäv–»µ‚ò)äwóÆ^Xº“…^ƒØW©ù‡ÒçÒ¬C¸Xó[ëm;RXš]B8Ý−Û*|¬Í‡ÁêU¡BÈ=Áiú}-ÇÚ4ýV+I~ï’*'• {0Ç‘‹xÎO9Ï-zw˜}(ó¥X‡p±æVÚn“gf−!ÔB³ZJ ̤³ˆ‚.{‚!\ýOµWƒG±¶8àÖÕ(àäÆv¼Cj¹õã œæ½WÌ>”y‡Ò¬C¸Xó{ m>ƱO¸XämþévÍcåO*Ç—ý“yE }o´.$ÀÈn3¹H=ºTgÂí+MÒoôáríÒÆ©$v¶ðIƒÆÛ£K°`§çÜ'=¶óéFóéGÖ!Ü,r7¿þßah’øY•»Oÿ%˜ Yÿ€ËµJã=Ï€t©¯ü=q Io‰Š(SM”(’’ÁY‡?{¼×O¼úQ¼úQõˆw —ü+-−|aÿ N©#Oö™"kH$−.1¸JèdAÀ8VqŒšÆñÃÙÇ‚tO èòI)µ¹1½ÜÅAÞPë1+‘¸”‘—ŸB}èÛÏ¥1!Çæ*“€€+‚ÚßÝoʽëµ/˜}(úÅ>ácÁ6·÷[ò£ku¿*÷¿0úQæJ>±ácÁ6·÷[ò£ku¿*÷¿0úQæJ>±ácÁ6·÷[ò£ku¿*÷¿0úQæJ>±ácÁ6·÷[ò£ktþUï~aô£Ì>”}bÂÇ‚moîŸÊ-ýÓùW½ù‡Ò0úQõˆw µ¿º*6·÷Oå^÷æJ”}bÂÇ‚moîŸÊ-ýÓùW½ù‡Ò0úQõˆw µ¿º*6·÷Oå^÷æJ”}bÂÇ‚moîŸÊ-ýÓùW½ù‡Ò0úQõˆw µ¿º*6·÷Oå^÷æJ”}bÂÇ‚moîŸÊ-ýÓùW½ù‡Ò0úQõˆw µ¿º*6·÷Oå^÷æJḸ´¬wÅHêúÒW=££KìVöи0u«EÆ_øÄ¿¼pá[§$ 6÷šºÞiiy™$U¬Q0ëbaÁù6“ \ Å‚ ÓÒq\-…þ®¡%ºkÖD6íx-hvçÌF€k‹èã0Zä−¨¡æo5”,X"¯Ëƒîæ€:ú+›ŠëZoA ù‹g„Üö]éää’eU¼Þ?ÖŒ@CÃ’€ (¢€ (¢€ (¢€%¶ÿ¨þ§ùWšjò½ÿ®òÿèF½.Ûþ>£úŸå^i©ÿÈJ÷þ»Ëÿ¡HY×,Tð¬Vkn—"F¶ß à«

Client Side 457 How to Develop a J2EE−Compliant Web Service (endpoint + client)

’2àƒÁAã¿JçgÑuÈu72Cwya¶ÚÞè$÷p ºÀ,YNõia,K.í¤ääŠî-¥¾çšÿ!Sl•Œá7+¡œ¼úv©?„t‹[‘öJt÷ºmÖx^VÉÀ?uϾ8ôª¾•-Éýªö©q#\j1TÝ8D€[ Ê¢ËfìÊy−†À·Ø=(Ø=*)®Ã¹ÀiºO‰·[]^Ë|·O2$ÿékµb:r«¹(Ú@觑œm'0˦ø˜øeíᵟínãýiÅ°ýÚô]‚‚Ÿ³Ÿ« ¹.ÁéFÁéGÕd"¢¥Ø=(Ø=(ú¬‚äTT»¥¥U\ŠŠ—`ô£`ô£ê² ‘QRì”l”}VAr**]ƒÒƒÒªÈ.EEK°zQ°zQõiw ‘QRì”l”}Z]ÂäTT»¥¥V—p¹.ÁéFÁéGÕ¥Ü.EEK°zQ°zQõiw ‘QRì”l”}Z]ÂäTT»¥¥V—p¹.ÁéFÁéGÕ¥Ü.EEK°zQ°zQõiw ‘QRì”l”}Z]ÂäTT»¥¥V—p¹.ÁéFÁéGÕ¥Ü.EEK°zQ°zQõiw ‘QRì”l”}Z]Ø~ð¯'ñÏü×îÇÿ õÍ W‘øçþFë¿÷cÿÐtQ¦à¬ÄÙÎÑE°M¢Š E|¶ÎÖ?_÷,¹ó ëþ°çþëR[ñ`ûÉ: ¢ly°tÿX{gøòúмGéQÀÌä$r7¾qRUhšEG áæ9;yÞ}ŸÆ€2$Ѽ?¡ÁåÔϽªìFº½Æ«å´ap̓òP9=p*΃e¢Å·ú3G2^íi.Vc1—h‚ēÀ8µfërè·ú¥¬§Æ«ÚGi€QFhÍQš3@fŒÐE£4QFhÍQš3@µ#‹dÿ®ðÿèÅ®_jöš¥Ä¯q3[EªÜ[í‘a˜£‰Ÿ` oóxãÓƒœœç®isG°Õ9ëy›Ä—š~«a¤HéîVºÊªT3þ`Pœ` ç9‰-ÿÈgÅöNßôçmUC×Bï{áÖrP–:’J¡ÏÚ„’G§jÒд»½9µ¯¯!¹¹¾ºÐ[˜Qqq€»‘ƒœõ52iìi%»5è£4f¤°¢ŒÑš(£4f€ (Í Š3Fh¢ŒÑš(£4f€ (Í Š3Fh¢ŒÑš(£4f€ (Í Š3Fh¢ŒÑš(£4f€ (Í Š3Fh¢ŒÑš(£4f€ (Í Š3Fh¢ŒÑš(£4f€ (Í ¼‡Ç?ò7Ýÿ»þ€+׳^CãŸù®ÿÝÿ@ÎÑEé´QEEoþ-¿ë¤óüf‰¿ÖÁÿ]| ~çÒˆ3å¶sþ±úÿ¼ieÏ™_õ‡8Ç÷Z€$¨-ÿÕ·ýt~ùþ3RÔ™( •‰v ‚Øã¸íÿ]W¸·‚–ââía‰rîòGUI%“ õeÀÁpxÁÈü;Wqq?Š£MBÝŽ¿ú‹/! IdŒ4r7˜Á\¨#ƒ€76 `.ˆ—Z}¿ˆ“ki² (î?%l¦9N#Œ°Ã2«Ÿñós•:Ôgu+öê\¡Qn´;l“œœúýiK±êÄþ5Åv[ Gû,Ë"5Ìqy†õob€äbÂiðNcU*Ρw)−ƒlø†üÚ^ÌËi ÌK2Ù]ÙŒ)!`AåNœì?6x-H:’ÌAËäÿß?xþuÇê^%¸tÕŸ=”¶¶Ö·ó,±±b +µÕ†é›$z `ÔÚn-©ÿjɧ¼°ÝÔ.Qe‘äG²oVùðˆ‚ôÇš¹PR ŒœR–cÜþt”PÔæŠ( Š( Š( m¿ãê?©þUæº:¥çý|Iÿ¡ô«oøúê•y®£ÿ!KÏúø“ÿB4wWPÕo€.Ö—û{Xÿ -÷þ?øÖ}ÀÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿAkïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãGöö±ÿA[ïüñ¬ú(Cû{Xÿ -÷þ?øÑý½¬ÐVûÿük>ŠÐþÞÖ?è+}ÿþ4okô¾ÿÀ‡ÿÏ¢€4?·µú ßàCÿÛÚÇýo¿ð!ÿƳè íícþ‚·ßøÿãTç¸êc5ÄÒM)‘‹ÌÔtPEP¦ÑE¿·~òNØþ3þ}è˜~úÃÛ?Âß—ùõ¢ßý[×I;çøÍg\\ÜöVä¢L ½¿˜äRKñ÷Ïåí@Ýǽ©½+R–KÏÞ‚|»‹¤Oø“ß$äêwI©j−£5¼VZt7)¬{$vkŒïÜ¥ˆ"$~NïÅ7¶ßÚOö io3áÁQæGnŒµ„aì¬häÞì궨]»Wií /RO~æ¹i¼Ew ìˆÆÚO!`2tÞ"¾·w·{Xd˜4ˆ²¢°Œ˜K4¥¹%FÀ»FOÌpHÅb:` öÏ"p. )™T sÔA }v®¥`[뺉¸na³Ù¾$)œœËuËOñg¢c˜tÿjzŒvIµ¼3ÞËÆó«*¢ *Ç" ¹!ÝÎ@ à“‘µUá•‚•“ýcŸ–#ïŸAÏõëT¤Ò²d¸¦îÂM>Îâê;©l-¥¹‹\Ï ³¦FŒŒi·Ze•Ú\¬ö±–º-¦.Ù@án|ºƒ 1À_,.æ¸F{ã¶î© −Qyí¤‡ì^mı V,ìÈ£rår‡ººÒ”−(9.‚r´¹NŒZÛ(¶ðªãjÆÃœ¸Æ?ˆò}{ÔK§Y¡ƒe¼h°FÑÅ.ÔEldsO_S\Ü>+½ŠÀ ‹5–ò¶Ú°ªIò£¦ã”‘qà{r,j$¹†DGk~H¸HgEäC|¨ò íGýGjl6–¶ã[Aó ¿»‰Wç#øxŒŒõæ³,õ‰n¯¥¶[u)

Client Side 458 How to Develop a J2EE−Compliant Web Service (endpoint + client)

³ d’P ¨¸$Ú6€ßêNsŒ>ñÍbÝø¾ñà/mm‹¼¿;áã6³Ì› Ä2tà Ÿ—8뢶·™¡‚(Ù•P”@¤ªŒ(8ìv©k½ñ,–iy/ØVHaYÄdO‡‘âPX· pO¸§\ø†æÙ\I§Æ ;–¹Š0ªë m“ï0T]-–nà ú+Ä:•å˜š+6(ðÛ5Ãfb\Fªp:±ç¾ÞÙªš–±©iZba/ä»y]”]Ù«¾ÄŒ·Ý· X*î# 3r0 u4W'ý³>¯ ·’ìÛµìP@¦~ÎQ¢Ø3gÌ µœS´ çý*æ[«g ͲÁ#(ÀfÙ cßnhíQ@ÛÇÔSü«Íuù ^×ÄŸú¯J¶ÿ¨þ§ùWšê?ò¼ÿ¯‰?ô#I^Š(¦EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP¦ÑE¿ú¶éþ²Nùþ3Dßë`ÿ®‡¾?…¿Ïÿªˆ?Õ¶sþ±úÿ¼ieÏ™_õ‡8Ç÷Z€$¨í‘ÚWïŸã5%WxãFûHw´G¢éÉ%Ô¦Ò'’跜 rTœtöª/ªÝ[躵ÓÌ%¸¶·–hV]:[LìB~ìŒK ã$ŒÞ ƒ]¼m}m ßÉhª,eP¡cw ç–(ÇäÆÐäúVfÆçØ,üèçû$llì匩rYÈ>¤’O©$Õì−'Êh—gå³neòF à ýpî>ŒGzÅ»ñ]ž-s§,™Rµ¶qåKÄó÷†$Æ8û¾‡7WÄ{Ôí²;¥)öPeâ@òùJXãäù½7qùP“iv|Ó=•»I:yr¹Œe×ÐúŠ'Ó,.›uÅ•¼-æùÙxÁ;ðﮀ¬Í?ÄMqnmY%ÀŒ ·Î»’ÝAÁ#+å‚pHsëüûИk_µÿíãy¡O¦Å× š6Ãdl)ÎTàœŒäû×aá? ¶‡£Íet"q0ýâ‚X>ì—−%` NI«>»«Ý[h³Ã`£í’E)·´¹c+£ÀòÜñ*á$†ãoCVtý|§†5BVk©,áë åS!rÖRŒ„eˆÛw Ó™Î½í§·ßÔÁS„ÉýÛ\€FO?3xæ9t+ˆãIÚîSÛ,w!˜a»vpTcéTíüO †›ìr¤;I¦Ýý¥ »mXË@®N8ÞÖKháa Ì“•óè!Sí ö6‚ÊÜ¡“Ì‘Ý¥–B1½Ø’N;Àdà2z›5‰aâ[[Ëk)dŠXMżR¹Æä‰Þ;Ë'©;9ÎÜïÅ>ËÄ0^^ ¼ðîtXŒ‹‚û£isé¨pA9Î89Àí¯ü}Gõ?ʼ×Qÿ¥çý|Iÿ¡í4_ZêñF—ÌCÖDû4S–#øp?ô#I^Š(¦EPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEPEP¦ÑE¿ú¶éþ²N‡?Æh›ým¿Oõ‡¿û þýTAþ-³Ÿõ×ýãK.|Ø1Ÿõ‡8ÿu¨NôÕ−à´i×$í÷ÍfëÚ忇ìVæâ)¥.Å#HשÁ$±µ·lSÝ+ `}ÊZÝ#,QS+‚{}ðÄç’p0EáÛHm Írl M¹K«DÌèãåÛÌN ñÆ8©Æ·§Ÿ7÷Ò«00HÍ· >_™¾t[,£ PºÕƒù[d˜™ E´™ °ùƒoîðÀ¯ÏAÔÐí#Õý ¾hP,sعÉÚÆí§ ·4Ëiwi2Ïo½æ’G–\$‚@ÊÈ\ Ûv¶Ð3Â…«VŠÂºð¥•õµÄ7·7—−q#¼Ó;F÷F‘‘ò P6Æœ€c® [Ã6ó}¼\ÜÜ:Ý°ªÀ„ŠŠä›Ýï·9'rŠÉ_Ù,×å²åæ‰Xä('s¨'q8ä.ÐqSÞhöw÷Ý\£ÝÀ`}ÜíöíV.õeµ»{u²»¸1D“Nð* 32© °fÉGáC—§"Úµ‚=Â5ʆ·Ï˜0y …!xùÈb…É @;Šú[D8 ómIJùlò2».åUP™n\¯LmfNI=Gk“xyàÔ’Âk¯·™"y/®í¶‰ð0RŠp¬…¡¸9 ÕøGn ãí‘fbÆë÷G× ?Éóqó1çŒwÍi¦µa.™>¤·9´·Wy‘Œ ËnR7ÆHè)—æjû$¸,þ\R†'•™dm±w@Æ*w¾¢µŒ»ÿ Ïu¦-”7âÞ…[rN3Š–ëÃ?i¶ºˆ\F-ÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82Ü`äöãkêL¯m ðXè2ÝIièˆH“ÉU‰ Wæç¡Îqô#¾êËÃVWfÚ{FYµ•ÊÃ;¤hÅ”3º‚¨ FåˆèOJ䡽ŸQ“É·KnŒ!AuhÛ Ÿ®ð£nÝÝsíÏI$²²ÉÖ›,¨‡ânåäÖ¬mcŸZuRVH‰ óooæ"yŒqʯ÷ˆÝÀ÷¥BÐfuH- v`J„˜’@m¤zàûñY÷Þ¸¹úÞ7¶X¦Šq¤äÉoä„e €«÷³“›G5f †½¸šÝlàÞ4À›pàDl¸B¼Îí™ G|šÄêšO‡$XÚ8 ‘% RD‘™Þ¿0l~´çѼ?œ—oÙ£F‘æ±P«Ç ôúʾ–Öò;‹‹v{†˜íg2 1…'bîÇ”Ù;FAéÔV-Γ2éÚŒvëg»KÈ!O”0£q=qil|Ép‹¬pxñS“Å`Âá¿úCÿ}7øÑÿG†ÿèýôßãZæþÔ_ ´CöÃœ−üÁæyyÆý½v䙫äPü!ÿ T?÷Óð„xoþPÿßMþ5µou Ô~dÇ,ye߆RAÁB*lÐ?ÿG†ÿèýôßãGü!ÿ T?÷ÓmOu °VXãVuE.ÁAf8UêI ÜÓc¾µšî{H®a{›p¦hV@^ À•Ü½F@8Ï\P?ü!ÿ T?÷Óð„xoþPÿßMþ5ÐfŒÐ?ÿG†ÿèýôßãGü!ÿ T?÷ÓtæŠçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¢ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¢ÿ¾›ühÿ„'ßô ‹þúoñ®‚Šçÿáðßý¢ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šçÿáðßý¡ÿ¾›ühÿ„#Ãô ‡þúoñ®‚Šã)’:D…ätDYÛ}I§Õkä‘íq“ºË…R!dV8Éèlï ¼%"»†i»ˆƒéߧ=h²½¶Ô−£¸´•e†DWVQÁ 2?ýUBÎ Ót-−Σ"¬R šçìÙRY8Qü'9ëÍsþ"‹[Ò律HÒÚm:úA;µšæHÛ ²£“¸€Ù[8Æjá'fgVrŠæJçk,‰ O,®±ÆŠ]Ý΀2I>˜¨l¯-µv´É´á†ÆVÆU€#ëZÀÑìµ94=VÊþÜ«Ê-¡Ý…(ÊcÀݱA=@9ú†÷@Ô5 =³ eûJJmæ;†‘V9 òÆêÃs«Ê@Ù‘‚A QIÙœœ¢›V:í-Œàâ-ÇÊ}¸®HøJ_*f/ÚÝâ‹í,æG’ßì±Á f dåYú|ÅÏÿÂ#3]_³ò®.ƒ‘æ Y"ûZLÛrR4(¥Ý±’ñ%l’ÇÏ1ÂnuEÏv'~x¨m¯ínî%··d–"w*ƒëƒŒ@#ŒàñU/−o%¼µ†(-–Æ¡™X¬[n+· á@Æ1ÏZɛ÷·$:[ˆDv:{Y@æCûü¢¦âù8NÙëÙ –{˜m K½f−äy®%f„…È”H'=¶ýÓ“ò„áJš«?†g¹»¹f†ÝR[†’YUð÷HבN»ð3˜âFEÉ8ÝÆu›['å1,{xäþkY•±£¬O÷$þkHø‹áIYXåjú×UÑ Ô euÍáþ9ðZ[ýÙ)Ï>•-:

Client Side 459 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ƵÕVf™nþl@BË' XbØ àƒ8æ¹Oø¡lÌ“Y¿˜å>Ï œ±£ ÷Á¯ÓúÖ" =7=‰Z…)93¤ñŒ´m:õZ;.µ,|å)e÷−+5™v¹û2;:úÀç ® N]’››†ß;Ä·95³ý©.x WÔÒÂÆ1Õj|~'3œå£²;ÛYµ µÞÛ+øÊí$ …}P=:+¤ÒΉ®éJ`²¶k`ÜÀð¯î߸+ y•¯OÃ梵|=«%â·ÂÁ¨©VNŸ0RÀøcñ¬ka´nÇNyÆ7ºzjz|PÇK(±Æ¼* ÀØTÔÀiõÂ{¡EŒ3@ŸÄî>ø‹þ¼ŸùVDvV^%ø·«Å¬$7Qè––¿aµ“æTi7;Ë´œÈQœtÛSj_$¼½Õ"·ñÕ¦‰«ÏöGMHQ¼Ùw•”üÈ*äsÐö8Þ!ð“júŒ¾ªÝiÌù+w¯íÛ$¸uÎHŸÂ€27 “Ñê埄ÖÓNñ˜¼gÝÕÅË9ý¨yÆÜö CÆ~(³Ôß#Á%¬fáâ=PÏ÷²znÇJê.4‘ÿäºFœëb¿d6¶î±‡ ›T…ð.£Fhín•dYö¸%[~N™cǵ5/ëšafdS+ì\°È · íÅnKðöOøF,ô‹}vx§Óõ3©Y^¼ #«–f"U'l‡2IÈÙüo‡°êj“jšŒ÷7:„VcÏ…C=º°Y©ÀbÍ»ÀéÈ ìo|Cáÿ麯«®µk«A+Ãpöé°I‚Ãj(R¤0ÇpsøàiÚçŒÓÁ:/Œ/5ÛyQÚÙfÓÖÍ6M²,[™À ²e÷|¸Q´ Ië4O]ÚkI¬ëºäÚÞ¥FY‚;to¼V58ÜÝÛ®©à ¾°ð·ÛÛ¿gÿIò¹o*T“îçŒìÇSŒ÷ ³RÒÍ−QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEq”QEEoþ©¿ë¤±ügüç¿ZWb¯ˆœ ¹˜À›6nn¥£¸µËE¡ß‹é.X²\ÆÖä\}Ôû|ò>Ïè;œ£©Y©vÏáRi™ßlÓyŒKª9ç‚GP02Õ~_•Q@Q@Q@Q@Q@lhßëýÉ?šÖ=lhßëýÉ?šÒlô®7ÇvK>ší·'ùWeXþ!µûN›"CL•þ×.‘âÿ´DÅu ã‘Å{N©Øëyè–Òy˜7W ×aüCû-î+ÆümböZˆ¸ƒJ“GÕåVH€zŠî£V¬ó12•œëcØõC§ÙÀM·†ØÊzy“PmÄÒ¼þö «Ûãqt ¸û±'Í´~Ò£>(¹tÚò?J‹Fñ éÚ¤º« “QºëZÒÃÆ–©•ñ¬¬Þ…‹−V+wšÂmµŸ©–Õá½½*Y1qòƒˆß†ü†=ˆºK½ 2Ûãb§i,dçnìd{†¿−jê{9kÔãxW^ “¡Š·×V—1Ékn'eä«®å9 àç»ñÅV·½mGÇE̶ööÌ’*Ã=Á+G\[m!#…[tœ»9È †eÓyôª?ãÞ$¿’E=¿Ã53•õER¢áîõ]}O{ðΡ6£¦’9¶ÆÞZM2•i€þµÆ–â1xs6˜÷âû>VR8ß¹Áè` zãi†âÖCFMIÊI${â„JÕc™™q’éÀÉ8ö¬›±áë¸ûG‚àCm¼©äXP€–àK’p Àôõ¥Ô−g‘tˆš+ 1Ç“ýšnœ−¦sÙèvÈò0`wq!sÓ9íE£mõu9-m ”QEA±¾ LF1æIœÿQ/Û‚F|ÃŒ“ýÇüÿýtAŸ−³ŸõÔçø`j/rºÌB#naûX>tÈãh·íéÎ{c$m]é¶wï]Z¤ÍB3uPØÈ]«ù ÏHðõò4qÙÛL³. dÄùKf Îm”¹òVÜq»|ñ`“›³ßÅ‹¦VÆtþÊ]ZéŸíÚb)EÜ6®÷¶Èê7û‘Þ\¬ì4çæcNy ¼‚Es:®w}¬\ÃîìçŒ]ùˆÿJXÌK“ß%€ìbÜ0AÍKe×R²•£š$»¸[§ ’u{‡i@U+”¸Œvn`j„v%˜ ¤Ÿ¥Y:©_ÃÍøB;ëmÜ%âC+½nWhY7· ÛnͧŒãøðÕ›¤x~óLðŋ©i{$60Ê–bÞES$^kK’ÛäUÞ ``ã;bKœ“I\uô:…ËÊ’MáðIpdÀT¾‰ 1`|߸“yyä ØlfE“W1Mæ@b…c|«y§Ìò@a³ê²=9 ´sz;×+¨.«$×íÔ7Q 1µ¹´ß>ßxÇü%:ïýn?1þÂS®ÿÐVãóáLgÉöüé’D²Œ8¼oþwþ‚·˜ÿ ?á)׿è+qùŠö%‚4T\Pmâe¿^$=Fqò7å×úw¢ßScë$èsümX×wÔåC−© 2ä\jÒZ”_.>UUX7WçLšÕ¾Ô−4ËWº½ºÞ—vÆp ÀI $únŸ©Ùj¶¿iÓ‡vÒÈsµ±¬:«r8 EsšÄƦêvˆ×ke#ˆÒ}®ìðñ(ÈÆõ+òõûç¿\f¼Ñ®#Ö¬çy¯¤´S#,‘ꀮ F ®œüÛ¹*KðsV£ury¬ìzf €qô¤ü+˜ñxÖ•„rÊþDb>w|ùR)Â> îÜ1€˜î−}â¾ÔfòÐ]ˆK˜ÐÝƈÀ”`Â]›/!=FÌPQ×c¾ ÇzN=«’¹¸ñl6#ÜMi4ÑD>{‹k—ÎÐÝ›pv71QÎE>þÿWC§®›{,ð¸ßÜÀc2°u ¬«q‚ÝYÇÞÕþ'ëEbi·W¯®ê\M,+9Œy[R0 9H%z|òÚ[1ð§n€ ?_¯4Q@Q@Q@Q@Q@dx»þEë_úú?ú -zÈñwü‹Ö¿õôôHr(¥öEÈØÎI?¥5ÃFÅ]J°8 AôǯµKlc"xä‘SÌhf¼§°' 5n¨•YÆ`v*Oš€±eò£wœt¦niT`«óp䟥hEyùAŠíS?»å ûÎÝÈÇ©úRÁqj–ЬŒY•Ôí+ »Œ{ûçœã¥fæ±øù‘¸qÛ×éÁæ¬Ïp²ÛR7(„dv5¹)Óåù6¨ö àcús@³Fséù֔׃+Dà¹åŸqK‡f1¡\ ƒÓÓßðÇ4œ ±Ú ±ô€`x|m ÏÈǧ8íšÍÕ−Åô¬mä6éæ³+)eeSÐ|¤vǨã¥YŠgb"ŠI!¶áQç¶jÍ«Æ#t•¢9eßÚHÏ?'!¾n;r}ªÚÝÚì9#̃‚Xþóvâ1Œíã9öÆ9 ¼ÑšÑ†öѵ§UágPBÂXyÈ!rwŸ×¿^ôë»»}>Õîon#¶·_½$®Gâhµ»·¾µæÒâ9à’Dᔃî+Í®¯£˜$š–•¨;•,ÈΡ„ªÅqÀ!ø觧ñVþŒ/´Ý7WÕd¶™á!öò¢Â÷ÞùŒ£"3+² …ÆO|»ÙõÂË-êúM¿Ø'¸)yoÔ¡®#½ÑS@¹RBnghº±b€ 3®,ê:ÍóbÞ+°LBåc(ð*0û‡'q,7—+¼-£±Íçüþb¹Û=NêMU-åœE–äÄHnqsp¤.Oxg—íïˆõô÷•/eŒA$›hO8›;— òãw+ä½8ôJ3\¦¡®ßÁs©¤3De….?ÑÚ0Æ›|¹}â$óÁíWÞçP:f¡•äÖñ`i¢ÐîŒÈáF~`ŒøÀ?tc'¨åÍ=ý½½œ−c¬´z\·b95)æÅùnĬò–f›h9 O«ëw²I+G”yÝ *ð;iÿh'$ç+ Úç98Àd9éEp—^#½Úh ¹’èeI ” 2Ú™@Èw|ÄpÙ€ÛyRF•Ö³ªÛÉT¤ËþåF°…ò„)’sÏÊä’p¸QèÄ€u4W;£jz…ýÕ’Éq[´3ÊÌŠ¯çuT!Ôíþ"~\ƒ;×E@Q@dx»þEë_úú?ú -zÈñwü‹Ö¿õôôIÄUY/Ѳ{³k –ímØÃdåYýˆ9 ;‘ZöA!•î"ÔeTÆO´k‰ Ïu^vûý=jµõ•¦‚–m–¹ÞLÖi6-§½´i»Ëã+µßæ8^7u'åTmÔNýí%¶€KgÇ9©ZÒé³ZΪI1°~UìË…™| ¡ÁÈÇCŸ_z鮵 é´− $½ºu¸’t˜5Ã~õw¨Ãsó

Client Side 460 How to Develop a J2EE−Compliant Web Service (endpoint + client)

õ¤3š¢»,,nuZ8´ˆþÏe'•…2ÌÃça‹‚ÄãÔ½6{ïOº2)üÍUíA–Fùcù1ÐŒŸ›Œú÷ÍrWkm¡Y›[´M4ÈñÏtåÞ*$RUÇG_˜úUc£ÚÿÂ*n^Ä$ßbtFÜI_˜Èp™9'`±ÏÉ€K`Iè¥(ÁŠ-œ1uÅvðXÅaâ[‹EÚÇv‘ÅzÒ’' èÄýì0j¼VÜŦ ‹@—’%•Ð;¡R±€Ç#=N98 >Šê¤°°€Ks>˜#”i¢áìšV)™ZìðÍc−¼ ÝYG;Æ„•V%Æ{|¢€2¨¢Š(¢Š(¢Š(¢Š(QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzmQ@[ãÊlcýd¨›m¾qþ°ã'ÀÔAŸ−³ŸõÔçøç̃ÿXsƒáj–¢¶?»b1þ¶N‡?Æi—Ï$vÙ‰Š»Ie@'æ‘TãØlKŒ£ÉÇÊ*|Ùý(×dúŸ¦iw7÷çX+rZ™gÔÞá.Ö−G"XˆSŸ/«g−óô\g¢hÇâ=Fp«Ó̲ÉPcb−¼ÉLe$ÃüÌÏðý;ÐW¸ãô£ñ®4x‹P[‹‡k›U‰Ô•AfI%¯ˆõ øí$µ‘5ÜqH|åy´óˆ0ÉÎQÇê×î;·n9õÍ›NŒ¹ÏØÅÀoõ¡Ùw„ÀêwŒ®¾ˆ…ÁŒÍŸË.}rxõïè(BÄ÷=sÖ“'ÔÑE)$õ$þ4”Q@Q@dx»þEë_úú?ú -zÈñwü‹Ö¿õôôIŤ;×=v±¤gwÆù€9˜œÆµ¼=§Ûj7S%Ê €Œ1^sŠÐ¶¶ðíÕÔ¶ñA|²CÌuµÌJœg—t 8ç¯=¨°Å)f*ª]¶®vŒôúW_ý y‘'™ùXˆ×íôå´WªEàÿ ÌшHd]èíõày}ëÊÏSõ Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( M¢Š(+õMÿ]$íã?ç=úÑ/úØ?ë¡íŸáoËüúÑo)±õ’t9þ6¢ly¶ùÇúÃŒœP¤9£1ËHÕCõ-AekmnÆhm MλҧnóǸ\S¯¥’bñ¼i’»¾óª;ðMd躴·-Ÿ.àE¾é =³#—`™Í]«6J¬¦ìÌ[£€Ü3ëõ篹¥FºÆŠç«ÍÉÏâ=BÒ3s(/o ’ú0¨-´i;ì$‚"8T·82œù¼CªG")¥®D‘Κ#‚9¸C— †aŒnF’«bïµw€qÐz}(‹¨£'q rO¯Ö³.®'º¼Ó-`¹’Ê;«yn Ѫ3VoV^C¹õ§ÿ €?çóPÿ¾®¿ÆøLKMEº·¸ÓI¶Œ¼e³Gù—Þ:ÄíñN¢HÆï‘Xz…ï-lôÈã)f,d²«ÀfÁöÞóˆãnNºø¯áÚLó−Åð‘À àÝe±ÓÝËcÓlà ÀzÔš¦y5Ö¡$BÑÊÒ4Qo œ¥ ÍŸ¡ïZŸð˜xþ5ûêëüiá0ðüþj÷Õ×øÑì*ÿ+ûƒë4™}ætÚUôò2-’FâK¡1uà4.‚.r ~ïËÁé™õ[U²ð”6Éq–$Ù…PFãµYÿ„ÃÀ~Ù¨ßW_ãQÍ⯇sÆcš{ÙòUÑÎaWù_ÜY£üËï5|]á ÿx »]BóOH´ËˆæÎé¡u2€íå“å$œõÈꟼA§ènºu´FÓOûš|QF¶òɸ‰Þ)0_‚J…pBüÍÛ²ÿ…¥á#Öúü“ü(ÿ…¥á/ùþŸÿdÿ =…_åp¾³Gù—ÞTo j ã»mMìl/ Å0Ôngc=š¤3`Í—É;r͕αü1ðÒöÞmF×ZKXìçÓåÓçÖgiu6yKý¦\œ+¨8ÜrÍÎÜÑÿÂÒðüÿOÿ€²…ð´¼#ÿ?Óà,ŸüM¯ò¿¸>³Gù—ÞsàOê~ »“Sš/øI.®-¥»U‘|»¸-ÀTˆåY>o™¾deÜÜ®0tŸ†óÉsáŸí6 ¬,f¿šâÎæâ;„ŒÊbª¬h›w+p3ùt¿ð´¼%ÿ?Óÿà,ŸáGü−/ù~Ÿÿdÿ =…_åp}fó/¼Æøme#kúÌÁ¼Ë−*I4«7(Gœó7–3ò(WŠ2£‚#^xÀãOÞo-z_ü−/ÿÏôÿø 'øW=ý·ðÃ?vã'ý›Ÿñ£ØÔþV?¬Ñþe÷œ-Õm|/þíÇýósþ4m|/þíÇåsþ4{ŸÊþàúÍæ_yÊÑ]WößÂÿîÜß7?ãGö×ÃîÜß7?ãG±©ü¬>³Gù—Þr´WWýµðÃû·÷ÍÏøÒm|0þíÇýósþ4{ ¿ÊþàúÍæ_yÊÑ]Wö×ÃîÜß7?ãKýµðÃû·÷ÍÏøÑì*ÿ+ûƒë4™}ç)Eu_Û_ ?»qÿ|ÜÿÛ_ ?»qÿ|Üÿ¯ò¿¸>³Gù—Þr´WWýµðÃû·÷ÍÏøÒm|0þíÇýósþ4{ ¿ÊþàúÍæ_yÊÑ]Wö×ÃîÜß7?ãKýµðÃû·÷ÍÏøÑì*ÿ+ûƒë4™}ç)Eu_Û_ ?»qÿ|ÜÿÛ_ ?»qÿ|Üÿ¯ò¿¸>³Gù—Þr´WWýµðÃû·÷ÍÏøÒm|0þíÇýósþ4{ ¿ÊþàúÍæ_yÊÑ]Wö×ÃîÜß7?ãKýµðÃû·÷ÍÏøÑì*ÿ+ûƒë4™}ç)Eu_Û_ ?»qÿ|ÜÿÛ_ ?»qÿ|Üÿ¯ò¿¸>³Gù—Þr´WWýµðÃû·÷ÍÏøÒm|0þíÇýósþ4{ ¿ÊþàúÍæ_yÊÑ]WößÂÿîÜß7?ãGößÂÿîÜß7?ãG±©ü¬>³Gù—Þr´WUýµð¿û·÷ÍÏøÑýµð¿û·÷ÍÏøÒö5?•‡Öhÿ2ûÎVŠê¿¶¾ÿvãþù¹ÿ?¶¾ÿvãþù¹ÿ=Oåp}fó/¼åh®«ûká÷n?ñ£ûká÷n?ñ§ìj+¬Ñþe÷œ-Õm|0þíÇýósþ4m|0þíÇýósþ4{ŸÊþàúÍæ_yÊÑ]®•?ýkS‡N²†g¹›pEcp áKIÇ@kñ%¾Ÿâ+ÛKXü¸"e»‹cåSÔ’z“YÊ..ÍBqš¼]ÑÜÑEŠ"ƒ>[g?ë©Ïñ%Ï™3þ°çÂÔ[ÿªoúé'lÿ9ïÖ‰ÖÁÇü´=³ü−ùŸZtÑ$ñ˜äPÊH89êGOp* Kh£c2«t Î[ »§^Ÿ(÷ãÖŸy+Áo¾=»Ëƃr–sªô½;ÖV‡¬‹÷ÚßkÆõõkŵ{42è]ýÉÃœ g?5w%@ÂŒÀv®W–îoh—z¢ÿf½Hštšhííåi−^@®P+Þa›uõ £ê—:/Š"¶‘”iV),6ó‡−m7ÌP,Ÿ?’ ¦Ì€Èä jj¢æ¾Ú¢ ì‘ܬqÆѲFŠÑ.ÈʨŒè8^AU“IÓc´KDÓ¬ÖÙV·@ŠwÈ\`|À@=y¬A®^Ø›ß:+»Ÿ)á…c¹„G/™#`|±+’˜Ç!XçpÁÚ@¹½Éoû’_î—äÙ˜ôÛ“ŒtÉÆ3LM6Â8L)cj‘a‡–°¨R ñŒr ê}k>−~IµÅÓ×N˜Ç¸G$à;,narʆ=¸*¹ó7d—!Ú '±´ºÇÚ−−æÄ«8óbVýêŒ+ò>ðõc5*¢( Š( Š( ²`$Z¿ð«üPlÍ™× 6ŒÛŒ|ÞYlç%qŒçÚ/Ã?O剼C¾S+G¾âfØW;JäpFNé“ëÊX˜ÏÑ}]ÿϳ−D]+QÙjþrOj"ó«Ʋ!#pÛ‚¹'#Ç9±‚lï.µ#Þ+5ýÕ-¼‘D¾U¿•“ºl€xÀ\t'Ú´‡Ã?‰§”x†!,ãŸÚí¾Û“›‘ç͉?˜ä¹¥õˆ/ùzW°—üûüŒáÝ$èÂDøjE]T†ØbR½2s9ãúW'^—ÿ ³ÄÄÈrØ'ìÿë¥?ºÎ|¾Ÿw¯ÿÄÑÿ [ÿ Ÿù¿ÿG×ðßÎQÄ)ç”W¢ÂÖ±ÿ!;ó“ÿ‰¤ÿ…?-cþB:w·/ÿÄÑõü7ó ú#ùOàý+¾O†>*-ÙëGþb:þDÿâh?õ¡Œê:æÿüMÚoçAõGòyEzü)ýkþ‚:þDÿâhÿ…A¬ÿÐGOÿÈŸüMÚoçAõGòyEzü)ýh ÿhéÿ›ÿñ4§àö¶?´4ÿüÿ‰§õü7ó ú#ùO;¢½þþµœhéÙúÉÿÄÑÿ {Zÿ ù¿ÿKëøoçAõGòyEzü)ýhuÔtþ™ÿ–ŸüM𧵿úéß›ÿñ4ha¿ÔqÊyåè𧵿úéß›ÿñ4ÂÖÿè#§~oÿÄÑý¡†þtQÄ)ç”W¡ÿÂÖÿè#§~oÿÄÑÿ {[ÿ ù¿ÿGö†ùÐ}Gü§Q^‡ÿ {[ÿ ù¿ÿGü)íoþ‚:wæÿüMÚoçAõGòyÔœq]ìš‹ßh!l–#ªÝÇö´UìM…Ä*!Cn−†ŒÄ™Áýh CN9÷“ÿ‰«?ð¬|RûÃ=zŒÖ5q”'ðÔFôpµ¡ñBæN™á‹áûBtº¸M:òáF ìTëæóg§N9ÍPðý¬I¡ÝjI¢®-v—‘Zý÷2ÇKm^rH àgêKÂßÁo%¼ZôÁ…q•Ÿ•gõªVwªµ4ú½K¯Ýíèdi~µÔ§»Y“P¶c¨=Œ0Ŷ_²°BÛ¦nëÐqèyªqxZ9tå»èÇýs$ŠÁ$e®výÓ´q× t0|)ñ¬rÇo¬Ú“.ÉV9eQ"ú0 Èö5"|/ñLvŸd_…−H``YæCåÆ9ç× −/LÌ_ h+$+6¥#ÚÍ`·Ì\\mTœ‚AϦF3óW1â+{kO_ÛÙÁ4E;ªÇ620{`—ÓÛk¸…~qÎ1ÆzqŠmÏÂÞÌg»ÖmnULš¸j²£NÇ›Q^‡ÿ {[ÿ ù¿ÿGü)íkþ‚:wç'ÿ]ÚoçG7ÔqÊbü7ÿ’‡¤}eÿÑ2WIãùµ/÷×ÿ@ZÐðŸÃ]SAñE©s}e$VåË${÷ѲŒdÕ¿JÏñüÚ—ûëÿ −y¸ª°«Sšèö0§J—,ÕÎÊŠ(®s´ŠßScë$èsümDØómóõ‡þ¢

Client Side 461 How to Develop a J2EE−Compliant Web Service (endpoint + client)

ùmœÿ¬~§?Äh—>dÏúÃœ PÏwä© ðåNAÈ9@éPXÚÁ z «HƒtÎàOHÉ*2}E[ªÑÏhÂI!ÜòsÆó@Üþ»Ôô» #U½·›O¶‰"1ÃÆϲ‰H`sÕ·’qКÓÒô9m«ý£ÑæSÊ6ïù3È,p@îÿáÐ¿è ¦ÿà$áGü#:ýtßüü)©Y[”NŒ›nç ·Qû;jFÐjAÞÔÛ6Ákö©0Û¶î#nѳÊc·BŒ²yÌŒ¤c-’xé]çü#ýtïüÿ‰¥ÿ„gBÿ e¤×–Ö“Ýi‹gÔÐÆ4O!·Uÿ{!ubY¿ˆNB‚À䊱_øT›H:ŒWÈâÑÚ8-™2¦*2òF21ÆÆO{ÿÎ…ÿ@]7ÿ#ÿ ?áÐ¿è ¦ÿà$áB’_dnŒŸÚ8P‹Ôb‹O¾ÖY!["O᱉ƒ4‹É;F2H%›oq‘vÆÒêÏÄDMq©³˜ain,äF†%·'ÍNÜ—ñœ¾A·þ þ€ºwþÇþÂ3¡ÐMÿÀHÿ—7ý‹îpo§ê0Ø]-ÍÕô¢ßU¹•{Y%ûQ„ìÆ;°>é§Ao-. ¯oãÃÚ'‚!…»J–ÑlùXnrÓÉ榸>!ÔôØÞöY.B»¡• 3[Ÿ¼Ë ®Uù_—ß‘]ùðÎ…ßDÓð?ð£þÿÌNÿÀHÿ‡?î‰P’êgYkÏLµ¶¿ýï …#¸ai$›¤ c¸) ËFAÃtÖ=ÈÕô½gÄs@ú„æXí|‡Ø ÆYå/Ê@Ew¬Øä‚Mu?ðŒè_ôÓ¿ð?ð£þ þ€šwþGþœb¢ÛQÜÕÂNÚœJëÞ(û6qxe…”›uûIîìÈ>XÞNP‚Ï϶ú¾ ÷vZ’A−õƒÎ§çŒD·ªí'r€W8ôÉçü#:ýtïüü(ÿ„gAÿ .›ÿ€‘ÿ…h¤–Ñ3ö2{Èá´˜n„Îc…#,¸ Ó Œç€;½!ÞM"ÒI'wh”™gƒÉ‘Ï«€‘ÿ…^¶²¶³`µ‚8!\í$ £''qÖ±-½¢5§ ÅÍ©6z]ƒÞ¹¾¯3[¢,Ñš—`÷£`÷£êó ¢,Ñš—`÷£`÷£êó ¢,Ñš—`÷£`÷£êó ¢,ÐzT»½â8µƒâptÖºXg´‚ÎSØTI]Ò.8^¤ÑX(KcjDbÃx˜±RÆO´~ï±6gæ¯NòǽX÷-Ôf•¬+£Œ»:¬ñE¥Ì÷SΖò−¼ÉFÝnäGb#HÍcÛÝøŠ95‹¹þÙßfµ·‰•NÔ(Î’8Ü\>X#åv ×¥ìôl¦’„×AÝO‡õ?^j6ê ñ¤–ßl•^5W# TãvÙw`œp¿−R‹Ê†ïP›P¶¾x/[QHâ”´ßéJm—åûùpdm$+¾û4bv˜"ùŒ³àn g>ƒ'ó>¦¥òǽ>Yß`¹Ã][O/»øàšçÏk+©#[}á•¿xËdÚ¤„\`£±æ]a.¿á9·”DÒÆÔ[¯—'S4‚r²)¡F`~ðzWiåz6zJ]tp׫Ëâ1£‡R—OKI+ˆÚ5Y¢$É*äùlIoïaWÂQOöY¢i®−w²*˜á* SoâE?0?1n…‚õ¸Ø(òÁ¡ÂmZú8…³ºÿ„OHù¯–[}BcÞå™~Ö ™ Ë0 “ós“œÅÏ«Á-iwRNÌ−nâ`Œeä0¤[±þÙƒqè ·–=èØ)(TNö £Ìlíç€h‚Xïf¹K{DCü›·œýŸ8mì ôÁÆ1Uº™ÔŒŸÂÌéü]¦´ð‹=ÔD‚in%1G.R(–B±í C»8Œq£'‰4(.−−çÑ#kˆ¡—fÈIU•ÊiRâ9cÌ!ºvÛ"q“ß[‡D¸Ñ[é6‘$Vˆ±ºm%¥' ¤ œä¹£á±„Ôp‘ê"/e^8°¬yt^mOûJOhÆóÍI¼ßíË€C"•\£à òô9ÉÖ߇-/m−î –ñÜ\]I9KyZTPØÀÜȤôô©vèi.¦ÍQH¡1F)h Å¥¢€b–ŠLQŠZ(F)h Š( Å¥¢€´Q@(¢Š(¤Å−˜£´PbŒRÑ@ Š1KE Š1KEñ¯ÿÈÝ©¾¿úײ×xÇþFíKýõÿЀ;*(¢€"ƒ>[g?ë©Ïñ%Ï™3̇88þ¢ßý[×I;cøÏùÏ~µVkÂn¼µ‹w“(´ˆ¹%: x?É Æœ¬UAÍej:‹¯…¯u+L,é§És° †ò‹(#¿8㡪úN³öÝNêÚWdE±Er¢9ƒìÞÊÑ;H`0~\`´£ur\¬ìUÒ¼;s¥Å%…´ÆÞÔ”?kÃLÛP Ú¬¥T«¸ÀüØ#nœZBzo¦7{·›zíSß… “Æd“¹8 HÉeö-sk}s 6PÍ¥¬wW•ÑG Í(Â$yÛÄò³lÈ;#ó@ëœôÇ¡5Ï àÜ¢µf²©)+2_ìKR nÌþ`\›—2‚”aó6»ŒtÃZ{èÖ24Ûã¤ñùr!•¶°Úq嶪Ýp£ñ¬Þ"¶K−¡™G3J$R²FèaÚ›=X\!ñÆzœ+ø“O7i!°oæšÐ?™”LnPÄm$dèAèA¤2S£ZŸ4Ÿ29q¿‚R?,~„ÿ?j‹Nðõ–™öo È~Ë0š,„P1Æ„U‘¹?1$Ç\Š p¤áÁ °É݃€z=?Gk‹MN+˜ÚÞúAº KÆI.¤q¸3+s“–`An%ñ/ˆ Ðç]EÚ®¼¢¥wÈɱÎQ2 ;ÂÇÞ‹Fúæ¥u$Rý’9n]mX6èFæF\㪩þߘ08ÅZøt1PŠ›×}áˆ.|#n÷ö'S[Ïöö±")óJØp¡–,cÎeo ‡¾7WrIÚ8Ð D%#$dg8c‘×֯ͨ½¦{{}¦ÞZ%¤O3Ç)‰ÕT±Û²F»‘Î>¡‘ë÷ßf6WqÆn^Õ._ËòTVb£\p‚T¶`ØK};[×¹†êá -!™TÞ–Y@Î26´ïŒ`ôÏJ˲[[ˆêdûA@$Ö„¾$°‚y-ßÍó⽆ÄÇ´e]»HçîüÇ'ý–ã#ÈÖtâ³0»R! >œäàmãæÉãåÏ=(¥×‡a»’äÉs0a.#vÒcyÇCÀ¥¾ðí½ó»´Î…îZç"4fF*«˜Ø‚c`aÔ†“˜³e-i÷ð$ÐܦÇ(’CÊÑFr #©ƒÏÛ=rÂö+6IŒowOr wÄeCcœf€#ÕtvÔ§fyI4&p ‡F\‚ *G!úäa£YÞlªÅ©F›öÅ=´að cv€záµ_¶Ô¬o"’X.£1Ä3#±ØqÇ=è@=jíxV²Ið-Ì2N¾b`¢"†;—9Æ{Þ·µ#æÉ−ÄS$âá‡,c :2®×ØUÍ6Ñì¬V\H‘NÄ •‡`œà†SèTö ôQEQE‘âïù-ëèÿè 8š(¢˜Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@›EPPgËlçýcõ9þ#D¹ó ÆÖàãøZ‹õMÿ]$íã?ç=úÑ/úØ8ÿ–‡¶…¿/óë@ÔÀ™CÈàüǦóèjzŠû¶ÿ®’vÇñŸóýhËÞÛ^ÅȾ°Õ¥¸`Ò[ÀÛ'8 Xºd\œ…SÂöù['‡|?sÿ¶§¦ÝŸ-$ú_Û.Lx3¬`ÆR Hœa NsÇ#øI¥ |©Éu«8¦Ó,â»G†t°ÓŠ?U‘\Ét–An7:2my·È·GEçŒÉ¬ÙI3Â’3H—f*ä¾XzåÉ“ØFÇ Í4ëúHH%£A9aÂΆ"WùÆrÀc=x¦QJo ÛÍ«6£ç²Ê×1\¼nŒƒ¯`$þn„RÇá·‰FÛÕÝ–−I€á ‹æ ÿ9Éä©N;µ§>¥kkme4»ÙŠË[Óoâ³’

Client Side 462 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Èw^Eç[ÄîIûÁ øvXšû|lwÀ÷9·?¼0ܵÂìùþL³°9ßÆ1‚YeáH¬îl¤>bÛAd4gs4qùa‡ÍµAUO «o«é÷wkoy²¨_¹"°,ÆOyaäÈJõgèÓ-i‹’I}o åþþIUcmêι89b€+Zè •}¦Üݼ]ÆБ ˜ÄhÊT• [ AäŒ.@¨òèWš¤*5[ØØ22¼PÆxWÍPû³°ª É»ï1-Ÿ¶ÚÓd.íÍØO0Á毙³ûÛsœtç§5VmnÆ »«y÷ZÂe•¶ðÚH»èxìø þÒ§»g¹†;›R³mq—kJ" áØ“»÷£ —ÄZd6†íço³ˆb˜ÊE,?ªX¡pqÈÌ“k0ÁysÛ]ùvÒ¤3܈Ǖ²£NsÒDè;Ð ¥Ôw–©qv¶A 0U ©÷øš€ (¢€ Èñwü‹Ö¿õôôZõ‘âïù-ëèÿè( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( M¢Š(+|yMŒ¬“¡ÏñµcÍ·Î?Ödãøˆ3å¶sþ±úœÿ¢\ùc?ëpqü−@ÕxbGVbÏþ²@vLà}óèzÿõêÅGn FG92>2Ú4áZî¤xŸ2hÚ–£´’üð4‘³6~q´#ÎÒ Ÿnÿ(°ß·8ÎÞ¸È#5ßZµû؉”ܤ~cGÜ/úesé¹Iûà ֺ#Ùê‘MÉ´j Ä»þr±†T±@pç ¿|Äl9B:‚$A §%ÝHõ+C”»„ªÌ°.™EU'†%YHÆzúƒIw©ØØÛÏ=ÕÜ1Go”–ÉEÎ2@ç¯^(#þ+gQU (ÛèPt^RÛÂqÄþ|òC−ð¹†U£?v8£ˆ«yÈ= dr-ñqygˆ¼eC¨pJû ÙíëÚ¡}JÊ+ƒ—Q,‚Ù®ÎO ÝÓ#Õùs, Y¶ƒ#"º¨'‚J²‘Œõõ¦Y¢iÞ–32Z0ÃrƒÐ‘Ô }dx»þEë_úú?ú ©§×4û{Ÿ³3ÜI?Íû»{I§#hBßêѺ #ÿ¾…Uñ5ÄW^±¸ÃÅ%Æå`ÈÚ{E 8Ú(¢˜Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@›EPVÿê›þºIÛÆÎ{õ¢_õ°qÿ−lÿ ~_çÖ‹|yMŒ¬“¡ÏñµcÍ·Î?Ödãø€%¨ãƒ²È ±8\u−’zuëùšeÝåµ…³\ÝÜE+Õäl öçØrz ¡aâM+R•#‚vWâ%6Í>‰¸ÇƒÀç¿jNI;6;=Î"ûÄZu—†|=s¥Ë¥ÏªZÃlÌ-wÉ[7R-’pA8Á{ ‘Z:ŠêŠ¬4éƒÙOl−læ1(oI •xp¯#pÙœzc°º×,ìnUÅlQ@âø~[‹Æó湂(ZûËÚæHdsq,r«Œ>îpÇjœsÄšý»Zø;M·eZ9B0ˆ¹rFyäóϺ6šLw0¹[{KU–O?{C0Šíe“–ÉÚòÄÇ>Ppw4ŠÊã*Á‡¨9çƒùP~…ÀÒ£óÚ˜8ÁBü„ÇAµv§d©8É5£LY¢gTYc,Éæ*†+ýáíïO Š( Š( Š( Š( Š( ²EÛæ( °pzö(Kf¦»Óµ“ì¶óê>sG©K·ÍæÍ@Ý€»ßºFäVAc´P3œÖ¾Û'‰#†ÈÝíñºf)—œrι†ÀøéNÒ)‹−j1−⹊$¹ 7—3òÚé¼Ì…‘T,ƒ’²»åØW'¯íŒ÷Î=èÅpZF‡§iÐkª'îàxã½7ä·Û…"Lª‰qÀ A ׇKÕ'»‡í×WÛZú/s·ÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=820ycÑdt$aߧûƼ×V6>,¸{¢HiüÐC`õÏÖ´£ÉÙœø™ÎR‰õ®F;~5JëU³µÍ•T¹¯?°ñ!Ô¬ãX5ÙcãdPÄ~5‘¬´’j–zVŸy−æ£xØóäF;œvàô¢Ã»ûÌÂXÕËx−Yêº^-m« šÙ_dO°³ }ª/Ë,$æÞVŠgd‰z©f ‘ïÍM¢ipèúTPò#_™Wnì}ɬÿãK¶Ý‚÷‚B=B#7ó \x‰(BR]ê NÊ[™ºY¹¶ñAõ+ÉmE´²Ì.g «‚¡OA-Zö¾,Ðï/#µ‚÷t²¶ØËBê®pNÊ…$‘ƒÏjæ.ín/ªñ[µÌP¥¤rAËJi’U¹)³ãõ¦i×wsZH4¹á’ÍK»³º™#J\îU%Ø¢…$onÀg“ :Ê7ÖçEX®wcÖ¸ôý+6ë^Ò¬µHtÛ‹ —smÙÆ#æ$.H ã$W–iúmݵݥèÓõr]ÒlýšmÉå´{ÈÊ–\ƒ€Û—ƒR\Ûk—ÿÚòXê*f"UÛm#‘@ÜÕ™@ÂûšèueØÏ•w='PñV‰¥]›[»Í³ "BòãÀ›X¤m†ÞO+¶½_N…-´ëX#GVX—j(ì=*á'@VuÞµge-iÚLÅþÕ¨,¯ DaKdöá…hÑ\¥÷Ä−×T¸Óm¡ÔµK»S¶å4Ë).D ýÖ*0·lqZñ6•â}5oô›‘ÌysDçå €¾:Ú¥m^ÖÚÕ¤‚òMJä‡i7–ÇMÌU?lšùš•ªÊ£$ù›>†0‚’œ^…ëMrÛDÓu+Û™†k^ ¹)a3YÚÃñ¼_oÚãõ}B]ZñmUókäãc“’Húäþ5rZÚ%EV@FGkép8NJqæì|¾i˜IÍ“õ;;+g#íz¥ä’-ç7_ζãÔõªN×/¨é€üÊÜÉézŸ¡ÍyÊÞKœî5½§êm%RZzÎæÛX®``ðʡчpjp8•çÿ µxî4ëí9¦RÖÓæ5'¬2p=3ŸÎ½šòªG–MQB§´¦¤:Š(©6 (¢€ (¢€ ½¼ƒO±öêU†ÞÞ6–Y¢*Œ’~‚¸í}üω¾ t`CÛj%HÙÜÛÃwm−µÄ)4¡I"‘C+© ƒÔ\ö‰àm Ã׫wak/Úo—y†!üï'bû ÏøVmÃÍ5mÿצõ½ Iqs¸ù»òs»vO=ˆÇ®cÄø§âšlŒ? ·4l@[-²óþ×—Œcß¾kµ¾ð…ªÍ©˜.-ogÇ5ä–æ\c¼¶váwë:−ÒéÂh™¿³¥[|ämpŒ€õç†=jM'J´Ñt¸4ëŒvЂÜrI$’y$’I'’NMp‘jkã=Ã. úG‰œöò5¶áÔq˜çŒ£d|§æÚ âÜ×Þâ=Úi•-ÍÉŠÆúÖ–·Œ£±àª¿Ì-9ëµ}àR±¼³»ÓRX.®šñÔ¹ùëÆ9$õ4ºO‚ôT:•¼W^˜¼¡=åÜ—‰œ¥Øíq@¾ ëO£x2õ탾¡x>ÇeK¹åLª…zŸ¢“Î1\n‡sgá¿è+oáÝkGÓîlÆ,·ðF©,ªC@IÈÞÇÌRé›{£Zj7Öwq´’XHÓ[‚çhr¥wèHà‘Ær1I«è¶zÝØï£gŒJ’©I ::0eeeÁRzòk- x‹á·ˆüU«ê—ñke/U¶\¼QÛ™Ð[ùYÚª€CÇy9ÉÍmC¥Å®k^°»ñ,ÛÃO$ÛÝaèzµÞi}©éúÄL×:{Höì…Уdgå'-dÝøA½ˆ,¶’+¥Ü×±ÍÃÇ,rÊI¬ŠC(lò 㧠y—LÓu? %½ÄÌYk¶Qêþå÷Y ä…Õ³"r¬ß0ÏO'->Ó®> ÚH−–úe]ÿh› Ä6æ#䧃Æ:ü Å¡O¤%œ‚ÚyþÕ,{ùÏ6íâC.w–sš¿§øvÇM¼[Èsr¶‰gæKpò1‰Y˜Xœœ³ry怇m-Ü:i¾−³Óí/+ËdÆv±ä9BÅ~`~îí]üÞÐeÓ4»mXÕB•`=}ùíYÛ+§E£E)ùÞÊ+wÂ÷ $×6 ”Ì°§äçÑjæÚ\ÝhÅIòw*,™ïL{ûë;Ö3bŒ‘¾ì>rŒÓºµÒl!¸2ÈŒÑ(óæ?tÜú£¿-p:Î¥%ÜÏoæwá@ç 8Ç°¤ë)«®„¬¨»w:Ÿ†ö÷BÔ\ÙØ›JoÞE;0]‡?1$öädw¯}‡x„Ú7Ó5åÿ â Å]G˜D?_•¿5ê@`ן^^õo¢å}Øú(¢°;‚Š( Š(4QIE−™¢€ŠAÒ–€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€

Client Side 463 How to Develop a J2EE−Compliant Web Service (endpoint + client)

(¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¤4´RQ@ E%´RP(‘ÿ½ý \ôýïèh©–êþº¿þ„jÕU°ÿPÿõÕÿô#V© )ê6i{lÑ°Ïá>9ð+³¹T;z‚:ƒ_AUKÍ> ÈÙeE9Å15sãY-uFWBÑ/ñÅKý¬‘B Ò·ä+ÝüIðñ5)f‚5(’©RPtÏzųø4¶šDp\ˆ®gË—ÊÆì“§Ñ D¢j˜XMÞÇ“Z_E]æ #ýãý*êkqÁ$r¤Å$ÕÑ”ò¬AÔô> @ïÄr/û¬Eiiß´ÅpÓÀò{;+E‹iZÆÀFRælókêÚ¼Kcls€»bˆ €02GQ ª6BëHÕ#{µ”aP§=3_KéÒô»3 µ¤:$`f¼ïÅÿå½™ã…YCteèk%]©.n—·!¯_kÉþ|K¹–ÙÖDYggÕ‹ç89'•Ç/ÝÀ¨âðf— 5ÈŠ)HÎ;adrêTtÎOS“3OÜ(¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ CKHh"óVkoéºX…Yo!C!lòö`cçyúb³nüs¤ÙMt“‹”Ks2ùÞ^QÞ ª€wdnê@±éZÚ†‹¡}kzÓÜCsj’$RBà`>ÝÀ‚?pV]÷´»ÕºÜd−p%8s¹ä ¶ŒrvŒó¸ÅRåêe.{;ŸÅ–±èúüvó–±¹o !31@yã2(ÝÏ#d-s%Ïš%k¦”‰I Èጠ¬ÀŒn$`œÓ÷Iýí´#ð׉ãñ×f I¡‚#ÊË™‘‰œpÃóüF:ÖNáÛ:؉^8£egÈ>ZìSõÚükS+_CHs[ÞÜ‚ç¤ïCE=#ÿ{ú* bßõÑû´jÏ>¿¥xÏ‹ÑOŠo PNGojÄòÓû‹ùS@}ϯéG>¿¥|ýå§÷ò£ËOî/åL1‚r@'éKƒþE|ÿå§÷ò£ËOî/å@@mú~T`ÿ‘_?ùiýÅü¨òÓû‹ùPÐ>¿¥1 G9eð¯òÓû‹ùQå§÷ò X (ð§sÖ¾~òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚ůŸ|´þâþTyiýÅü¨è,R_?yiýÅü¨òÓû‹ùPÐBŠù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú Šù÷ËOî/åG–ŸÜ_Ê€>‚¢¾}òÓû‹ùQå§÷ò ¨¯Ÿ|´þâþTyiýÅü¨è*+çß−?¸¿•Zq*ú ’¾~òÓû‹ùQå§÷ò ¨Å|ûå§÷ò£ËOî/å@@Ò×ϾZq*€ŸÿU5aÍä•+qü áFùÁãÞ¡[…7›*†#œaçרÍBË(O.6rä…¤“ŒüèòfòÌT›Ám§·ó©’xÖÌ@á™\¾ý§c#“ÆrŸ-:[ó+HJcx“Ý ¶h³\y¢/³Íæ0ÜË;ˆõÆ3LÆ7|p„ÏQŸóúÕÖ¿Ê⨠!%O ®Ýî èsé\L˜¹oºÒü¡'°n§ýßÖ€*¬ˆÌÊ®¥—ï(#+õˆ« nëòW!CÏÌãûÌU%²„^ͬӕڱÀ^8§ãדZ‘ÞˆãˆbÑ”!Y² ©#¸'© >Ës¼Çöy·Jùg?•5a•£2,R2’ÁIz“Û¡«/~qˆÆÐ…ÀU [¢ÜÓ›Q ’(Œ.wáI¨Lrã$ûP'GŒ€èÊHÎ`Ôíg2³¡Û½X¨Lòä¾£ óßÌŸÖ€ òE³”¹RQHmƒqûÍè?OΤKï/qT%öÆü§ÐúU“|-!gpß»Ïޣצ)d¾I¹‡†*ü¸_/dtíÐcPFB¨qµÁ ý?Îi°¸Ûä2È€¥'¥Lò/Ùcˆ6HfvÏ©ÀÇþ;úÕ;;8,I1#1g!w$¹÷=¿ x ¦ÚMʱbbÄåÙ#Ær2)†DfC„S‚ÅNãVÍòåÁB¬ÒmfÁ ã‘‚ÞàòM Ô˜L²•ÜC;•l`–9è8êh³ÛÌ›·Dã`¾SòçÖ³\Tò—q•P„–£Ö¥’åe„ÆÊùÚ 0lriÏåŸÆ¥—QM¼¦—fP‰ÌAœ×CâãÿEçÔ*ZÝ−-7è:Uã¡Y„÷ø´H-Bm$‚|/00V[˜n#†ò;peÞ"’ÚàKd²‡î·g êZ…¿Ÿkn’G‚sçƤpIzÞ¬nZÖÒÑaÜ"´´•Ñ%Š/íO6DO3M™»¹0=MSµô½µ(\Á%ÃÛÎeLnÕ€ã=A ðj−ÃÔVü‚Å¢é6‰=¼k%ÔŸiÝÈQ7ÆFá×iÆHãvÜWAy¨Ù‹»iÚîÆi!*]î"º˜ÎÍÁ@à~^p{ò) à7.3‘Š7.3©®ÊÇWY¤Ò/n®l÷ɹI^wH™~a³æÆ°[ŒHïV!»·‹]Ô%Tµw0Àg†#)çp2à©ÇÚ9ùGMp¹Î3ëVEÉP|°@nWs¨Ì`XdúƒÇSØWX·Vë5ÿöeþ“lÏzòJg(V[r¿(A'*9ÉíQi .¡jb]XV‘‹8È)çîíÇ-qùÆyô z~•Øj7–RiSª]X¶a‹ì©6)8ÜHûÃøòIç#Ö™¬jÉ}ˆ`k‹g…€9:(¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€:?ÿÈÙmþäŸú xþFËo÷$ÿÐh¤ÈÑyõʱ3ï[~.ÿ‘óýáü…_´hí´“N†îââA «m\±,rXƒÙMr¹÷¤ãÖ»5¼³†IaÔ4´·¹GEù/¹Y—hDÜÇ䀼' ©£¼ÑecŠ'y”2í³b,To;q,¬ > *GQŠ`pÜRäz×i¥ Ï,QÆ‘fbö-/,áˆAC¨E"7‘Ç–´yÿ®©ÿÄQÿ gMÿ¡Z?ûúŸüEtðZSÈó2®ÓÀîr3®>$÷òêÛw‹¨¶¨º’rßfVWAƒ~ùkåîÎ{ûV8øÓh2àHÿâhÿ…ÓýdÿÀ¡ÿÄÑõZßÊ]¡üß™©¡ü/‡ÃÓéz~¡WÖ¾|WÓ−¦Ñ®[c€à†^±'ä-¢|"³ÑTŠ+Ûybº²’Êþ̳"3½Cù¿3JËáÎ ÚÛZxXµ++÷½³»ÛâƒzìxÄNíòÝüYÜÄçµCsð›fŸ¦“â ¬TiSéw öË1™%s#’6’å³×ƒ´óTÿátÅÿ@)ð$ñ4Âé‹þ€2àPÿâhú¥oå¯PþoÌèm~[−ˆ,¯/Þk}fÞÞ x¡H„ܱ zQ\-êu−u8ÈÑyþðþUÄßòFlÿëºèƪ.ÿ‘¢óýáüªÿ‰¿äŒÙÿ×tÿÑ[áÿ‰S Oðeèy! qŠ:þtÙé_C©òç¥èº¼qèVÜßjm6ᢴy£“¾ùIC äö€ƒi'Ö©A+~ð—9;þìÝ×mô¹–{h må•CZîw#wÍœvÜAíRO§h+ªi1I”ZCÜ2ÃuÉ3\Åå¦UÏ“‚NÌdŒ(«_j°^[Û²ÛfxÞU•nƱ«m.ÏÑW8üÀêqLO êl/™ÒÞ³)çI4ꉇ£+Æ0ë‘ôùaoŒNS×÷dþ/²³³Õb[8 ð†š41ì’2¡d“hÀ÷ïY—z6£b²µÍ£Æ"œ[7Ìï î 0~n9ÈÈäsȪ+Ȩ®Î]HïGiLïˆâ8Uÿ¥F©ÍÓcUðg;~m›(¤µ2å…YJOCþkûYô¿±bõ"34mÎa‚D°—

Client Side 464 How to Develop a J2EE−Compliant Web Service (endpoint + client)

“£)ÚÇwÝ`~cœçš-]oGFƒÑKþâ’ ¤ßåÃ#ì}¨NÑïéÐÒyoå™|¶òÃm/´íÎ3Œúâ»Ëi±k´“ÝMÔ‘È¥¼‘I)TÚHe›r“×çÜ 9%°O>šË?œlÞÓì^ZyHÌ\–Çß^ÝNT`µ^Þ¯òì)?s•û {Wê1^ÅäÇ´W 6JJç¨ a{œ¸?mY/„íö4[ø_Lе−`Htûa(‚»4© s—` àð*+#Qµ$ÆxÑæx²dR/×$sœt8Ù𶫧ØAq£:¤o4Rˆæ°[¸ÛnsÁ «àðÀôϯ§ˆôÙaÓákýZÊÖÓQAmnÌ @î |ÁøØ8Ç'æ8#ºÿ‘—Ãõïqÿ ÇE_ò2øoþ½î?ô诚{Ÿ_‘çÞ.ÿ‘¢óýáü«O_¶ïàõ”VÐKèÏÐzŠþÕ«{r þʇó3Ãÿ°µúê?ø 'øRaëôÔ?ðOð¯h›â¬ ,¾SÈ›·Ä-û¶1 x&uÝ'ïÀ ÆzvÉ·«ø—P¶´¸›MÓÇ‘} i&$f™#uÆrÏò“‘ÜôÁÚµon@þʇóý‡«ÿÐ#QÿÀY?ÂèšÁÿ˜F£ÿ€’…{küCÒVÚyÑf‘!‰'pƒ å´ >Fp8Dn;â£oÊ’;,Ãu%ÑŠPÁD",q½vÊFä¾£ûV¯ò þɇó3Åÿ°õúê?ø 'øRaëôÔðOð¯ 5}{û*öLf_:,Æ£ŒÈÓCÙàn˜gƒÇ=°iÇã$ëÓçÚ‘ÜH%]±;\=¶Ð:·ï#88.IÁ”³j¶¿ dÃù™áØz¿ýü“ü(þÃÖ?è¨ÿà$Ÿá^ëÿ „{õÅ°imm©:° _f\®B`ò~ö'Ú-K¯ˆì4ÛÖM±ÝHÊáXK…X¤rUÁÿWÁ÷äx_ÚÕ?‘öL?˜ðì=cþþIþaêÿôÔðOð¯k+Õd½Š(ô´"K„b2Œ˜ÚÞIwoÝʯðç¨Áá«cG××[–Ckm7Ù#ã³y-D¯Èƒû*Ì|ùý‡«ÿÐ#QÿÀI?“ûXÿ F£ÿ€’…{uÏ‹.¬í¯qf²XÆÉ+;'¤Â#ù±‰$!!IáˆÏoÝNK åµ´dIä7$i¬Ò«û ïì¨3a‘ð,kUÿŸh?²aüÇ‚aëôÔðOð¥þÃÕÿè¨ÿà$Ÿá^×'] ¤±Ù£•^3N äöµOä_xeCùþÃÖ?è¨ÿà$ŸáGö¯ÿ@Gÿ$ÿ ö9¼Oâ%0ÚZØÃq{åMæªÀwyŠñFGæíPc ªFTœ-Øü[ök==¯Do$ò˜faˆ HZ¶øÞÙPþcÃÿ°õúê?ø 'øQý‰¬Ð#QÿÀI?½óV×çÒuT„ÚùÖ‹jÓÏ"00WŒxn˜íÔw«‰µ £½‹ìQ-Ú›ÓjÎøT·¸ò‰`2F'ûß7 Å%›Ujü‹ïì˜1á§CÖ?è¨ÿà$ŸáGö¯ÿ@Gÿ$ÿ ÷ÏcáèwZ‹KÉyÄ´$oµNÑœî,À(ôyÆ ÝWQÔ¬/4öU·ÓÏFìļIó²§zØÉ,zt—ö±²ºÂ–]²ÇÝÎ@LôÀÎAý-SùÞÙPþcÆ°õúj?ø 'øQý‡¬Ð#QÿÀI?½ëUÖ5=~ÊÞ8−−¼‘qzöþj—–M‰"U*rÈGÌRp›gã FëMÓœécí× i!‹xÛ"Ln_›ä%ˆ\pXíö-F¯È¾ðþʇó/ý‡¬Ð#QÿÀI?Âì=_þþIþí¿ð–\ϪØÇn‘-¤ëdx˜™$d9”0H¶íÈ ü«ÍA?¦œ5®l¦ý¦W@Y™Aê “)®àÅʃGö-_ä_xeCùþÃÖ?è¨ÿà$ŸáKý‡«ÿÐ#QÿÀI?½êÇ\º¼Õ4¸ÂÀÖWº\—‚TÜL€~êâSÁÉéÓçØø§RN–]ZÚ(/KDVÒ`¶¾JH©wódÝ÷x²¼¢ƒ¿µjÿ"ûÃû*Ìx¯ö±ÿ@Gÿ$ÿ ?°õúj?ø 'øW¸ÿÂmjígå@Lw¶¢âß|ê$lÂÓ ÎѵH$b0j ojÒèÂ墷kµÚ«+Âðm‚g@nö$•n2T¬«¤þÕ«o}áý•æbDÊÊheJrw8! (Y-V¯È¾öÙPþcÆ?°õúj?ø 'øQý‡¬Ð#QÿÀI?¾…¶¿¼—ĺ4p¬öÖóBÊIfóeb݇ú¡€=ùäýjúêÒÖfÐ-ÅÅÌvêó!tBÇ©PT¶=7 Ÿíz—·"ûÃû*?Ì|íý‡¬Ð#QÿÀI?Âì=cþþIþí–þ'Ô¦šÙöZ¬ −Vâ=¾FáàÊ6ì R›°Cg8ÈÆj ?Å:Î ,áÅ„sê0Z][Éä»−ºN“¾Ç_0 ùÜßœ ¸7ý©Uý…÷‡öT?™7ý‡«ÿÐ#QÿÀI?¡ëôÔðOð¯l°ñ>¡w%„¾]²[J¶«4A¹yÁ9WÝ… …I>¢®øcY¾Õ” ﳆ’ÊÖú3lY÷â2 6â¾_Þã9û£§šÔJü‹ïì¨ÿ1àÿØzÁþÈÔðOð£ûXβ5ü“ü+Ù¬uýzþÖoô>Úè[5Ï•>8ò¶ãr+ܯÍ66 0§H0ÞiÓh–ÚŒö2Ëz‘Í;GñddHÕ»–bÌÄO ‚àhy-OåAý•ægŒÿa릑¨à,ŸáGö±ÿ@Cÿdÿ ö¸õ[Íö»½2hí5+K ±YI4Û’ù360'` ㊛S×õ8nîà¶"Ct‘yÂÊ[¶U0«äÅ|±ÆFEÚµ/nU÷‡öT?™ý‡¬Ð#QÿÀI?ÂìMcþþÉþô~—t÷º]¥Ë¼LóD®Í % #Éu%¹†yå†8ê(ˆ·0_I−å¤#KF¹w1²ˆR;g†N ?æ^1ËóZÍ*ÿ"ûÃû*ÌÏ%þÃÖ?è¨ÿà$ŸáIý‡¬Ð#QÿÀI?½‰¼Mâ´ÛÉé–×vq\Jo$ÊÎÒÜFÊ‘8Jàû9ãF{¿ÙëvÖ’ê:L±=¬÷NWN•ŒChû*ÌÏ þÃÖ?è¨ÿà$ŸáHú±å¸þÈÔyóé'øW³Xø“Z¼Ñ`nmþÓpö¨v‰un‘ù‡ þ²Aæûm#Nr+¥Ñï®.šþÚìÄ×6"ÞI!R‰!1Ç(`¤’¼J I3· 8þ6¯>ñwüŸïå]¾ÿ" ãÿ¡µa€\ûmÍr–6:†±«j‘E«5œ6¦%D[xß;1É#=h=„º|K ÷mw.ö̬Š™RcŒŸóÅcõxãn4-ú9ÅêÜLg–I$u‘â%\Ñ’„f2¨€©Èm H©—OðâÉu ³Kþiù¹.ûØ~V,–?"sò.8Ok×V6z¼i}–Ô½ò癈,é%#B[‡>c°ºp}*ø‚î J¹‚àC5é*ÊK[»…Îy]ätDyù[ì–× «¢®"´Õî-mí$*OûGyòNIlç'9Ï4Ë·0yiÈ!ØcòÐ2.Š…pùp‰ÇL¢ª¤Sµ›ÎÓ£œÝE"²ö”\FßœdýÞýpk¾ñåŠ/ŸÊwû:Å÷¶Ä‚dd 6âþÎvå\)ì—p¹éëy§¥Ô·JO*ªÈø'!s·ŒöÜ:Ÿû^ÓÕÿïšám®í¤ñ}å-®¨'x"µ@×[È}Ë´,yÂ^ P2d‰`kr¥áâ÷cuõK7Ä‚ dÌ´´Ðl^‚Ã/›;»”!˜¡dpîÇU7b¨Ìqzå´Ýzúþm:º³\ÜÄ’Ì‘äGº ¥’,ûèbQÉÈÝÈéB¡°\ê4mFÑÍà f§ ŒÎ¦Å .P$pä´(?²ü;öu‡É¸;$óVClŠæ•ø_›äÈBw·ªê×êCª[YIomÖŒ–†3qîs¸|¬qdÑì—v;#BåZÑYJO#ÆYJÌÛåR!ƒôVM'ÃsCs[K?–\‰OºH®3þ}]-çhôÌI¼“$l

Client Side 465 How to Develop a J2EE−Compliant Web Service (endpoint + client)

n0ÆÞr`rH˜$~ÅûÕYüOx!Šío-Õ+Ï)˜ÆétQ`eº‘“qvxƺãÚ^ÅwasÐî-´›ë·šèÏ"˜ŒK,k–n¬H,Npßð•\4º¬i, Zª¿™*Æ‚1æìa̸ÈâC$gæ´Yy4í*xYfšY h×*̾TåNÕbcÁË+c+SöK» éX¼± Ñýè™XÜLÎŒ (û÷( ÌRñVâ‡B·¸k‹{sÆ|Ñ€ª @ ‹‘‚U…y¨ñ ÃÜÇ)×ìVuÌ$û@Us¤ÿnµŒ¤Cu*Gååc‚HÈK´Ùì@ Š~Éwasµ¹Ó ®Yþfæ~xÁÉ|¾Hfcœ’O.-¿Gº¸ìsÜ-Üëg%µÑD™”m®IýÙ€ BàOO-?d»±\½}‰¨ÝGsw I,jQ[,>RA(@?2’TåNAÅ2ÚÛB´¸¸ fY.|Íçæ#÷ŒZLp»›–ÛÛW9Ú¸ãõíZçMÖàXn¢@ÖŒËo 'íæ(¼€‚}Iì88¯cª^]ÿjY®¤È×äÉfKO.äª,Hù¶ÜŒ/€Ø %E%kç|ÇH’ hZ ÉjQ¡P¦6àõ㢖−{¸.eIÞHH*ZIl1e,¥°ûXî]ÀìÒ!œÛµÄÈ…üÂÛG—‘œ¹™º}ÕlZÔ/"MSMêj×ROˆ’ä®èÌÛ\¬#å—Œ«’O–«½pÃö(.uv6Úùc]͈Ærp¢›=¦ƒqÈÐI–apÏnÏ ‹ Aõt!”ì~R2 Îx¿ êS\´¦{ß5¼«ft3ù¬Ó°”È¥X §j–r±àÇ−5Y¦µyqglÚÏ—tÒÊÖ‚šÏÍXüÀT¢‰6Œ‚ dg;ÎOb¯{°¹ßÍg ÜÛÇnðH°Ç…HâwŒ"íUòÀR6ÆB¨1”ãMXvÑåk–{u´À¶Ó+Õ.¿°4Éu E ™ìZI¶¿ÙÙnþÏ$m´˜³3y|»H´e¾¿³Ÿ\œ»Ü½¾“Ô6̸ èÿ²fÈäUA«\‹mK}ïïD£ÏÛxÁ`At±íÿ˾èÉù.ÕðÄOØ®ì.zö‡Å¹‰måMȈdI$Yr¬ìH~ýÒHKƒ¹‹’IÍKähbâÞa -ÕBï°í9RÉ®AèX ÈÁ¯6Õý°ûS^´–ðÄ‚1摬— æÑf]ÆIOÌ~ˆkŸÚ·²êzCfT¯Í†ÊB†=’îÂç£AqanT¤·Ghy“HùùBó¹xQ×¾ORI£u§xvóO·°¸²2ZÛÂmâOœb"¡Jd•ùTà’2Š~ò‚(%ÄJ#¶½‡|ŠnŒ®FT@è~VVôÁFy;Ï\i ѯÌ-4òéâáÌŠ¬f+‘Ë3®3’NÐÍ€HR°•‚ç Ň¡%üvÌ.$¬Ä1\9 à);Ws(c€2Ù'’s–>–8¢6¬vTŒº©ÞÛX¡nJ6Tñǹ “–Ï ¬ oT8HئT˜ýÚ~_Z¦šw‡V µvbÈ ÈìÉ´X±*€3.ÀBív\a˜gNººŸPÑå{‰ÄW:DÒ›iqë[ᘀ 7ïä¼Nrlµ™l´‰ê)u?› Ëy-q‘ÕËF¢ic`Wîî_¼«·qPW±]Ø\ï"Ó|5Û4vXû2*DŸ1E ˆ„í−囈$¨’ĶöÚµ³[G ¦'‘%>c¼ŒYÂ|ÌÄáJŒ.p:Šà—Å·WéI…“P³I|¥‰O–ÏlÓûÛ›O#;Û−BæM¥‹Qbb»³2IɸVÞñ‡ˆ;äNgØŠ=ŠîÂç}si Þ]ÍuqnÒI4e`”Ø_fvï(vy˜Ý·åÎ8¥´¶Ð¬V$¶µ1ˆ§óãÿÊûJ dôJ…èª1Àkz•Ì:ƧwÎslE¹`ë².‡îùb^~Ñ÷·þëy©ÞòM_Lx ó¼Ï{-½ÍŒÒ[š5y Úü˜ÔËò¶~hðFN(ö+k…ÎæH4)ï$»šÝ¥’E*É!fˆåvòÉÙ¸©+»*JçQmo¢ZQÊZÍÂI4$†B†2ìîK9ØÅ2ÄàcŒÕ®¤V’ßLÔÌw¦Ú`Q®_$ˆ¡hp@@ÛÊo“æ N †-¦¼6÷7©Ú¢Ûiï©#°ˆÂ’HLÉ!s˸G±[]…ÏGi´×šâ|L³\B°I"nF(¥Š€AÈÁ‘ðGÏÛ^3«I$‹gø"Vb"Còü¨|«ÇÊ1)Ek[‹o$ù70 yWæÃD¨\çŒyëø×i“‹ø.!}JiåM4ÒZê“1óF>iSå6®IoܯÊ~pGîÖœúÝ„z|¶-}=--´wš„-p%Æý¤—i_p ‹+aw›8A£Ø®ásÑYô™ñÂõÄ— TìP¼Gû£½U{− ¬RÛmÐTs ™nfYƒ‚Æ`þa$qËr0:`WmÚÆMZX®µ,µ;h¿{+\hö3;JûáF−0Î@ë3üëÓP´™ˆˆ%€@0ØÎ'±AsµŠÓBŠ„C,£Ì2n™ä•Ù¶”噋ˆœxéM‡D›ÅŸÍŒ@!¾Cÿ|{œðwúœ¶ñ±Ðõ /,¢–ŠO´9ÂNÒÀ]‰È"8²2v—ã@xƒY‚äÞ¬¯rU®“Ÿ¼Ù=ŠîÂç§-¾‚±Ï¶;.#J0ß2w¯÷¤sÿö«2Üi“\¥Ä¨Ï*Dð«?qÊ–‰Eü¾µåæ[©ô}@Üjw’Mic¬Ñ]I /ö‹¤g!B/¥kÞéñYëE Ö¤XÝÜl}NåÁxÞ¤†ä íÁàçx£ØG¸\é£Ò´ìšÌ6¤`>YUmFåŒ{T¡2e1ÇÝÇ¡-;+7M¶ò−„ª€î%Ë;1=K3ÌO©$יŪjQØO4—3Ko−Å•º°9h ¶rIë±÷°>ŒÃŒ;£e}3ëVñùæK¹$˜_@núgþº'øÒ}®ç?ñâÿ÷õ?Æ€9г€²cèiôˆRcŸ’N}G5¯Ú"òæ…2-´©ÆT†Sø vt´ÆOlna’ái#‘Jºº’¢ªA£¬3Ç;›ë™"9‰®gy|³ŒewƒŒã>õßQ@†Ù³²dûM“` ’`tà×aErfÉ;dçØÓ|©?ç›ÿß( ü %8ÊIÇN vPåËýÇÿ¾M%Á$ÁëÁ®ÂŠãÊJz¤‡ð4”„cÐì( SK¶lçl™õÁ®¸sK@º−¼÷Ÿk’Þs6àÙÊF1ò†°öõ«¥% ’tà×aEqå?d¿Ü“þù4yrÿÏ7ÿ¾MvP²\ýÉ?ï“Ab¸ÙÿëÏþ‚”Sµ>éúVoü$ºý¬¿ïòÿ5¼G¢ù‹Ùßåÿã5ýU¿‹U{(£ŸÃð@¸Œ7œÁ¤%ÈÁäÆ’ê×ÅÎÚ‹G.¢²‰%eDÈVŒN†=§vòà "ääîçÛò:ÿ дbjêÇ/¨i'‡QÔÚݯ‹™¤i-c!þÏÂÁC@`㶒>n1MÕañ †æí6•e»t–72´Kå†þöì€×AöÐJ?üKÿÅÑöÐJ?üKÿÅÖÓÈÇØ.ìËÕôízßRÔ‡öÙƒÁåmwa(¾C8o4 Øù†îHÈ#5RM+ÄÐËs5¬«5ÈZID bê9?þ %ÿâèò ©¡þ¢’ÿñtGƒ?è#þ %ÿâ麗ÒÄF…Û3ŸHÔl·%Òì ɵhšÑãPˆSd\É|Á·Ï\UëQt−ü /…кþÑ—ÍûI÷}ëÿØÿàJFIF``ÿáExifII*ÿÛC $.' ",#(7),01444'9=82•-XÅZÌçÃÔœÛRZ¼~IfàÒáˆÍ"˜c#%éÉÿ HWÿ—Z;¶Öl¢à/Rxãü9éUï|.o"½·ûj¥´ñÎ#S^7–$±mØ`À9þ*¹s¢}¢ò{…º14·-w•ˆLÙ›PŒïÉvÇzÄê ᆅÜ;qßfV‡Ã¿Ù²ê e¦Ék³4‘Û#}Þ ¹'¶$ñÜVzxBCor“êm3Ü4¬Ìé#ã|PÇŒÉ#1ÉÏÌÇïc·:wZT¯e¨,3+\Mv·ÐïU’3"±äíÝäðpN1ŒÐN·ÙÊæHbqr1„бøi§‚o¤§A$IäÇ—SèJ°úŒR^éwÚ™»E·)¥G‡#þ>ƒm“ÔÃt÷ÿF2vœµ;þ)s Ó´ƒ ¶GFB“À;öõ©ZÓB kÿÛè•ŠU¶Œ«6ÒÁruV#·ÊFA*Œ>¸íú³Ï4ëÆó,¤ÅåH ‰C)"SÄf5X-h¾Ÿ;[é–)™−åIgμ¾W¹−·þ-Îq@ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ ?±´¯úØà*…]¢€)ci_ô °ÿÀTÿ Oìm+þVø ŸáW¨ Öú.’féVa¸û,~‡ÚµäÒü9k^n¦*96±úuéU-¿ãá~üs?»ÚÒ3û ?J>¸ð·‰gÔ#·ÐôÕ’ìÛGó¯8o»ê t'ÃzþÄÓ1ïiøWÎñ ÓµP^êKyí.¿^㸯fþÚÔµ€·Õ-6÷¶tJ…ìã±ÃOkÆ¢ÔߟMðµ¸n−´m9âlícfƒ?øíyËÇu«ø¢=

Client Side 466 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Öñî×W8â$ïÐz}Mzå´vv‘[¡"ªÀ ŠPVêkB³ªÛJÈå«ý©k§Mij"ÄóØÁV*YòU@À?:ÔÖÉ—Ä ß,mòû»®?HÍrZÇÚCyÊ°·šöåĪ¬q—=Ýb po|W”ëKë.)è–ǣȽ’geceá IäK−᣺ÅlT„ŒUßøFô gûLÇýz'øWšn‹7Z–›,Öz|dÃÉ”Ÿ)fò£ÂÉ“Ï!Á!N:K¦k÷ºEü6«w;GnÎRòåÊfU‰¢V Hiq»‚B?¥u*½Ñ“™èi¾úK(¬4i.â’‚"ê=Æ2:ÔÿwëíÖ¸=æêÃÄ°É'Úåó Qº•šxŒ26ô¼è‡ýã銧¡B.õ{(-â2H’[«¢È hÑ×q‘Q‰FP7N7 Ër•WkØ9÷=dxkAÿ ð?ð-%è~´ú܃+þ þ€šoþGþÂ3¡ÐMÿÀHÿµh ¯øFt/úi¿ø øQÿÎ…ÿ@M7ÿ#ÿ µ©ê–z=ƒ^ßÎ!¶WDg*N °Eè å˜Æ©k¾)Ñ|3rë:ŒbRDJä—“ÎÕ±ÆFp8Í?þ þ€šoþGþÂ3¡ÐMÿÀHÿ¢Ð|[¡x%mR†ìÄx‹•tô%úã¶7ŠÌÿ„gBÿ ð?ð©õmbÇCÒçÔµ)ÄæHA8É 8¤*A¨Z›}çF¶Wç31ăóÚ€*Â3¡ÐMÿÀHÿÂøFt/úi¿ø øVM§ÄŸ_ê±i¶ºä]M)†!µÂÈý‚¹]§8㜌g"ºþÔ™ÿÎ…ÿ@M7ÿ#ÿ ?áÐ¿è ¦ÿà$áO]{Mm}ô%¹S©¥¿ÚšÜ)È‹!wgêGÍhofÂ3¡ÐMÿÀHÿÂøFt/úi¿ø øU‹ VÏSw³˜J°O%´¼¶Dm®¼ÄuéVË@ŸðŒè_ôÓð?ð£þ þ€šoþGþfçT³´¾²³`—®Én˜'ÌeRì:`aA—Ôe‰}fÏ2−廼u¦Ç«ÚKz−T˹¤x‘ÌL#’Dݹñ‚Ãcä°Þ•—wáí «Öíâ†Bïl−˜£Fî=‰_−6‘Ó/×#ÚiWÑjËw,¶è ¼’µ»º‰·ƒòÈ 3¸e›Ëòí@Mn†èµÚhÒϺ·2ÀȳF%¢gû¡‡U−ؽ³Y7ZuÓi:Å„pî7›Àû€ $`Nyãa−ŸUŒ“´Aqá©n¦);Û=¬wIÒ–óR[Ø®¤W`cÊØ1Û²qÒ€7?´,ˆµ"öÛñì|åýÿüœüÜxÏZr][ÊóÇ ñÍ5¹Û4Q¸g»+(ä:cX5ÓNÇÞ᱂pH=NÓf°¾¹™Œm äÅIå‹o?Ѷ¸ŠîÖ˜|ƲÆÿÞVƒø‚ KT´›imtÔIÀYä’[‰QNBüCâÝ êZ:\‘ÿ*šÛþ>Ñ¿‘®šY,âVZÿ!IòF¿ ÝéWïs]jî‰â9¶á%(¹¯xñg„ ¼¶ycO›äWÏ ÓN©¬è»Nð놺èVq•º¼*©%¹ì åKÄ"š34é°Y]éÖð UØ[XØv¿ò¬²Ú2¯Vum£/1ÄÇ E.§qÿ ¦½®ÊVÁÖÆ×ûäøüx…jÙǨ¿Íÿ −ל{ù#\$W- b8þP8ÅO¥2°;ýëèþ¬’²GÈK0›æÙéú‰.¬ïbÓõÀ„Êq Ú +F‰õWZª '÷5ãwÚÛ´cŸ–L=ëÒÚúP¹ei³»%vîÆðní»»cŠ½-x6ÇXÔâÕc¹¾ÓuHÓÊûnŸ0F9Øù]}˜v Û[Zxߘj·ím!‰éíŒLdßÆX)Xù?w?sR®¿7‚õ¿ÿÂQ¨Å6•u}%¼lÔÉxŠãÄZ°ø¿ÃºF«áèÇúSésH’C‘‰DlG8V$c¯è−smmb×2ʱÚÅ‘¥s€¨rIéÇ95˯ÃØ$hã½ñˆ/ìË› »Õxdá_×ŒÄ æ·õ½=wB¼ÒAŒ _ÓÒÛÆs TjßÛM$gqä-£·“°>Ý›|Œ^ûW3_øÇƺ-„ý曦èñÛ´GL‘C\É2oìA@à.0sœö®Þ[%ÓÚÁáF´xŒ û¦20Wé+˜o‡vb=;ìÚ¾µiqed,ݵʤ³@U$;0qØ€ÏZâ¬W±ðAµYš=FOYïàEFr×[]¶r¸''iÊöäVÄ~կ˽ԗތ‡~g†8Æ9¨¿áÓ?áÿ„?í7¿Ùÿó×zyßë|Þ»výî:tüèÅ>$—ZñE—‡î%71éVrA“wK7˜cÏB«€}@ôd[Pƒ[Òá ñuû ¬µ¤Ûs˜Š·™ Ã+°çc(É ŸPkÐuéºÜú”×ou¿P·†9ÈÅå3-siiuk9f1L™ùS¨q…;òI9'‚EuÖ¾Óà‹V7w÷׺¥»ZϨ]È:BWnÄ!B¨p“ÉÎ\¸ðΕ¡iÏ5ЇEÞ{vV]ÎЮÕòà‚:àlPúœæ–‘F3K@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@eQ@Aþ-¿ë¤óügüã·JY«Âûàý6±þ”«n¿ë¨Çñš'—ç?0ãåoZ¥¨ê7·úe¥¹¸Ô%h£2JcŠ=«¸—pŒÀÇ4—óëÖn§|úf–é§FòL©©É¸…ŒHBæßå"±|Km¢x—Âú…åÔA áóÑ(vÆȲÃÓ*Ãê=ÆgWF†åÝ×·ùþ•Íø›Â÷Î-uqÑG¶±ÛÄ‚ÁY@XƧŸº\õo¼1{s¡ 5k‹kˆÖríæ7™oåÛ Âù³“þîk3S¥¸½¶´@óÊ?¾A+÷•z>óùú›rå†á• 7=¡®[Qð¬“ÜÞx,ZÕ‹˜−d$ ö3‚kyIÀ?|NðÅÄÆd–;?−§ƒn”]¤ä¸Ú>`ˆT ¶sÔ éÒTeOñç x?îz‚29§œpqô>‡Ð×3†eKÙnYmÑ¿‘®¢×þ=aÿ®kü©] {wR3‘_9üP³òÞà…Æ0Ý=+éõ¯ø›¤ä|¤`þUI‰«£ð‰¢†Ïû6û−g+nSœoQèkÓÚkYà\Xéš¹å–æ$2L’~µó†Ÿ+XÝ=¬‡[Šë-µÛ¨c ½ˆú×¢©F´SÜW |7ó´è− ±¶º–I\ §lùA?¼sÀ=HÇZòZìÞ·‘.‚Œcæô?a‰4¡´|ÆXÿßþ†°¬íuá å8ô{ZZ’˜:š}yç¼QERfŒÐÑIøÑÞ€Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( ŠCGã@ EÜûÉ: S.÷÷ûõmÿ]$ïŸã?çÚ±5 [¶Õà’)$†!{æÈq:}ŸnѤ0Î=‰ê¢€.jšÈÓg·`3 ¢yw©b+F½Xœ™GlprEQ¾ñQÓÞò)¬Íj’K›yííâÞ’Æ»$˜¶C°=$^™ï\ðÒîtÝ?}í›K ý•nà‹2ùSÍÍ…åã;Ÿ vr LÔ)=¦Æë,),d4n¡•‡BC\E…¥ÜWºSÙÝ=Â-«I”ˆŒˆ\Œ6~RUˆÎÜŸ˜(6,~Ðç6“\Ú\.fûß^+ß|s¾+EÏÞ¶aø\3^[âêRj*Ö8I‘²¥ÚAìMz_Ão k:P’óY¸„·•åA $°Aœ’N'‡U:\¯rPÄsÇcÑÎiÔÀ;Së”ô‚Š( PøÊÞ=NKY−™cŠûì−'˜¹ ³~í½vsËvçÒ-Eã áYõ›{F¨‚ 7¾õ,›Snæ €AúŠÙL÷2ùÒ-Ä×ÆõfP»£%ÇÝ*#¾ãU#ø}a”Ö 8ØÂ%−öXrV5*¹;wù‰ÝœƒÈ#œÝ az¨¿uã−Õ\µÛ9 °9ŒÈÆ‶ÒAÇ5©¥ß2Á®|xO7K)ÛÉÆ{òEtZeˆÓ´Û[!+J−âXƒ°å‚ŒI¨¥¡PsoÞ−ŠZ¢¤Ô(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢Š(¢ŠCY’jѯˆcѼ§2Éh÷BN6€®«\üàþ¦k÷C{r−Z Ù−î#¶klÕÔ«2±8=ò¢š·Re~„oâÝ;*árr@ëIqâ9tÃ}lít>Óö8Ñ©yËlG`›Œ=ë*ÿÀpÍþEÔ…ó#Á‡ Œó¤í–Ÿ¼ƒ±«„Øh3Yß\¤É|÷é,'AÆr r*- ©UobÄ^−Ó–y-o‹YÞ@Ò a`_PHX2‚ØCzöÆj}Ä6~ [·³IŒvó·É@ùEpFáþ×׿B3ŸuàkkÉd¹–úãí³4¦[…UÃÇåmÛŒ(grMih>‡@Šâ+y¤‘ϸE?’Ú}¥õ1¨¢Šƒb(?Õ·_õ×ýóK*±x0 g$>ãŸòi−ÿÕ7~òNƒÆkRµšMj−„l ?Ÿ¦Ire‹ìତ;zç\0åÖŸg|Qo,-®J°O

Client Side 467 How to Develop a J2EE−Compliant Web Service (endpoint + client)

¾ÜõÆG¿JÍ´Óü9z?Ñô-9±IÿH>WS÷{€~˜¨ä‹VM"ÁlÂ:Ú¨Ù C+l\óQ²sè¾s‘Œ-?OÕmeCgi¬ÛGöb˜KwkóJ›Û¸KÀÛ¯~Ðåg°Ò;œybe\«„l°á›Tû’û‡¨¥VW'c«ùNÓœt>üιíWA›QÖ' U,¦„˘»Øð‡=ÏîÝG§ÉëÖ”nºº–Ÿ;™#IŲ}Ï—n#®FY„lT‚â:Õ{Kû−A\Ù^[]*Á2ÈÓ;IÇ~µá;í=‚ÝAÕ:-ìRCå{åÙÈvòGÞ8!éc¬fEzÀù?iUºæá„„Èb;ÆÐS ÇôÖ3*!v`ª ’Äàîh}k–¾Óõi®' Ó—Àsr ~I³)å¸ÿh;³·§;‡Ý«v6—ðkåÞ9ͱˆï'Ê¿"€ ÕxÏjÒ°,êã{rä¶À¤d`´ŒŸpA¤þÑBv²“ ÈæTT¿$Ï>€äÐw9Æs”åFvÚ “éúÿ,ÖŠji›vpw,¨ïÁ9!÷’Øöèj¤Æ„Ë)ˆ÷ G=Ç_ÿUDaD%+ò`ägœvüzÒ$RHû 63€?Ïù÷«iuÊeù˸EuÀùB²’AÏ'äé×-Œ*ø8#¸ç“ß\Ī÷ö1T .È€a½Cù»ú†Ã+qÓ¶+¡Òmu[;UÔZÞayy¡Û[Êá¤yWèßÈך^ÿÈBëþ»?þ„kÒíãå~üyùÅýÙÿ¦Ïÿ¡@Sšv‰ãŠ(dâRDPÇ€Ì@Éä’Iâˆgw’H8 ó]+išj^o x®äǶåâò›m¹oÑ£¶UG‰‘©,¹ 762GkM6ÚŒZeÓé€ýºH‡ò”*ªµUCÇ'¿Ö¸ùõ[h|;«ÅiwÚ'¶−d³Õe½w—„ŒHø++ùUym¬GCNµ»™¼eåGr¬´®VxÆ¡+ºÀ#—nmÈ؉¸E†®ßïP3°Éõ¢°Xλ"]]ÝG}ö•ÐE!-ð¹o/;Jýü¹ê¨Á¬ê—8.K$$¿¹ öGy ¼xõ 3†Ë ääp@:ÜÑ\IÖo㹸’kù£/on¡´Ââk”.7 ¨Xƃ$0bê d¦Ù-5}Vú+YAk%ÌQK."ß´›1)U p¿?Ó4ØdúÑ“ë\Ulj5}×ω+ Ÿ—ì‚_0/ßÿ\vdœmûøÏeI–Q,ƒïH`cì2p=OÔõ öÅš( úÑE−¯ü|¯Ñ¿‘¯4½ÿ…×ývý×¥ÚÿÇÊýùó;ïøÿºÿ®Ïÿ¡HefŠ7ff‰$’ ’iÃqÀ®¾îÛJ³šÚÜi]OýÁJ†ÆbËŸ÷‡¨ +jú ]£Ð~UÙG†fºÖ),âEÜ‘−À.ãØnÉ[Aá›Èå–Õì'Jñ\¤ xr}¥q›WÚ1×â—hÆ01é]céšyñ´)nCÛ³• pNNZš;]Eƒm˜−=ÃÛ,xmÁÓvðFxcsœtÆr2Æí°£hÎp3×8®¯w‡šÆæȡ@$“"u `öäS£M mÁ»±ÝQäå‚6C‘ÉFsxéH(…−v_gðÖ−Îë\ÿ¨?h½ÿwæù¿ A†L³ÄÀÉn32 ˜ÇO˜gÆ€8ê+³¸´ðí¡arl¡*ÛXI>Ü63O\sŠo‘á—/æX¶;g?hˆôÃ|ß/>´ÇQ]F«g¤ŸÏ}§¤p¦9¡}ãïÁÎ=k{]ƒÂ>†ÏízL·¿d-½¥œO4Ó‚ÅQNHQÉ=G-yÍév°x ëF±ÕÕôøìoˆ[y¦œÆ$cŸnaód·®A©¦Óü o¨gÍ.•ñtŒ[=ØY7·*»Kg'°ïÚ€¸ä−Igm1œÒ”“êx¬]Nä‹î®ÞÂÊh%’YVo$‰Abo8ìÒœwØ; ¬Ü VÒÓÎÑþÎ¥^Ó‰ E¡@ÉOº(¡Ëæ’xÉ®.ßÄZœÿØr]\YB'Úî_*ÚÉ5µÓ±¸±ÃAG$²áN߇Å×-§^N»Kf·RÔ̹ +Œg½Ÿe=;ÍŒdõÏ^ô•ÈêÞ%Õ4ǸµXmf¸·–T2acB±A"§ï%]¤ùøÈ,vHB ¿¦Ý\]É~Ó|¸®ä‚v£–$õ>€q| ôQEQEKkÿ+ôoäkÌïÿãþïþ»?þ„kÓ−ãå~üy–¡ÿ·õÖOæi ;−CF:å¤Í=ÄÅgh„~T2$–¯k:hÜÀ¬ÝšFÙ“.íä²¹êOÌsšé¼Gªxk©cý£a;›¥b@Ý»sœ°þð¬/øX^ó Ô?ïØÿâëXÒ©%tŒ¥^œ,¤“$¸Ò/§¶Ôì¿Ñ½ËÍ,Sbû¤mÛJí€zN}Jdú>¥z÷7$z„ó)F‚V”EŒDøfEÜÛrÀÆåPN2i?áax#þš‡ýûü]ð°¼ÿ@Í@ÿÛ1ÿÅÕ}^¯ò²>µGù¶þþÚãO(lMÄ7·Î¢/.(ãUòîÜþèìsÈÎvóQ´Y-ìü=¥E´ÎôÅÚ Ïó` # èß¾Ïb*×ü,/Ð3Pÿ¿cÿ‹¥ÿ……àúêsþ¬ñt}^¯ò°úÕæE™¿äk´ÿ¯V8SPˤj),º…œðŪÜi%BlÊýôÂHÃC`Ùü'ÞÞû*ûx å éôïøX^=tÍCþýþ.«ÕþVZ£üÈ‚O Ë qÛZ_ÜIjÂÖ9â@Œ©ÈêQ¢EmÛDƒvrI\8’ JO"I¢©rT®OÌA%™ÿð°¼ÿ@Ëÿûö?øº?á`ø#þš‡ýûü]W«ü¬>µGù ê8ìÅ´VðHÏ,‚öw+™Œ-Àý ÍĘÃ1aŒàC/‡õ ‹cfíjÃÊC •™œÊá¾e(cá›51ø…àúê÷ìñtÂÂðGýûö?øº>¯WùX}jó"Km/P}quKÅ´F>p MƒÈò¸fEÉÎNp8?œ'D¿m−=…·úÄ`xî¥åû¾gU ÙÜG©§ÂÂðAÿ˜f¡ëþ¬ñtÂÃðGýûö?øº>¯WùX}jó!º…›Xø>î'ˆG#7˜ê.$Ÿ–L’|Ì}I·ºhºÅÞ¡¢ëZ Ö"ÿNIcòo·ˆ¤IUCe(¤që\»øÿÀ²!I4›çSÕZ Aü7Ö˜ø½á¥ mH0’¿üUW«ü¬>µGù‘SÄ~×u»=5å¿Òouìe°»kÛCå"ÊAi¡Uû². â›wðÎîOí¿.k9¥¹]2;;›’Lª–Åú—ýù_þ*ø[þÿŸ}Gþü¯ÿGÕêÿ+-Qþd−¯¯m® ”5Š•×o5*X†T™Q~ï,µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ

Client Side 468 How to Develop a J2EE−Compliant Web Service (endpoint + client)

·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæG1Etÿð›|>ÿ Ïþ¯ÿGü¿ÊÃëT™ÅÓÿÂmðûþ€W?ø¿ü]ð›|>ÿ Ïþ¯ÿGÕêÿ+-QþdsWOÿ ·Ãïú\ÿà:ÿñtÂmðûþ€W?ø¿ü]W«ü¬>µGù‘ÌQ]?ü ·Ãïú\ÿà:ÿñt}^¯ò°úÕæGMEV'A¿ýä±ügüç¿Zÿù}ô[ÿ«nŸë$èsümDßëmùëSþÃФŠ9Ç,i"7Uu ~†«ÙZ[[î–hb“s¦äˆ)Û¼ñÀö\fŸ{,ÛnŒ€æHÓ%w`3ª;ðMehz¬—²ðÜ,[îTÇ%¹VÝÁ ç±ËdvéÚ€2o>èךÓj—W»1ó[yŠ"ÛÏÊxÎÜ™éÇJìR ®Ý¤¸èGl~¯?ÖyßK –Otw·f?ü×e,E(Å';?™æâ(Ô”ÛQºÓ±ŠÞÒmî®^{[ ‹kgplšãl–Ï4â6ØÐòÃvÛK’ØO`−ÞòÉ#î}ÊxÎr×d>߆x—æÈ`|‡È `¿ØqMoƒ·~ZÄÞ CåPÛ6Ð}†ü pÅQRRu?1OVQqTí÷Ú†‹öËM6 ]>Þ−FþX“UTˆfÄàyg`æè]ÛýÜc¨Úfúå•ý¼zcÙ,W‘Kötâ%(¯$,Ê¿)mœàà’‡ëS„wêÌÃĸfÁ,−Ø#¦~~Ô‹ð‚ò5)ˆ‘œ•[vðG#¦Gâj"‹ÓÚ~ ¥FªzÓüŒù´M7WÖ´˜ÊCöi,$º¾–¿e[æâ!*Ê:í Ä 2ÃÂZ\þ"ÔlM½ìûR‚6IâHšBw+¿”[ãk2¨#$ôÍj/ÁûЊ«â ³¹T[¸ Þ£çàÒ„Wë+Jÿ¨ê*¾·Oþ~þd¬4ÿç×äaE¡h÷>!Õmm4Ëû”ÓîVØZGp]¬mx‰V7á‘mØ+}Fü.—JŸ˜,=N´ûœÎ· YÙøVÃR´µ¸Bæ5–[‰$Ffd,pR28ecÀ¡t < 5XmîÒó\Lò"'ï6üŸ»Øà:8=}+¦?ïÄjQ>ê›f!~ƒ~àýß”"ÿ„‰|¬çgÙ›n}q¿-?®RåKÚk2~«S™¿gÓÈ;Ê¡biÿÏÏÌÑПüúüJ:‡4›MI†].âê—bÞÉ0ò/IƒÍ «¸nS݉â©[ø_M¸ðÍÆ ðÝÛ\=ü¬K+YÉ K” 08ã³ð‚óçÄK¶3˜ónß'—çã×-8ü!¿"Aÿ D‡çgoŸëóóGÖ©^þ×óÃÎÖt¿#ç@°²ð−ýäV’Ë#ZZL·îÈÑ»3ý¿?ëÐÿñthῘ?³ñËùaEzxø3pN?·bϧÙÿGü)›úÇÿ€‡ÿ‹£ûG üÁýŸˆþ_Èó +ÓÿáLÜÐv?ü?ü]/ü)‹ŒÿÈz/ü?ü]Ú8oæìüGò_Ezxø3qŒv!ÿn‡ÿ‹¥ÿ…1qÿAè¿ðÿñthῘ?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒû?ü§—Ñ^¡ÿ bãþƒÑà!ÿâèÿ…1qÿAè¿ðÿñtia˜?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒû?ü§—Ñ^¡ÿ bãþƒÑà!ÿâèÿ…1qÿAè¿ðÿñtia˜?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒû?ü§—Ñ^¡ÿ bãþƒÑà!ÿâèÿ…1qÿAè¿ðÿñtia˜?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒû?ü§—Ñ^¡ÿ bãþƒÑà!ÿâèÿ…1qÿAè¿ðÿñtia˜?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒû?ü§—Ñ^¡ÿ bãþƒÑà!ÿâèÿ…1qÿAè¿ðÿñtia˜?³ñÊy}êð¦.?è=þþ.øSô‹ÿÿGö–ùƒêåˆsoÔ²…½;Ásጕ“Ú9ÁÈíh¨íæ[›hg@BKÈ õŒÿZ’€ (¢€ (¢€%µÿ•ú7ò5æZ‡ü~^×Y?™¯Mµÿ•ú7ò5æZ‡ü~^×Y?™¤¤xîw‡LðúÅ°ËÀ=Àär1šóÄÒ¼Es«é7Ú…–»$«6š÷“ù²²%àœ¦;UŸëó ™Sz‡Šµ©ô−7J¸·¶K‰'Ô−m °É #…b¼»ã'óÅsÖbºÔ²té×Mxí€ß ²\KnÁþl¾0ÜœdÖ2rOD3;Ãø«ûNÓþíØæZ4>Dj #Ë“Ï7ÎH“!v^ƒÅ½åݵšxJö½T\ecA$v6Lûà˜èGñìMüs{׊ ¼Óa†]1âŠÆØÍ–¹2#°,F@WyÀùP1?t‘bÇYÕï|)iªiÚE¼Icmu,þHxÜIwX£¥Š¶ Ë€s–#?uö„ iá6îeÜSÆáÀ]§÷…ÎCÚ ¯Ø_YøOÄ·š%•Æ›ªÞA¾ÛKK7‚+GX¶Æ«æª‰$8ÜpH°,Û?‰:Þ¥§$zm»År¶ÃÈ‹qgimZ|¬ÌB+˜aóg®jÿ.,5 ˜áÓ£òm´››Éiq!¸ˆFÆ”‘…a˜g, l9¦§µ„VÓ¿á#ŸÄ–jdÖ±VK¹#k$e‚Ãnco±æùØŒŒõZÎð¿‰|A2_ú£~ú]²D Æéë¥Áv8ÆØ÷ UÇîÊØÔ9NË>ÛL¤@ä’#ÉÅPù±/œ0HL€ŠêuOˆ:‡Úæ‹DѦºÄbhË´ÓEqP‹dgj‚1Un~#Ïe,v«öG– ójhðÅ"Œ¨‘Ù[q9o”‚J»Ïù@ÍÖ¬üQªè¾'Ó®WÄ©¸¸X"Dv’[í‹`ÏÝ,~o–6,rá.·7ÿSM'ûRM8JÂú†˜šm”±Æg»šÆY¥’f5A½JnPÅêÑN³[-Ó=»¸š#;$›‚ü‰¶0šL³v…Ín\xÓÄ−¨ëºm¦€MÕý¥-²ªöÇ.Y¥—kbä`ŒPOSPÚ|G–òúÆ;sm5±û2ÏpöÏ Ê÷ "¢(ÞÆ"¦2>`á‰Á(â{ßʃB„:¶¹§xO^þÚƒWœµ£D—wíŒHa•™7»j«gˆ’»zšç5ïÅ®“h.tíVs-Ò‰nÍl,Œºœ¶¨“I ¬vþp‘Š˜ÙÁœÄˆÊÛîàÚ—â½®¡eèЬ~döáîîÈxm¡–FS,¡å#hʳ!bö"çOH\¿‰â™×ü$ƒGYnWý%7{þÏ–0‹Œy¿hÁÿS9Ù²™ã»gÄR ÐôíNÖîÞÊòÚöyãXþ×m„ݬ ÈH(FÃiô/‰×zÓéYµ·¶CmÛî$òIùeI)þ«#r°%¶–@7µé¼{©ZÚx¦K-.Þ .eÊÑæù¥Ýš7q ¹ Ð àµ/};ØjëJÖäñ\šÕ–ƒw˜tˆ−Ê–+ShÀ/ò„¬Nxd#µUÓô?øz.k]>h|ý+OIÿ³-"H¦ágUÜæp¬0àA*ç8ßo¢Ö4¨® °·¶º–BÉ$Ëq;Íl‘µº°=5´ÿëzݵq§ÙÚÄloF’+K'ÙÚ‘Xǹ3!,2¥“g#æ+Ën}heXÉâ说µI¬\ÆáDòL8Spä»6N"Ø%Ä`«Ü*……Ç]6I“XuŠk6ÕCFy“ΔL# É´ÅŸ/)Œ€ -#ñT[tÔåÓ£·ÓšÊaÝnì/gkw£bÊ»wnCÛ5í>$kcTÒ−¯-tÕkæ±Qljç(íæFK·ÉÚ‡†ÉÉÊ“´—d−9¼{'…u«‰ÿ¶F«ŒdI³K/…èÎ# ¤|¸äŒÞÖ¢ãÎM›—ù{w…óöŒXô-$øƒs¤]ÞØxÚÙo PÀÂÉ’9–•ñ´y−‡$Èù®§‰õ=KZÑ`Ò%´k}VÐßyW6n$µ· >wq.ŒŒ (QÔò1“>õþ£k?ZiǦbÒ%s, XV‘õIw7*r|‚¦Ò Š†óTñ¬~#½Ò-.uV¹‰${(BÞ(Ô6Fï¸r†o…mt-NÂþíåb¢òkInäÒÐÁ•UIS¥£aáë¹4Ç…ÔÞY¼«;Ël²EP'Ì,û3¿§E9À·¤ø·Tœ:E¦‹¦XD×SéÐØ‚T[ͪÜÒ'ÊWs!Pzäô4ù-°ÖÚÌ>0Ô;û»6mE®DVäI42!jðZ»AŸr/î"¿XdX.ⵉùi¿ 3; }Ì¿! ÜM®xï[Òâñltë»UÓÞôÁ¾û5؆šWŸ`п¦i‘Åñ.kû .îÖ‚åokaù¦D*Ë Î†nYöŒ '"»šóÛŸkpiº” ims§j2iûR–Ô&Gá%K ±gÛ³vÎÔ‡ÆÚÕî¹5…½¶›Í6¡om糨…íY¼

Client Side 469 How to Develop a J2EE−Compliant Web Service (endpoint + client)

Þ-¸œ\c»Ö3¥9»Øi¤z¯+¹ø‘®ZÚM;YXP@ ŠÕ×¼e«è—ºœ>VŸv−ÑîLY´“Ç"WΙd2l ŒÁ«?«È|ÇŠ1^xþ2ñ Yy–öú\×êsi¿eA.¡$s>RîÄ@ g,Æ@1ÏšM+Ç®©s$xÒ-£–Öæîî ªZÇ×æC»÷Ÿ._,d`õÜÕä=b¼ÂoˆÚÄ1Å+X[ŠÞ©wÅ"5ÔrÞtd³T 0Ûþðc‹u˜ÑÚM4ÛO–g•s·ËÇp7 >¯ ¹è˜£ÀYxËX½³ÐîDZvëû“hlãYiÊNñM*sˆãEQ‘cºtZ¨¹¹yv°4ÎŒ®7~õ€NA‚OAŒêòcÒ±F+Ììþ k¯wgö“mhÞfŸÕ³ïó ÝcÅ) 5ºËáÂ’åܹé8£ç–^7×ouŲþͱ溟OKiebÐϪϗ•rrJì[¢Ü,˜³i'(D¯œ;2ÈdØ!ƒToã/µ—™oo¥Íq§6›öP$êG0Cå.ìDrÌdð ¥ì$=b¼ïJñÆ«ª\Éô«håµ¹»†{‚ê–±Áuä9îýçË—ãË=w “|FÖ!)ZÂØ$VðÝK¾)®£–ðÛ£ −˜r I†ß÷€ã/êó ŸŠ1^w}ãØjÓií—:µÕµ¢ÝAæ4v“M6Áå™Äe\íòñÜ Â¥²ñ–±{g¡Üˆ´í×÷L¶þ»I«È9ÿb¼×Gñö¯ªÛé±Ë§Eª‹›‘'—kLèÊãwïXàƒ$ôÁmŸÄ uîìâ¾Òm-ÌÓຶ}þa{§‘C©Ïîð[c+›‚3GÕæǦbŒW¿ŒuÈï—M ¦M4Ú„x½†)ZÞ %y#Á`f1ˆÔ œ¿ +PÛxó\¹Ó´=V+−>HuÒXG#™Ö5W2Î_îÆŠB ¶ìãp$ >¯ æ=#b¼ÇMø-_µ‘‹NêõlæK ˜âIí¦Ÿi~X¯’WvõvvŒ`À>)ê×[„ ·aÏ\ö£êó £ÕqF+Ê−~#k×ǧ›}4^Ës-ȆO−Q¬šçg•ædœ¡]ÛÀç;xÁŸþuñ±þÖ:u·Øü¬ý“sy›¿³þÛŸ78ÇðmÙïÔ}^aÌz†(ÅyEÏÄ}zÞi4õƒNkØ’IÍÏ•'–ȶKs³Êó2 .vò8ÎÞp6ì|°Ÿ÷$Ƨ€UDÀÇ−‘ÆÒ xy9¡EW¢A¿ú¶éþ²N‡?ÆÔMþ¶ß‘þ°ã'ý‡¢õm×ýcõÿ|Ñ/úØ:ÿ¬9Áÿe¿Ïÿª€%¨-Î"lcýlyÞÕ−WŠh‘Y^@w8fïŸOóÒ€1eð†qs$Ík¹¤vbF¡x2O=lÃa[v¶âÚÂÞшq ) ÏpªëõÉ뺴ú”a-™×HTbòÃuåµË•Ìq–ÆŒ2w“•é•4ÿêwk¥ë =âÙ[Ç%²Or‰ Eš!䪲€$'ùÊš˜¸5x»¦š:XtË s†Îò û2b1òÅLcýœ€qÓŠ-má½ÍÃÛi6‘8à2Äû…?ôWèk9¼LÖVìnä‚gk…‚"ÖòØrQßçI·2ŒFØnA'«cÄHö—W‘ØÜ[x‘ÝÜ…`ÍJ©ä|’§¯!ìM°š«*ivk ŒDˆ}Лÿ¾>_§*3á}ÈhgåÜWÊ'nßýãéÅWÔ¼Iö!z‘Ú»=¬7r³’ ¨#bJä“*ŒØò:„°ñ“]5Ý¢År×ÒÛÀ±É¸H‹,˻تÀ䃌‘ÇP´¡g$Ä9ÊygóC·éÅ2?èñGåǦZªm‘0#‰+ƒþò¨Ô+JŠj"ÇÆŠUÀê( Š( Š( mãå~üy–¡ÿ—ŸõÖOækÓmãå~üy–¡ÿ—ŸõÖOæi−ÀõÏA£M¤Zp)µxdŒ30ÌÁ‡–^XîÆœúåÒÛáå·Ù.”(Û(·‰ƒÜ1i"‘¤òÝrw8³•`I8b/Š4-ø~;O²-Ë "‘ܵ»!V:H •qÔ{õ®zÓÃ>"};B‡R¾réÚçÛ7Ï6ùÔ$ŠªÎoœàuÇjÂV»»«5·…fÕµèœ|¤ãoxõàÓÈÌ’3 RY%˜’䨮´¿‡ˆ¿á#†ÎÈÝK§K§=«]²ˆ×Ì/›ösèË3Á5Ç\| Ô®ãŠM>x泊ɤ—z´‰¼!N |ëu럕ÉäŠv‹Þ@u ÃÖ‡SÕ¾ÑKq‹»„¹™D"wY0Ãfç Ãn0Ä‘‚NRM?áà–¥E‘üù`’âCq(—Ì‘$ Ÿ8ùŠX«îè{W''ÂZãN)SKyfYµÐQG´Ÿp±Ì¯€Ù?•åw¿hÀ ·n0+¢¢—´Ÿp²9ÏøA´ñJ°]$ñI,«€Rú3i1†ÿÚ`ûdþT›”)ýÞý£0Ü ¸À¤ÿ„Aß«ÒO’ʳǨ\$¥ä ‹‰71!Td“À¥ttSö³îG5uà ÞÉt÷ÿj @º˜Þi €øBåâ ç9ÉÌ—>Ð/V1wmsq±ádsçÁZú3mpb¾‘¥¸ˆßNQ¤g\.ü+nPCÇS"ð6ƒÌw0[ÝÃ: –−Bá¼Çó³ bÍÉ'$à€ÑÑOÚϸYËøÃR%Ê6œÛ.2EÔÀ(2ùÄ û°dˆL@ô©§ð^‡u,ÜÛOq$!@i¯'¸Yà;q]{Y÷ #œ‹ÀÚ&Mh¶÷~A”Lµ– 3ÌLÈv>þw.'M>×ÁZս͵żÖñˆ£h¯§L¨sû…‘Ëÿ½ðÈ@‹§ÊZ2›/'SÙÑP‡Êª³– ¸\àã‹'Áš_C{%´Ò\ÅåŸ2KÉœ¹Œ±Ÿ.w²—m¬Ù#Œ7è§ígÜ,rh6ÖXÅÚÛC"Ë h\%×8hÉ“(~fÉR3“œÒÙøÃú|ë−¥¤Ðbà1Çy8㌨ɿk/'!ÉbNI$ôTQígÜ,jønÞÝa†Êx˜ÊH·³‰Sb2 Y7ïU ì‚ñÍ=| á¤)F”„D¨«‘ÌGlF%−mŒDd®â Ç~+¢¢k>áds ðûÃ1ÛˆSO‘pÁ„¢òq(ÄF ¥ªK3ø‚Ü]3é!òÕ°™‹øT à »;ˆ4Ôˆ”ùw;¿í n]ÏþKÿÄÒh[Ÿ.çÿ%ÿâk€ºñÎ-ÛÌ2XM œw’¬Â2Vu„BA\60LŒ§ôõ¬ùüW«iÍ=çÛyæþ1æ³ùh"–(ÐÃ…À{g§=Í*Íâèz‡ö…¿üó¹ÿÀIøš#¿´–å−Ã:LêYH™ ŒãpÆGç\uψõ¨NÑ/I™ ëÖcÊ]—0À' jQY:Ö¶4„|A-^t¦Y¼”7ªÍƒÕ›Ó€¬IΪÞ)†−5nØn‹NÑãM¾*#Þìͱp@Æ1–Œ—dtWu‡Ëåü“»…VojØÓïý’\ÌlK#ÆNv:±G\÷Ã+ ûPš(¢€%µÿ•ú7ò5æZ‡ü~Þ×Y?™¯Mµÿ•ú7ò5æ—¿òºÿ®Ïÿ¡Hj»²kÛãK©íd\2ÍBê@ìY}zƒT°µúµûõgÿÆ+Çüé¿ç´Ÿ÷٣ϛþ{Iÿ}š`{ö¡ÿCV±ÿ~lÿøÅØ:‡ý zÇýù³ÿãä|ßóÚOûìÒyóÏi?ï³@Xöì−Cþ†½cþüÙÿñŠu¦ƒ,:¤÷:Æ¡zðFéN°*øÉýÜjIùGZñß>oùí'ýöhóæÿÒßf€=ðqK^çÍÿ=¤ÿ¾Í/Ÿ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4ï”WùóÏi?ï³GŸ7üö“þû4é4QEEoþ©º¬“§ûíDßëmú¬=ÿØz ÿTÝÖ?SþÙÿ>ÔKþ¶¿ëö[óÿ>”−APº–x£cæH +7Ÿ_óúTõɿ뾌ÿŸjá/¼1¨¢ÄÖ6† ˜®QJʪ(À ‘»¤dðØ z ?Fi−õ¼·0C{*³A¹w2Ë+…Êá*À3nœ‚Äñ/ˆ`ÑZÅZéÉtxàUyLf7è e¼¾NÝÉÇ4Xøá¿Ôg‘.ήŠDÀÞS°ÁÂîVàcO±¡Š„c?Qn¼)eqx^'{KY−æ†{{m±«ùR·`Hö·ºAR ÔŸðÃ3Þ½ÕÌò}¦Iœ"° ˜À¶Ü‚A¨#;xÈPI“n¥#€xÇ4ȼAšÏö{BªMÔ–ˆÞz–gEf$§UR°O·-flO‹oÓ\E−™F•˜YwI$˜l áZiq´½Îí«ŒÑà-1mãîcîJà d’Ùø,vq–2• ãýX꧊¶5Í8¬Œ³ÈÁ Œ−¼„ɸíS ™A €Sp'¥Cqáû[©®^I®vOæ~è2…ŒÈAv_—vIQ÷‰¶)ooð‡‹Ê”Æ≔@*ÀõÇ9ÀÂ>‰ovÊÚ¬²jûª‹øáePÛs…DQü8Î3Éç'ƒT²¸µ’é')K¾I'¢

Client Side 470 How to Develop a J2EE−Compliant Web Service (endpoint + client)

˜Îÿœ—Ãå#¡¨_XHa¶’æÚx1¾GrîØí–f8íšÌ“ÄŠ šGj¾mÂÎY'¸HDf—n¹gõwMÕ¢ÔÙ‘)Kkÿ+ôoäkÍ/ä!uÿ]ŸÿB5év¿ñò¿FþF¼Ò÷þB_õÙÿô#IQLŠ( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( Š( M¢Š((?Õ·ýä±ügüç½ÿ-ƒùh{gøòúÿÿêÛ§úÉ:¾ÔMþ¶ß§úÃŒÿ¸ô/-W†Þ¥…Ú8mÈ9ÏOçÁ«¸ÌmŒæIÓ×{P™>“â2’¥öu(L"™DS· ÏÁóÜôcŒWIáßK†uêì› ‘½f˜ÛaœÈ±äm‘AÆs•E.G¡É8©¦ÖD—P¾Ÿx`µ−ç»_+ÊGeFoÞGïPp‡’}(NŠ‚Îê;Ûe0Ê *ÈøÜŒ[dG8$`Ôô−¯ü|¯Ñ¿‘¯4½ÿ…×ývý×¥ÚÿÇÊýùóKßù]×gÿÐ$QE0 (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€ (¢€=6Š( ÿTÝÖ?SŸã?稗ýlÖÿì·çþ}(ƒý[qÞ?lÿ>ôKþ¶?å¡íŸáoËëþ4−W†$pÌÛÏÎãýao>‡Ÿ‡OZ±QÛ©(F0LÆ1üf€Óu Ú¢y…qc…c'>¸«¶šÒ¶‡uª]¨H-ÖY_˳商 ÎäŒÉÆx-çVu"œí¡„i·R´þµº‚fšB‘ÙIjÅ8,]ïƒÈ fà‚ qŸº3ü"ÒùGn¢‰•ç·¿òºÿ®Ïÿ¡H(¢Š`QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzmQ@[ÿ«nŸë$éþûQ7úÛ~ŸësþãÑú¦ÿ®’wÏñŸóÝ(—ýlõÐ÷Çð·çôÿ –£Ú1 ÃH ’p²Él“ÇÔþuö£g¦[ý¢úæ;xs€ÎycýÕYe'°5Ÿaâ6þD@ÒÛ™[l?iM‚cœa[${/ pNåìÞ¬vm\äoµŸ²xo@—F…WVµ†]ã eläFSò“NÜ÷ˆut−4_Ûx®ÂÔOÔ mi$Ðaô”¾×?3€ò1 ãi8ë.õË;–·K1bYdò-f•Q `Ùª‘ú‘€§µ\£¾Õ‘ö†Ú'¡ú{ô¥NÍ4íþ!'Ìa]xeÚ…”†–XgŒyóœr©Àèx;94¶úÖ· Ñ"¨'ÃHÆM²4˜!™ƒòí‚ã*X²œãBxLi š3‡j8q†`s÷‡àô-h´Ké¯":ƒÏ"5ôM9K¢¡[„€ó'9Æ9®šŠÃðõ–¡f‹öã)i,−LÆI„„ÝþóÏ=Oý2ä|§ërŠ(¢Š(¢Š(¢Š([_øù_£#^i{ÿ! ¯úìÿú¯Kµÿ•ú7ò5æ—¿òºÿ®Ïÿ¡H(¢Š`QEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEQEzmTÔÆl[ •ó"Þ'åówNqŒô«tt9{P? -ôw[§û/ÚÚNbÑ6y«å‚ ÇÝÆ:ƒs\F¡¤Ùéú ¶Ñä»qiÙ¤3B’´®üÜ…PfMÄäàü‡hcëyã©ÅP¹Ñt˻ϵÜØA4ä,ëØeOóÔƒÛÀÄT‹’²* 'vsNw/€ub®ó%ýŒÂÞÐ1r¬cu8bK:|¼¿{ó¿w »NSÃ"Ir®¤óÂ÷ÔSŠ²°›»¹Ä-–¹ 6©ln!‰¦Eò dÚÍ((Ljá@ÙŸ–L¯¨ÍX¸]—Yº·Am$£2¬…°Ô ÜJäNTH1”㮢¨G.ÑjÑÉd¿ñ0qÌÈ©æ6WèßÈך^ÿÈBëþ»?þ„kÒíãå~üy¥ïü„.¿ë³ÿèF’ (¢˜Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@Q@ÿÙ

Client Side 471