The Enterprise Java BluePrints for the J2EE platform describe the J2EE application model and best practices for using the J2EE platform. Building on the J2SE platform, the J2EE application model provides a simplified approach to developing highly scalable and highly available internet or intranet based applications.
Thanks to the J2EE application model, maybe the most interesting thing about J2EE applications is what they don't do. That is, various complexities inherent in enterprise applications -- transaction management, life-cycle management, resource pooling -- are built into the platform and provided automatically to the components it supports. Component and application developers are free to focus on specifics such as business logic and user interfaces.
Another advantage of the J2EE platform is that the application model encapsulates the layers of functionality in specific types of components. Business logic is encapsulated in Enterprise JavaBeans (EJB) components. Client interaction can be presented through plain HTML web pages, through web pages powered by applets, Java Servlets, or JavaServer Pages technology, or through stand-alone Java applications. Components communicate transparently using various standards: HTML, XML, HTTP, SSL, RMI, IIOP, and others.
Reusable J2EE components mean competitive choices for enterprise developers and IT organizations. The J2EE platform enables them to assemble applications from a combination of standard, commercially available components and their own custom components. From general business application components to vertical market solutions, a range of standardized J2EE functionality is available off the shelf.
This means that an e-commerce site could be built using a combination of off-the-shelf EJB components for shopping cart behaviors, modified EJB components for specialized customer services, and completely customized layouts using JavaServer Pages technology that bring a unique look and feel to the site.
This approach means faster development time, better quality, maintainability and portability, and Web services interoperability across a range of enterprise platforms. The bottom line benefits are increased programmer productivity, better strategic use of computing resources, and greater return on an organization's technology investments.
The J2EE application model divides enterprise applications into three fundamental parts: components, containers, and connectors. Components are the key focus of application developers, while system vendors implement containers and connectors to conceal complexity and promote portability.
Containers intercede between clients and components, providing services transparently to both, including transaction support and resource pooling. Container mediation allows many component behaviors to be specified at deployment time, rather than in program code.
Connectors sit beneath the J2EE platform, defining a portable service API that communicates with existing enterprise vendor offerings. Connectors promote flexibility by enabling a variety of implementations of specific services. In particular, connectors implementing pluggable messaging contracts enable bidirectional communication between J2EE components and enterprise systems.
The J2EE platform provides choices for graphical user interfaces across a company's intranet or on the World Wide Web. Clients can run on desktops, laptops, PDAs, cell phones, and other devices. Pure client-side user interfaces can use standard HTML and Java applets. Support for simple HTML means quicker prototypes, and support for a broader range of clients. Additionally, the J2EE platform supports automatic download of the Java Plug-in to add applet support where it's lacking. The J2EE platform also supports stand-alone Java application clients.
For server-side generation of dynamic content, the J2EE platform supports two types of web component technologies: Java Servlets and JavaServer Pages (JSP). Java Servlets enable developers to easily implement server-side behaviors that take full advantage of the power of the rich Java API. JavaServer Pages technology combines the ubiquity of HTML with the power of server-side dynamic content generation. The JSP 2.0 specification supports static templates, simplified access to Java objects, and easy extensibility.
Enterprise JavaBeans (EJB) technology enables a simplified approach to multitier application development, concealing application complexity and enabling the component developer to focus on business logic.
EJB technology gives developers the ability to model the full range of objects useful in the enterprise by defining several types of EJB components: session beans, entity beans, message-driven beans. Session beans represent behaviors associated with client sessions -- for example, a user purchase transaction on an e-commerce site. Session beans can serve as Web service endpoints. Entity beans represent collections of data -- such as rows in a relational database -- and encapsulate operations on the data they represent. Entity beans are intended to be persistent, surviving as long as the data they're associated with remains viable. Message-driven beans allow J2EE applications to process messages asynchronously. A message-driven bean normally acts as a JMS message listener, which is similar to an event listener except that it receives JMS messages instead of events. The messages may be sent by any J2EE component--an application client, another enterprise bean, or a Web component--or by a JMS application or system that does not use J2EE technology.
The Java 2 Platform, Enterprise Edition version 1.4 is the most complete Web services platform ever. The platform features Web services support through the new JAX-RPC 1.1 API, which provides service endpoints based on servlets and enterprise beans. JAX-RPC 1.1 provides interoperability with Web services based on the WSDL and SOAP protocols. The J2EE 1.4 platform also supports the Web Services for J2EE specification, which defines deployment requirements for Web services and utilizes the JAX-RPC programming model. In addition to numerous Web services APIs, the J2EE 1.4 platform also features support for the WS-I Basic Profile 1.0. This means that in addition to platform independence and complete Web services support, the J2EE 1.4 platform offers platform Web services interoperability.
Based on these flexible component configurations, the J2EE application model means quicker development, easier customization and greater ability to deploy powerful enterprise applications. And, because it's based on the Java programming language, this model enables all J2EE applications to achieve all the benefits of Java technology: scalability, portability, and programming ease.
When you say J2EE server I assume you mean the reference implementation from sun. There are some differences but the really major one is that the reference implementation is not meant to be used in a production environment, whereas JBoss is. (and is in fact being used in production in several places).
Al
Yes,
you should be able to test those examples.
You need to make sure that you are working with ejb-jars though. Once EJBs have been deployed as an .ear file for a particular app server, they are no longer platform independent as ear files contain deployment info particular to that platform.
Since the deploy tool that comes with J2EE RI does several things, you may be able to use some of those features, but not all of them.
The deploytool helps you to create the ejb-jar files, as well as write the xml deployment descriptor. You can then save those jar files, and add the jboss specific deployment information (in the form of a jboss.xml file).
This is all that you need to deploy ejbs on jboss. The part where click on deploy, to send the jar to the server in J2EE, and the creation of a client jar is all handled differently, (and more simply) in Jboss.
Deployment is handled by just dropping you ejb-jar file into the deploy directory. There are four generic client jars that need to be on the client's classpath. This means there is no need to create a client jar for each ejb-jar. Much simpler.
So in short, while you can use deploytool for some of the work, it is a J2EE RI-specific tool, designed only to be used with J2EE-RI.
Ant on the other hand, can be, and is used (AFAICT) by 99% of Jboss users.
V. Handy.
Cheers
Thank you very much for that bigg help.
I would like to ask you again about Richard Monson-Haefel examples, I see on jboss document, Richards examples can be tested on jboss but only for unix users. There is also link saying modified version which is not working.
Any more insights are very much appreciated.
JLea
Thanks
Oracle WebLogic Server is a leading e-commerce online transaction processing (OLTP) platform, developed to connect users in distributed computing production environments and to facilitate the integration of mainframe applications with distributed corporate data and applications.
WebLogic is an Application Server that runs on a middle tier, between back-end databases and related applications and browser-based thin clients. WebLogic Server mediates the exchange of requests from the client tier with responses from the back-end tier.
WebLogic Server is based on Java Platform, Enterprise Edition (Java EE) (formerly known as Java 2 Platform, Enterprise Edition or J2EE), the standard platform used to create Java-based multi-tier enterprise applications. Java EE platform technologies were developed through the efforts of BEA Systems and other vendors in collaboration with the main developer, Sun Microsystems.
Enterprises use WebLogic Server to develop distributed applications, enabling users to access applications from a client -- web browser, mobile device or any other type of client program or device using a program written in Java or any other language -- and systems on the back end -- databases, enterprise information systems or mainframe applications.
c80f0f1006