On Performance of Enterprise JavaBeans
|
|
- Juniper Sanders
- 6 years ago
- Views:
Transcription
1 On Performance of Enterprise JavaBeans Radek Pospíšil, Marek Procházka, Vladimír Mencl 1 Abstract Enterprise JavaBeans (EJB) is a new-sprung technology for Java-based distributed software components. During the one year of EJB existence, several implementations have been developed, mainly by the leading corporations of the software industry. The goal of the paper is to identify a set of criteria, which would help developers to evaluate specific EJB implementations. These criteria especially cover a particular implementation s compliance to the EJB specification and performance of the implementation. Experience gained from a project 2 evaluating several EJB implementations is used in this paper. 1 Overview With the expansion of multitier application architectures, the enterprise software providers focus their attention on the request brokers, transaction monitors, and other middleware services that facilitate building the multitier applications. In response to this demand, Sun Microsystems introduced the Enterprise JavaBeans (EJB) standard, a component framework that provides services for transactions, security and persistence in a distributed multitier environment. As its name indicates, the standard is based on the Java programming language and runtime environment. Since the introduction of the EJB standard in March 1998, a number of companies provided their own implementations. Typically, these implementations are offered as a part of the existing application servers of the respective companies. They differ in many aspects, from the level of compliance to the EJB standard to the class of performance delivered. The goal of this paper is to identify a set of criteria, which would help to evaluate specific EJB implementations. An extensive part of the paper is dedicated to a thorough evaluation of the individual compliance points as defined by the EJB standard. This is necessary especially because both the EJB standard and the EJB implementations are still under development and thus the compliance points are often not observed. Apart from the compliance with the EJB standard, the paper also proposes criteria for the performance evaluation of the EJB implementations. The performance tests measure costs of elementary operations (such as an invocation of an empty method), and evaluate characteristics of the respective implementation by observing dependence of both the costs of the elementary operations and the overall behavior on the various factors involved. The characteristics evaluated include scalability, robustness, and overhead caused by the use of various features of the transactional subsystem. 1 Mgr. Radek Pospíšil, Mgr. Marek Procházka, Mgr. Vladimír Mencl, Department of Software Engineering, Faculty of Mathematics and Physics, Malostranské QiP VWt3UDJXH {pospisil,prochazka,mencl}@nenya.ms.mff.cuni.cz 2 EJB Comparison Project, carried out by the Distributed Systems Research Group at the Faculty of Mathematics and Physics, Charles University, Prague, Czech Republic, and sponsored by MLC Systeme GmbH, Ratingen, Germany
2 The criteria proposed in this paper are based on a project evaluating several EJB server implementations. The results collected in the project have served as a proof-of-the-concept for the criteria described here. 2 Enterprise JavaBeans Sun Microsystems Enterprise JavaBeans (EJB) framework is a component architecture for development of distributed, -oriented business applications in the Java programming language. The EJB specification [1] [2] defines a standard for the EJB deployment environments, EJB servers, and for reusable components that are executed in these environments, enterprise s or s for short. A implements application-dependent business logic, and is typically structured into EJB s, or s for short. These s are then associated with the EJB. A container provides a deployment environment that wraps the s during their lifecycle; every lives within a container. The container provides services that the can use, namely transactions, security and persistence. The EJB specification does not state the way these services are to be implemented; it only specifies the interfaces of the EJB container through which the services are made accessible to the s. home EJB Server EJB container A cc o un t family Client remote wrapper Ac co un t wrapper Ac co un t (pooled) home interface home B oo k st o re family Client client contract remote interface remote wrapper wrapper Bo ok st or e (pooled) Bo ok st or e instance container contract unspecified interface Transactions Persistence Security Fig 1. Structure of an EJB server In general, the protocols that characterize the dialog between a and its container are referred to as the contract. Furthermore, every has a deployment descriptor, a description of the 's characteristics and the 's usage of the services provided by the container. The container also supports a set of protocols, termed the client contract, that characterizes the dialog between the clients and the. The client contract defines two interfaces that the client uses to communicate with the : the home interface and the remote interface. Both interfaces are created at deployment time by special tools supplied by the EJB server provider. The remote interface reflects the functionality of the, also called the business methods of the. The home interface supports methods for creation and
3 removal of EJB s, as well as methods for querying the population of the EJB s, termed finder methods. To use a business method of a, the client has to obtain a reference to the s home interface using the Java Naming and Directory Interface (JNDI) [3]. Using this reference, the client can create or find a, and obtain a reference to a stub implementing the s remote interface. The stub then delegates method calls to the corresponding EJB. An EJB server transparently manages the population of the s residing in the main memory. When the population of the s inside a container grows beyond a certain limit, the container stores some of the not-recently-used s in a secondary memory (the s are passivated). Whenever a method call targets a passivated, the is brought back into the main memory by the container (the is activated). There are two types of enterprise s session s and entity s. Session s reflect short-lived s, which exist on behalf of a single client and do not represent directly any shared and/or persistent data in a database. Compared to an entity, a session differs in the following: Its identity is not exposed to the client; therefore, the s home interface cannot provide any finder methods. It cannot be reentrant (reentrancy, guarded by the EJB container, is allowed only if enabled in the deployment descriptor; only an entity can be reentrant). It can be involved in at most one transaction at a time. It is transaction-aware; it can be notified about the stage of the current transaction. It cannot be persistent. A session has to be serializable to allow the EJB server to passivate/activate the s instance to/from a secondary storage. Depending upon its conversational state, a session can be stateful or stateless. An entity, on the other hand, typically represents persistent data, usually stored in a database. An entity is transactional, allows shared access from multiple clients, and can be long-lived (living as long as the data in the database, and thus surviving crashes of the EJB server). Every entity is uniquely identified by its primary key (analogous to a primary key in a database). Therefore, the s home interface can provide the finder methods. An entity supports two types of persistence: container managed (CMP) and managed (BMP) persistence. Transaction support is more complex than with the session s, because of the support for persistence. In Enterprise JavaBeans, only distributed flat transactions are supported. The distribution mechanism makes it possible for an application to update data in multiple databases during a single transaction. It is not the concern of an application programmer to ensure transactional semantics, these are guaranteed by the underlying mechanisms. The s execute the database updates using the standard JDBC API. Behind the scenes, the EJB server registers the database connections as members of a transaction. When the transaction commits, the EJB server and all the databases involved use the two-phase commit protocol to ensure atomic update. Multiple EJB servers can participate in a transaction; data can be modified by enterprise s installed in different EJB servers in a single transaction. Every client method invocation on an enterprise is interposed by the container. The interposition allows for delegating the transaction management responsibilities to the container. The container handles transactions according to the transaction attributes that are
4 specified in the corresponding s deployment descriptor. The transaction attributes can be associated with the entire and apply to all methods, or just with an individual method. The EJB specification version 1.0 [1] supports the TX_BEAN_MANAGED, TX_NOT_SUPPORTED, TX_SUPPORTS, TX_REQUIRES, TX_REQUIRES_NEW, and TX_MANDATORY attributes. 3 Compliance with the specification Most of the EJB servers available are still under development. Typically, the vendors aim at implementing all the features required by the EJB 1.0 specification. However, this goal is often not reached, partially because of misinterpretations of the specification (which is not clear enough in some places), partially because of the implementation errors (which are likely to be fixed in future releases of the server). In this section, criteria for compliance with the EJB specification are described and discussed. 3.1 Essential functionality By the essential functionality, we understand the functionality that is the key to the use of an EJB server. It includes facilities for creating connections from a client, instance creation and removal, accessing the s meta-data, and of course invoking the s methods. In particular, the following properties have to be evaluated: The ability to obtain a reference to the EJBHome interface via JNDI. The home interface implementation, i.e. creation, removal. The functionality of the EJBMetaData, EJBObject, and Handle interfaces. 3.2 Session s As stated in the EJB specification, an EJB server has to support the session abstraction (unlike the entity s that are optional). A session represents a function, being by default temporary (short-lived), non-persistent, and thus of limited transactional capabilities (compared to the entity s). The focus should be put especially on the following points: The one transaction at a time restriction. The implementation of the SessionContext interface. The functionality of the SessionSynchronization interface. The correct lifecycle implementation of both the stateful and the stateless session s. 3.3 Entity s By default, an entity represents data that are persistent (long-lived) and transactional. In the EJB 1.0 specification, support for entity s is optional. To test the support for entity s (if implemented), the following properties should be evaluated: The implementation of the EntityContext interface. Handling of the concurrent access from multiple clients. Support for the findbyprimarykey() methods, used for both the container and the managed persistence. The entity lifecycle. The support for reentrancy. 3.4 Container-manager persistence With the container-managed persistence (CMP), the state management is delegated to the EJB container (an entity does not invoke any database calls to store its state). In the 's deployment descriptor, all attributes are declared to be managed by the EJB container.
5 Unlike the -managed persistence (BMP), CMP is fully automatic; but, due to the limited expressive power of the deployment descriptors, CMP is not as flexible. In the compliance tests, the support of the EJB container for container managed persistence should be verified. 3.5 Security The EJB security scheme is based on the security model of the Java programming language. Identity of the calling clients is represented by the java.security.identity. Two security-related methods are provided by the EJBContext interface, getcalleridentity and iscallerinroler; functionality of these methods as well as the implementation of the Access Control Lists should be examined. 3.6 Transactions In a distributed system, a transaction is one of the basic abstractions used to provide transparent concurrency, reliability, and fault tolerance. In an EJB implementation, the following features have to be thoroughly examined: The basic functionality, e.g. creating, starting, and finishing a transaction, setting a transaction timeout, marking a transaction as RollbackOnly. The support for an update of multiple databases. The support for transactions distributed onto multiple EJB servers. The interoperability with non-java clients and servers (access to existing enterprise applications, such as transaction monitors, via bridges). The support for -managed transaction demarcation. The support for container-managed transaction demarcation; in particular, the support for the transaction attributes and the handling of the transaction lifecycle. The support for transaction isolation levels; a transaction isolation level declared in a deployment descriptor has to be propagated via JDBC connections to the underlying databases. Note that most of these features are essential for the use of the Enterprise JavaBeans technology in enterprise applications. 3.7 Interoperability From the developer s point of view, interoperability is one of the most important issues. To ensure at least a minimal level of interoperability, the following issues should be examined: Platform independence whether a client can be a standalone Java application with no restrictions to either a specific platform or a Java language implementation. Support for transactions that encompass multiple EJB servers of different implementations. Many EJB servers use a proprietary RMI implementation. Since the original Java RMI specification did not say how the RMI implementation should transfer the transactional context, interoperability problems are likely to occur. Portability among different EJB servers assess the difficulty of deploying a developed for one EJB server in another one. 4 Performance criteria for EJB In this section, the proposed tests for comparing EJB servers with respect to scalability and performance of the distribution mechanism and transactions are described. In addition, the robustness of the EJB servers is considered.
6 In the first group of the proposed tests, focus is put on the distribution mechanism. Next, the overall scalability of the EJB server is evaluated, together with the robustness of the server. Finally, the overhead caused by the use of the EJB services is measured, with an emphasis on transactions. 4.1 Distribution mechanism The EJB specification defines the Java RMI as the primary distribution mechanism. It also allows to employ other mechanisms, such as CORBA IIOP. Usually, however, the current EJB servers support RMI only. As the EJB server vendors often choose to use a proprietary implementation of the Java Virtual Machine (and RMI), scalability and performance of the RMI implementation used may vary. Because RMI relies on the Java serialization, performance of the Java serialization has to be taken into account Serialization Serialization is the principal point of the RMI performance. Observations have proven that serialization of large method arguments constitutes a significant part of RMI overhead. Therefore, we suggest to measure how the speed of serialization depends on the type and size of the parameters and the way they are passed. We identified the following measurements as characterizing the serialization performance: Measurement of the time spent serializing a single value of a primitive type depending on the way it is stored. Three methods should be tested: passing the value as a primitive type, as a java.lang representing the primitive type, and as a class with a single attribute of the primitive type. Measurement of the time spent serializing a fixed amount of primitive type values depending on the way used to pass the values. Three methods should be tested: passing the values as a single array, passing the values as a class with the respective number of attributes, and passing the values as simple parameters of a method. Measurement of the time spent serializing a fixed amount of references depending on the target of the reference. Three types of reference targets should be evaluated a null reference, a set of reference to different instances of a class, and a set of references to a single instance of a class. The class used should be a simple class with no attributes; this way, the overhead of serializing the instances themselves is minimized. Measurement of the cost of the primitive types serialization. Two approaches to this test can be taken; either the time necessary to serialize a single primitive type is measured for all the primitive types found in Java, i.e. byte, char, short, int, long, float, double, and void, or the overhead of using different data types for passing parameters of a constant total size is measured. Because Java RMI limits the maximum size of the direct method parameters to be 256 bytes, this test is also limited. The test is carried out for all primitive types in Java, with the invoked method taking the appropriate number of parameters of the respective type to make the total size of the parameters constant RMI Currently, several implementations of Java RMI exist. For the purposes of evaluating EJB, the most important is Sun JDK 1.1 [4]. As the future EJB servers will probably use Java 2, Sun JDK 1.2 [5] should be considered as well. Furthermore, several EJB servers rely on proprietary RMI implementations, which should also be taken into account. Although all of the implementations conform to the Java RMI specification, they can have different scalability and performance properties.
7 To evaluate an RMI implementation, the benchmark tests described below should be used. All the tests perform RMI calls on a set of s. The time measured is the time necessary to carry out the RMI call only. The target used for the test should have one method only, with a void return type and no arguments. No transaction context should be involved. To assess the influence of the order of method invocations on the cost of an RMI call, the following tests should be carried out: Object instances should be iterated through in an ascending order, with N RMI calls carried out on each of the s. Object instances should be iterated through in a descending order, with N RMI calls carried out on each of the s. Object instances should be iterated through in an ascending order N times, with a single RMI call carried out in each pass on each of the s. Object instances should be iterated through in a descending order N times, a single RMI call carried out in each pass on each of the s. Object instances should be iterated through in a random order N times, with a single RMI call carried out in each pass on each of the s. The purpose of these tests is twofold, to measure the performance of the RMI mechanism, and to ensure that the performance of the RMI implementation does not depend on the call pattern in a way that would distort the measurement results for other benchmarks. 4.2 Scalability Scalability is one of the most important performance aspects. Here, it is first discussed in general, and then specifically with respect to transactions Number of clients The ability of an EJB based application server to serve connections from several clients at the same time is essential. Dependence of the method invocation time on the number of clients connected to the called should be examined. The test should start a number of clients, each client executing an infinite loop invoking a method on the. At the client side, the time necessary to carry out the method invocation should be measured. In addition, the test should check whether each client gets its share of the access to the Number of instances As data are collected during the application lifetime, the number of instances tends to grow. The impact of the increasing numbers of s present in the system on the cost of the elementary operations should be examined to prevent future surprises. As proposed here, the test should create s in a loop; with the increasing number of s present, the time of creating a new instance, the time of performing the first and the subsequent method invocations on the instance, and the time of removing an instance Transactional context Typically, reliable applications rely on transactions whenever accessing data. Thus, it is important to know the overhead incurred by the use of transactions. A number of tests dealing with this issue will be discussed in section 4.4; here, only scalability is discussed. The dependence of the commit operation time on the size of the transaction context is examined, the size measured in terms of involved s. The test creates a fixed number of s in
8 the EJB server. Then, transactions are carried out with increasing number of s involved in each. This test should also be performed with multiple EJB servers involved in the transactions, to assess the cost of using transactions in a distributed environment. The s should be distributed uniformly across the participating EJB servers. Furthermore, the test can be performed with a large number of EJB servers involved, checking for a potential dependence of the transactional overhead on the number of EJB servers involved. Unfortunately, the computational resources necessary for performing this test on a reasonable scale are expensive, making the test difficult to carry out Number of s In the previous test, the dependence of the commit operation time on the number of s involved in a transaction was examined. However, s residing on an EJB server are liable to cause an overhead even when they do not participate in the respective transaction. Therefore, this test measures the dependence of the commit operation time on the number of s present in the EJB server. The measurements are carried out as s are being created on the EJB server. This test is an addition to the test described in section 4.2.2, where the dependence of the manipulation operation times on the number of s present in the system was examined Number of active transactions Dependence of the cost of the commit operation on the number of simultaneously open transactions should also be measured. It is necessary to have one thread for each open transaction in this test. Unfortunately, our experience indicates that the limiting factors of the Java Virtual Machine thread system exhibit themselves sooner than the potential dependencies of the EJB server performance on the number of transactions. 4.3 Robustness By robustness, we understand the ability to perform reliably under demanding conditions. Robustness can be evaluated with respect to many issues. While it is not practical to design tests that would guarantee the suitability of an EJB server for a particular application, we can identify several scales that reveal the most common weaknesses of the server Number of instances The response of an EJB server to an attempt to continuously create EJB instances should be examined. Instances are created until the EJB server in question crashes or reports that it is not possible to create more instances. The test should be performed for both the session s and the entity s. For the entity s, instances can be passivated and moved to the persistent store during the test. Thus, the result does not represent the maximum number of instances resident in memory. Session instances, on the other hand, cannot be passivated, and the result represents the number of instances resident in memory Number of transactions The maximum number of simultaneously open transactions should be measured. The test should create threads in a loop, each thread opening a transaction and performing a method invocation in the context of the transaction to get the EJB server involved in the transaction.
9 Note that the results of this test do not necessarily indicate a limit within the EJB server, as the virtual memory of the client s Java Virtual Machine is usually exhausted before the limit of the EJB server is reached Maximal request size The maximum size of a request should be determined. Requests with increasing size should be sent to the server until either an error is reported, or the server crashes. To generate an arbitrary request size, an array of that size is passed as the method parameter Number of clients An important issue might be measuring the robustness of an EJB server with respect to the number of clients, be it the number of clients connected or the number of clients actively performing method invocations. Unfortunately, the EJB server vendors often limit the number of clients allowed to connect to the EJB server as a part of their licensing conditions, which prohibits carrying out the test. 4.4 Transactions A transaction can add an overhead to the method invocation. Several performance aspects of using transactions can be measured. In section 4.2, the focus was on the behavior of the EJB server when a large number of either s or transactions is used. In this section, the impact of using various transactional attributes on the method invocation time is discussed Overhead caused by transactional attributes With the transactional attributes applied to methods, the overhead of transactional context creation, suspension, and/or transfer can occur. Tests should be carried out to measure the exact influence of the transactional context manipulation operations. For each of the transactional attributes, the cost of using the attribute should be determined by measuring the time necessary to complete an invocation of an empty method augmented with the respective transactional attribute. This measurement should be carried out twice, once within a client transactional context, and once without one. To illustrate the approach, consider a method associated with the TX_NOT_SUPPORTED transactional attribute. When called inside and outside a client transaction, the difference in the invocation times represents the overhead of the transaction suspension taking place in the first case. Similarly, if a method associated with the TX_REQUIRED transactional attribute is called inside and outside a client transaction, the overhead of the transaction creation is measured. If a method associated with the TX_REQUIRES_NEW transactional attribute is called inside a client transaction, the overhead of a client transaction suspension combined with a container-managed transaction creation and completion is measured. Also, note that in the tests mentioned above, when a method is called within a client transaction context, the context has to be transferred from the client to the server Overhead of managed transactions For managed transactions, the time necessary to perform a -demarcated transaction should be measured. The measurements have to be done from the client s point of view, and should be taken for all the possible scenarios of distributing a transaction into multiple method invocations: Invocation of a single method that does not use -managed transactions: The method is augmented with the TX_BEAN_MANAGED attribute, but no transaction context is created, and no transaction primitive is called.
10 A method which gets a user transaction context and starts and completes a transaction. A method which starts and completes a transaction, obtaining the transaction context only once during a preceding method invocation. A method that uses a transaction retained on a. The transaction is started during one method invocation, is retained after the method completes, and is finished in another method. All methods invoked within the transaction s duration are invoked in the context of this transaction. All these tests should be carried out both inside and outside a client transaction. This should provide results for all possible combinations of transactional attributes, even those that cause unnecessary overhead, as they might be accidentally used by a programmer unaware of a s implementation. All the tests described in this section are performed on methods with both an empty signature and an empty body. A comparison of the overhead of manipulating a transactional context with the overhead of transferring a parameter and a return value can be performed. The results show that overhead of transferring a small number of parameters is insignificant compared to the overhead of manipulating the transactional context. 5 Miscellanea Together with the criteria characterizing performance and standard compliance of a particular EJB server, additional issues, also important to the application developers, should be evaluated: Technical requirements (supported hardware platforms, operating systems, Java implementations). Developer support (GUI tools, debuggers, logging, quality of documentation). Vendor data (a brief company profile, market specialization, flagship products, pricing policy). 6 Summary The Enterprise JavaBeans technology has been introduced in this paper, and criteria suitable for evaluating the EJB server implementations have been proposed. Issues covered by the criteria are compliance with the specification and various benchmark tests that cover the performance, scalability, and robustness characteristics of the distribution mechanism and the transactional support provided by the EJB server implementations. The criteria described in the paper are based on our research evaluating several EJB server implementations. The criteria have been applied to several existing EJB servers, yielding important compliance and benchmark results. Although the results themselves are not included in this paper, we take them as a proof-of-the-concept for the criteria. 7 References [1] Vlada Matena, Mark Hapner: Enterprise JavaBeans 1.0 Specification, Sun Microsystems Inc., March 1998, ftp://ftp.javasoft.com/docs/ejb/ejb.10.ps [2] Vlada Matena, Mark Hapner: Enterprise JavaBeans 1.1 Specification, Public Release, Sun Microsystems Inc., August 10, 1999,
11 [3] Java Naming and Directory Interface 1.2 Specification, Sun Microsystems Inc., July 14, 1999, ftp://ftp.javasoft.com/docs/jndi/1.2/jndi.ps [4] Java Development Kit (JDK) 1.1, Sun Microsystems Inc., [5] Java Development Kit (JDK) 1.2, Sun Microsystems Inc., [6] Susan Cheung: Java Transaction Service 0.95 Specification, Sun Microsystems Inc., March 1, 1999, [7] Object Management Group: Object Transaction Service, December 1997, ftp:// [8] Susan Cheung, Vlada Matena: Java Transaction API 1.01 Specification, Sun Microsystems Inc., April 29, 1999, [9] Rohit Carg: Enterprise JavaBeans to CORBA Mapping 1.0, Sun Microsystems Inc., March 1998, ftp://ftp.javasoft.com/docs/ejb/ejb-corba.10.ps [10] Sanjeev Krishnan: Enterprise JavaBeans to CORBA Mapping 1.1, Sun Microsystems Inc., August 11, 1999, [11] Satoshi Hirano Yoshiji Yasu, Hirotaka Igarashi: Performance Evaluation of Popular Distributed Object Technologies for Java, HORB Open and Electrotechnical Laboratory, [12] ECperf Benchmark Specification, Java Specification Request JSR , March 26, 1999, [13] CORBA Comparison Project, Final Report, Distributed Systems Research Group, Charles University, Prague, June 1998,
Enterprise JavaBeans Benchmarking 1
Enterprise JavaBeans Benchmarking 1 Marek Procházka, Petr T ma, Radek Pospíšil Charles University Faculty of Mathematics and Physics Department of Software Engineering Czech Republic {prochazka, tuma,
Chapter 6 Enterprise Java Beans
Chapter 6 Enterprise Java Beans Overview of the EJB Architecture and J2EE platform The new specification of Java EJB 2.1 was released by Sun Microsystems Inc. in 2002. The EJB technology is widely used
TOPLink for WebLogic. Whitepaper. The Challenge: The Solution:
Whitepaper The Challenge: Enterprise JavaBeans (EJB) represents a new standard in enterprise computing: a component-based architecture for developing and deploying distributed object-oriented applications
Enterprise JavaBeans (I) K.P. Chow University of Hong Kong
Enterprise JavaBeans (I) K.P. Chow University of Hong Kong JavaBeans Components are self contained, reusable software units that can be visually composed into composite components using visual builder
Enterprise JavaBeans. Layer:07. Entity
Enterprise JavaBeans Layer:07 Entity Agenda Build entity beans. Describe the bean's lifecycle. Describe the server's free pool. Copyright (C) 2001 2 Entity Beans Purpose Entity beans represent business
The Developer s Guide to Understanding Enterprise JavaBeans. Nova Laboratories
The Developer s Guide to Understanding Enterprise JavaBeans Nova Laboratories www.nova-labs.com For more information about Nova Laboratories or the Developer Kitchen Series, or to add your name to our
Describing the functionality of EJB using the behavior protocols
Describing the functionality of EJB using the behavior protocols Radek Pospíšil 1, František Plášil 1,2 1 Charles University Faculty of Mathematics and Physics Department of Software Engineering Malostranké
NetBeans IDE Field Guide
NetBeans IDE Field Guide Copyright 2005 Sun Microsystems, Inc. All rights reserved. Table of Contents Extending Web Applications with Business Logic: Introducing EJB Components...1 EJB Project type Wizards...2
ITdumpsFree. Get free valid exam dumps and pass your exam test with confidence
ITdumpsFree http://www.itdumpsfree.com Get free valid exam dumps and pass your exam test with confidence Exam : 310-090 Title : Sun Certified Business Component Developer for J2EE 1.3 Vendors : SUN Version
EJB ENTERPRISE JAVA BEANS INTRODUCTION TO ENTERPRISE JAVA BEANS, JAVA'S SERVER SIDE COMPONENT TECHNOLOGY. EJB Enterprise Java
EJB Enterprise Java EJB Beans ENTERPRISE JAVA BEANS INTRODUCTION TO ENTERPRISE JAVA BEANS, JAVA'S SERVER SIDE COMPONENT TECHNOLOGY Peter R. Egli 1/23 Contents 1. What is a bean? 2. Why EJB? 3. Evolution
Exam Actual. Higher Quality. Better Service! QUESTION & ANSWER
Higher Quality Better Service! Exam Actual QUESTION & ANSWER Accurate study guides, High passing rate! Exam Actual provides update free of charge in one year! http://www.examactual.com Exam : 310-090 Title
Implementing a Web Service p. 110 Implementing a Web Service Client p. 114 Summary p. 117 Introduction to Entity Beans p. 119 Persistence Concepts p.
Acknowledgments p. xvi Introduction p. xvii Overview p. 1 Overview p. 3 The Motivation for Enterprise JavaBeans p. 4 Component Architectures p. 7 Divide and Conquer to the Extreme with Reusable Services
Appendix A - Glossary(of OO software term s)
Appendix A - Glossary(of OO software term s) Abstract Class A class that does not supply an implementation for its entire interface, and so consequently, cannot be instantiated. ActiveX Microsoft s component
Java Enterprise Edition
Java Enterprise Edition The Big Problem Enterprise Architecture: Critical, large-scale systems Performance Millions of requests per day Concurrency Thousands of users Transactions Large amounts of data
Overview p. 1 Server-side Component Architectures p. 3 The Need for a Server-Side Component Architecture p. 4 Server-Side Component Architecture
Preface p. xix About the Author p. xxii Introduction p. xxiii Overview p. 1 Server-side Component Architectures p. 3 The Need for a Server-Side Component Architecture p. 4 Server-Side Component Architecture
Borland Application Server Certification. Study Guide. Version 1.0 Copyright 2001 Borland Software Corporation. All Rights Reserved.
Borland Application Server Certification Study Guide Version 1.0 Copyright 2001 Borland Software Corporation. All Rights Reserved. Introduction This study guide is designed to walk you through requisite
Application Servers in E-Commerce Applications
Application Servers in E-Commerce Applications Péter Mileff 1, Károly Nehéz 2 1 PhD student, 2 PhD, Department of Information Engineering, University of Miskolc Abstract Nowadays there is a growing demand
Overview. Distributed Systems. Distributed Software Architecture Using Middleware. Components of a system are not always held on the same host
Distributed Software Architecture Using Middleware Mitul Patel 1 Overview Distributed Systems Middleware What is it? Why do we need it? Types of Middleware Example Summary 2 Distributed Systems Components
UNIT-III EJB APPLICATIONS
UNIT-III EJB APPLICATIONS CONTENTS EJB Session Beans EJB entity beans EJB clients EJB Deployment Building an application with EJB. EJB Types Types of Enterprise Beans Session beans: Also called business
Exam Questions 1Z0-895
Exam Questions 1Z0-895 Java Platform, Enterprise Edition 6 Enterprise JavaBeans Developer Certified Expert Exam https://www.2passeasy.com/dumps/1z0-895/ QUESTION NO: 1 A developer needs to deliver a large-scale
SCBCD EXAM STUDY KIT. Paul Sanghera CX JAVA BUSINESS COMPONENT DEVELOPER CERTIFICATION FOR EJB MANNING. Covers all you need to pass
CX-310-090 SCBCD EXAM STUDY KIT JAVA BUSINESS COMPONENT DEVELOPER CERTIFICATION FOR EJB Covers all you need to pass Includes free download of a simulated exam You will use it even after passing the exam
Introduction. Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve
Enterprise Java Introduction Enterprise Java Instructor: Please introduce yourself Name Experience in Java Enterprise Edition Goals you hope to achieve Course Description This course focuses on developing
Application Servers G Session 11 - Sub-Topic 2 Using Enterprise JavaBeans. Dr. Jean-Claude Franchitti
Application Servers G22.3033-011 Session 11 - Sub-Topic 2 Using Enterprise JavaBeans Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences
Component-Based Platform for a Virtual University Information System
Component-Based Platform for a Virtual University Information System Dr. IVAN GANCHEV, Dr. MAIRTIN O DROMA, FERGAL McDONNELL Department of Electronics and Computer Engineering University of Limerick National
Reflective Java and A Reflective Component-Based Transaction Architecture
Reflective Java and A Reflective Component-Based Transaction Architecture Zhixue Wu APM Ltd., Poseidon House, Castle Park, Cambridge CB3 0RD UK +44 1223 568930 zhixue.wu@citrix.com ABSTRACT In this paper,
Enterprise JavaBeans (EJB) security
Enterprise JavaBeans (EJB) security Nasser M. Abbasi sometime in 2000 page compiled on August 29, 2015 at 8:27pm Contents 1 Introduction 1 2 Overview of security testing 1 3 Web project dataflow 2 4 Test
Transaction Commit Options
Transaction Commit Options Entity beans in the EJB container of Borland Enterprise Server by Jonathan Weedon, Architect: Borland VisiBroker and Borland AppServer, and Krishnan Subramanian, Enterprise Consultant
Deccansoft Software Services. J2EE Syllabus
Overview: Java is a language and J2EE is a platform which implements java language. J2EE standard for Java 2 Enterprise Edition. Core Java and advanced java are the standard editions of java whereas J2EE
presentation DAD Distributed Applications Development Cristian Toma
Lecture 12 S4 - Core Distributed Middleware Programming in JEE Distributed Development of Business Logic Layer presentation DAD Distributed Applications Development Cristian Toma D.I.C.E/D.E.I.C Department
Today: Distributed Objects. Distributed Objects
Today: Distributed Objects Case study: EJBs (Enterprise Java Beans) Case study: CORBA Lecture 23, page 1 Distributed Objects Figure 10-1. Common organization of a remote object with client-side proxy.
Enterprise Java Beans
Enterprise Java Beans Objectives Three Tiered Architecture Why EJB? What all we should know? EJB Fundamentals 2 Three Tiered Architecture Introduction Distributed three-tier design is needed for Increased
JBuilder. Getting Started Guide part II. Preface. Creating your Second Enterprise JavaBean. Container Managed Persistent Bean.
Getting Started Guide part II Creating your Second Enterprise JavaBean Container Managed Persistent Bean by Gerard van der Pol and Michael Faisst, Borland Preface Introduction This document provides an
KINGS COLLEGE OF ENGINEERING DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING ACADEMIC YEAR (ODD SEMESTER) QUESTION BANK
KINGS COLLEGE OF ENGINEERING DEPARTMENT OF COMPUTER SCIENCE & ENGINEERING ACADEMIC YEAR 2011 2012(ODD SEMESTER) QUESTION BANK SUBJECT CODE / NAME: IT1402-MIDDLEWARE TECHNOLOGIES YEAR/SEM : IV / VII UNIT
Agent-Enabling Transformation of E-Commerce Portals with Web Services
Agent-Enabling Transformation of E-Commerce Portals with Web Services Dr. David B. Ulmer CTO Sotheby s New York, NY 10021, USA Dr. Lixin Tao Professor Pace University Pleasantville, NY 10570, USA Abstract:
CERTIFICATION SUCCESS GUIDE ENTERPRISE ARCHITECT FOR JAVA 2 PLATFORM, ENTERPRISE EDITION (J2EE ) TECHNOLOGY
SUN CERTIFICATION CERTIFICATION SUCCESS GUIDE ENTERPRISE ARCHITECT FOR JAVA 2 PLATFORM, ENTERPRISE EDITION (J2EE ) TECHNOLOGY TABLE OF CONTENTS Introduction..............................................
Enterprise JavaBeans. Layer:03. Session
Enterprise JavaBeans Layer:03 Session Agenda Build stateless & stateful session beans. Describe the bean's lifecycle. Describe the server's swapping mechanism. Last Revised: 10/2/2001 Copyright (C) 2001
Oracle 10g: Build J2EE Applications
Oracle University Contact Us: (09) 5494 1551 Oracle 10g: Build J2EE Applications Duration: 5 Days What you will learn Leading companies are tackling the complexity of their application and IT environments
CAS 703 Software Design
Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on Software by Tao et al. (Chapters 9 and 10) (SOA) 1 Interaction
Enterprise JavaBeans Technology
Patricia Seybold Group Strategic Technologies, Best Practices, Business Solutions Enterprise JavaBeans Technology Server Component Model for the Java Platform By Anne Thomas Revised December 1998 Prepared
Conception of Information Systems Lecture 8: J2EE and EJBs
Conception of Information Systems Lecture 8: J2EE and EJBs 3 May 2005 http://lsirwww.epfl.ch/courses/cis/2005ss/ 2004-2005, Karl Aberer & J.P. Martin-Flatin 1 1 Outline Components J2EE and Enterprise Java
Oracle EXAM - 1Z Java EE 6 Enterprise JavaBeans Developer Certified Expert Exam. Buy Full Product.
Oracle EXAM - 1Z0-895 Java EE 6 Enterprise JavaBeans Developer Certified Expert Exam Buy Full Product http://www.examskey.com/1z0-895.html Examskey Oracle 1Z0-895 exam demo product is here for you to test
(9A05803) WEB SERVICES (ELECTIVE - III)
1 UNIT III (9A05803) WEB SERVICES (ELECTIVE - III) Web services Architecture: web services architecture and its characteristics, core building blocks of web services, standards and technologies available
DCOM CORBA EJB DCOM CORBA CORBA EJB DCOM EJB
DCOM, CORBA, and EJB 1. DCOM, CORBA, and EJB Generic distributed object systems with object RPC, unique object references, generated stubs, and persistent objects. 2. DCOM and CORBA Designed to work across
Java- EE Web Application Development with Enterprise JavaBeans and Web Services
Java- EE Web Application Development with Enterprise JavaBeans and Web Services Duration:60 HOURS Price: INR 8000 SAVE NOW! INR 7000 until December 1, 2011 Students Will Learn How to write Session, Message-Driven
Interconnection of Distributed Components: An Overview of Current Middleware Solutions *
Interconnection of Distributed Components: An Overview of Current Middleware Solutions * Susan D. Urban, Suzanne W. Dietrich, Akash Saxena, and Amy Sundermier Arizona State University Department of Computer
In the most general sense, a server is a program that provides information
d524720 Ch01.qxd 5/20/03 8:37 AM Page 9 Chapter 1 Introducing Application Servers In This Chapter Understanding the role of application servers Meeting the J2EE family of technologies Outlining the major
J2EE Development. Course Detail: Audience. Duration. Course Abstract. Course Objectives. Course Topics. Class Format.
J2EE Development Detail: Audience www.peaksolutions.com/ittraining Java developers, web page designers and other professionals that will be designing, developing and implementing web applications using
Plan. Department of Informatics. Advanced Software Engineering Prof. J. Pasquier-Rocha Cours de Master en Informatique - SH 2003/04
Plan 1. Application Servers 2. Servlets, JSP, JDBC 3. J2EE: Vue d ensemble 4. Distributed Programming 5. Enterprise JavaBeans 6. Enterprise JavaBeans: Transactions 7. Prise de recul critique Enterprise
Multi-tier architecture performance analysis. Papers covered
Multi-tier architecture performance analysis Papers covered Emmanuel Cecchet, Julie Marguerie, Willy Zwaenepoel: Performance and Scalability of EJB Applications. OOPSLA 02 Yan Liu, Alan Fekete, Ian Gorton:
SUN Sun Certified Enterprise Architect for J2EE 5. Download Full Version :
SUN 310-052 Sun Certified Enterprise Architect for J2EE 5 Download Full Version : http://killexams.com/pass4sure/exam-detail/310-052 combination of ANSI SQL-99 syntax coupled with some company-specific
Outline. Chapter 5 Application Server Middleware. Types of application server middleware. TP monitors CORBA Server-side components and EJB Summary
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 5 Application Server Middleware Outline Types of application server
Web Design and Applications
Web Design and Applications JEE - Session Beans Gheorghe Aurel Pacurar JEE - Session Beans What is a session bean? A session bean is the enterprise bean that directly interact with the user and contains
1Z Oracle. Java Enterprise Edition 5 Enterprise Architect Certified Master
Oracle 1Z0-864 Java Enterprise Edition 5 Enterprise Architect Certified Master Download Full Version : http://killexams.com/pass4sure/exam-detail/1z0-864 Answer: A, C QUESTION: 226 Your company is bidding
JDBC Today C HAPTER 1 INTRODUCTION
C HAPTER 1 JDBC Today INTRODUCTION Since its inception in 1995 the Java language has continued to grow in popularity. Originally intended as a language for embedded systems, the Java language has moved
Jironde: A Flexible Framework for Making Components Transactional
Jironde: A Flexible Framework for Making Components Transactional Marek Prochazka INRIA Rhône-Alpes 665, avenue de l Europe, Montbonnot, 38334 Saint Ismier Cedex, France Marek.Prochazka@inrialpes.fr Abstract.
Stateful Session Beans
Berner Fachhochschule Technik und Informatik Stateful Session Beans Course Multi Tier Business Applications with Java EE Prof. Dr. Eric Dubuis Berner Fachhochschule Biel Content Characteristics of stateful
BEAAquaLogic. Service Bus. Interoperability With EJB Transport
BEAAquaLogic Service Bus Interoperability With EJB Transport Version 3.0 Revised: February 2008 Contents EJB Transport Introduction...........................................................1-1 Invoking
Using JNDI from J2EE components
Using JNDI from J2EE components Stand-alone Java program have to specify the location of the naming server when using JNDI private static InitialContext createinitialcontext() throws NamingException {
CO Java EE 7: Back-End Server Application Development
CO-85116 Java EE 7: Back-End Server Application Development Summary Duration 5 Days Audience Application Developers, Developers, J2EE Developers, Java Developers and System Integrators Level Professional
IBM. Enterprise Application Development with IBM Web Sphere Studio, V5.0
IBM 000-287 Enterprise Application Development with IBM Web Sphere Studio, V5.0 Download Full Version : http://killexams.com/pass4sure/exam-detail/000-287 QUESTION: 90 Which of the following statements
Enterprise JavaBeans. Layer:01. Overview
Enterprise JavaBeans Layer:01 Overview Agenda Course introduction & overview. Hardware & software configuration. Evolution of enterprise technology. J2EE framework & components. EJB framework & components.
Enterprise Java Security Fundamentals
Pistoia_ch03.fm Page 55 Tuesday, January 6, 2004 1:56 PM CHAPTER3 Enterprise Java Security Fundamentals THE J2EE platform has achieved remarkable success in meeting enterprise needs, resulting in its widespread
Java 2 Platform, Enterprise Edition: Platform and Component Specifications
Table of Contents Java 2 Platform, Enterprise Edition: Platform and Component Specifications By Bill Shannon, Mark Hapner, Vlada Matena, James Davidson, Eduardo Pelegri-Llopart, Larry Cable, Enterprise
Enterprise JavaBeans: BMP and CMP Entity Beans
CIS 386 Course Advanced Enterprise Java Programming Enterprise JavaBeans: BMP and CMP Entity Beans René Doursat Guest Lecturer Golden Gate University, San Francisco February 2003 EJB Trail Session Beans
JBuilder EJB. Development Using JBuilder 4 and Inprise Application Server 4.1. Audience. A Step-by-step Tutorial.
EJB Development Using JBuilder 4 and Inprise Application Server 4.1 A Step-by-step Tutorial by Todd Spurling, Systems Engineer, Inprise Audience Evaluators or new developers to EJB using JBuilder 4 and
index_ qxd 7/18/02 11:48 AM Page 259 Index
index_259-265.qxd 7/18/02 11:48 AM Page 259 Index acceptance testing, 222 activity definition, 249 key concept in RUP, 40 Actor artifact analysis and iterative development, 98 described, 97 136 in the
Experiences in the management of an EJB-based e- commerce application. Abstract
Experiences in the management of an EJB-based e- commerce application Juan I. Asensio, Víctor A. Villagrá, Jorge E. López de Vergara, Roney Pignaton, Julio J. Berrocal. Department of Telematic Systems
Enterprise Java and Rational Rose -- Part I
Enterprise Java and Rational Rose -- Part I by Khawar Ahmed Technical Marketing Engineer Rational Software Loïc Julien Software Engineer Rational Software "We believe that the Enterprise JavaBeans component
CORBA Object Transaction Service
CORBA Object Transaction Service Telcordia Contact: Paolo Missier paolo@research.telcordia.com +1 (973) 829 4644 March 29th, 1999 An SAIC Company Telcordia Technologies Proprietary Internal Use Only This
CHAPTER 4 TRANSACTIONS
CHAPTER 4 TRANSACTIONS OBJECTIVES After completing Transactions, you will be able to: Describe the importance of transactions in enterprise-class software. Describe the EJB transaction model. Protect your
Distributed Multitiered Application
Distributed Multitiered Application Java EE platform uses a distributed multitiered application model for enterprise applications. Logic is divided into components https://docs.oracle.com/javaee/7/tutorial/overview004.htm
Entity Beans 02/24/2004
Entity Beans 1 This session is about Entity beans. Understanding entity beans is very important. Yet, entity bean is a lot more complex beast than a session bean since it involves backend database. So
MTAT Enterprise System Integration. Lecture 2: Middleware & Web Services
MTAT.03.229 Enterprise System Integration Lecture 2: Middleware & Web Services Luciano García-Bañuelos Slides by Prof. M. Dumas Overall view 2 Enterprise Java 2 Entity classes (Data layer) 3 Enterprise
~ Ian Hunneybell: CBSD Revision Notes (07/06/2006) ~
1 Component: Szyperski s definition of a component: A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can
Comparative Analysis of EJB3 and Spring Framework
Comparative Analysis of EJB3 and Spring Framework Janis Graudins, Larissa Zaitseva Abstract: The paper describes main facilities of EJB3 and Spring Framework as well as the results of their comparative
QuickSpecs. Compaq NonStop Transaction Server for Java Solution. Models. Introduction. Creating a state-of-the-art transactional Java environment
Models Bringing Compaq NonStop Himalaya server reliability and transactional power to enterprise Java environments Compaq enables companies to combine the strengths of Java technology with the reliability
Outline. Chapter 5 Application Server Middleware WS 2010/11 1. Types of application server middleware
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 5 Application Server Middleware Outline Types of application server
Enterprise Java and Rational Rose - Part II
Enterprise Java and Rational Rose - Part II by Khawar Ahmed Technical Marketing Engineer Rational Software Loïc Julien Software Engineer Rational Software This is the second installment of a twopart series
Designing a Distributed System
Introduction Building distributed IT applications involves assembling distributed components and coordinating their behavior to achieve the desired functionality. Specifying, designing, building, and deploying
Oracle Tuxedo. CORBA Technical Articles 11g Release 1 ( ) March 2010
Oracle Tuxedo CORBA Technical Articles 11g Release 1 (11.1.1.1.0) March 2010 Oracle Tuxedo CORBA Technical Articles, 11g Release 1 (11.1.1.1.0) Copyright 1996, 2010, Oracle and/or its affiliates. All rights
Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach
Developing Software Applications Using Middleware Infrastructure: Role Based and Coordination Component Framework Approach Ninat Wanapan and Somnuk Keretho Department of Computer Engineering, Kasetsart
Notes. Submit homework on Blackboard The first homework deadline is the end of Sunday, Feb 11 th. Final slides have 'Spring 2018' in chapter title
Notes Ask course content questions on Slack (is651-spring-2018.slack.com) Contact me by email to add you to Slack Make sure you checked Additional Links at homework page before you ask In-class discussion
8. Component Software
8. Component Software Overview 8.1 Component Frameworks: An Introduction 8.2 OSGi Component Framework 8.2.1 Component Model and Bundles 8.2.2 OSGi Container and Framework 8.2.3 Further Features of the
Oracle9iAS TopLink. 1 TopLink CMP for BEA WebLogic Server. 1.1 EJB 2.0 Support. CMP-Specific Release Notes
Oracle9iAS TopLink CMP-Specific Release Notes Release 2 (9.0.3) August 2002 Part No. B10161-01 These release notes include information on using Oracle9iAS TopLink Release 2 (9.0.3) with the following CMPs:
Problems in Scaling an Application Client
J2EE What now? At this point, you understand how to design servers and how to design clients Where do you draw the line? What are issues in complex enterprise platform? How many servers? How many forms
Chapter 6 Object Persistence, Relationships and Queries
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 6 Object Persistence, Relationships and Queries Object Persistence
Outline. Chapter 5 Application Server Middleware. Types of application server middleware. TP monitors CORBA Server-side components and EJB Summary
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 5 Application Server Middleware Outline Types of application server
Using the Transaction Service
15 CHAPTER 15 Using the Transaction Service The Java EE platform provides several abstractions that simplify development of dependable transaction processing for applications. This chapter discusses Java
A General ecommerce Platform with Strong International and Local Aspects
A General ecommerce Platform with Strong International and Local Aspects By Martin Ramsin A Master s Thesis August 2000 Examiner: Professor Seif Haridi Supervisors:Andy Neil and Mark Bünger, Icon MediaLab
Chapter 3 Introduction to Distributed Objects
Chapter 3 Introduction to Distributed Objects Distributed object support all of the properties of an object created in compiled object oriented language, namely,data and code encapsulation, polymorphism
Java EE 7: Back-End Server Application Development
Oracle University Contact Us: Local: 0845 777 7 711 Intl: +44 845 777 7 711 Java EE 7: Back-End Server Application Development Duration: 5 Days What you will learn The Java EE 7: Back-End Server Application
Application Server Evaluation Method
Application Evaluation Method Janis Graudins, Larissa Zaitseva Abstract: The paper describes an server evaluation and selection for software systems implementation using client-server technology. The multi
Commercial Component Creation (EJB 2.0)
Commercial Component Creation (EJB 2.0) Enterprise JavaBeans Components Technology Based Components Technical White Paper Date: April 5, 2001 Authors: Faiz Arni, InferData Corporation Andrew Pharoah, ComponentSource
Supports 1-1, 1-many, and many to many relationships between objects
Author: Bill Ennis TOPLink provides container-managed persistence for BEA Weblogic. It has been available for Weblogic's application server since Weblogic version 4.5.1 released in December, 1999. TOPLink
JOTM: Overview and Perspectives
JOTM: Overview and Perspectives Marek Prochazka Marek.Prochazka@inrialpes.fr www.objectweb.org Presentation Outline JOTM overview What is it (interfaces, services, functionality) Relation to standards
Selecting Enterprise JavaBeans Technology
Patricia Seybold Group Strategic Technologies, Best Practices, Business Solutions Selecting Enterprise JavaBeans Technology By Anne Thomas July 1998 Prepared for WebLogic, Inc. 85 Devonshire Street, 5
Chapter 1: Distributed Information Systems
Chapter 1: Distributed Information Systems Contents - Chapter 1 Design of an information system Layers and tiers Bottom up design Top down design Architecture of an information system One tier Two tier
Course Content for Java J2EE
CORE JAVA Course Content for Java J2EE After all having a lot number of programming languages. Why JAVA; yet another language!!! AND NOW WHY ONLY JAVA??? PART-1 Basics & Core Components Features and History
History of Enterprise Java
History of Enterprise Java! At first: Sun focused on the Java Development Kit (JDK) " Remember that Java is a spec, not a technology " Different vendors can implement Java " The JDK became the de-facto
133 July 23, :01 pm
Protocol Between a Message-Driven Bean Instance and its ContainerEnterprise JavaBeans 3.2, Public Draft Message-Driven Bean When a message-driven bean using bean-managed transaction demarcation uses the