The technical list of J2EE developers is quite lengthy. In this article, we will not discuss J2EE technology, or even discuss new technologies. We will explore some of its main new features, then you will know which features to use in the J2EE project. J2EE 1.4 brings some new and interesting features. They have always around three main topics: web services, messaging and easier web development. To meet the needs of these topics, all major specifications that make up J2EE are upgraded - most specification is important. The most important (and most) upgrade is the JCA 1.5 specification and JSP 2.0 specification and the J2EE specification itself. In addition, there are some norms to be new (or new J2EE) - for example: JAX-RPC, Web Services, and J2EE deployment and management specifications.
The new specification contains some new specifications and technologies in J2EE 1.4. Overall, most of them are used to support Web services or XML in the most important expansion contents of J2EE. The most important one is:
Web Services for J2EE (JSR-109) This new specification describes how Web services are deployed as a servlet or EJB stateless session bean. The most striking change is to increase the new deployment descriptor, which will support the components as a web service to deploy.
JAX-RPC 1.1JAX-RPC is a Java API for remote procedure using SOAP. With these APIs, you can call the Web service with a remote object. The use of JAX-RPC in J2EE is very similar to calling remote EJB.
The JAX-RPC specification also defines a web service (through its WSDL) to map to the Java interface. The implementation of JAX-RPC also includes some tools for generating interfaces, stubs, etc. from WSDL, or generates WSDL from the interface.
J2EE uses JAX-RPC on the server side and clients of the Web service. The web service (as servlet or EJB) implemented in J2EE will be used to use the JAX-RPC interface. And if a component is to call the web service remotely, it will use the JAX-RPC as a remote interface.
SAAJ 1.2SAAJ is SOAP WITH ATACHMENTS API for Java (for Java with an attachment API SOAP), which allows accessories that are delivered in the SOAP calls can be accessed by Java.
JAXRJAXR is a Java API for an XML registry, which uses to access Web service registry, such as UDDI, EBXML, and OASIS. Unfortunately, J2EE does not require any particular registry, but can be used with an API and implement the API.
XML Support Now J2EE 1.4 specification requires support for SAX 2, DOM Level 2, XML architecture and namespace, requested to support XSLT. If you are writing a J2EE application that manipulating an XML, you must now support the latest version to work.
J2EE Management and Deploy API (JSR-77 and JSR-88)
These two APIs are concerned by tools and IDE suppliers. They provide a vendor-independent API to control management and deployment activities on the J2EE application server. This makes IDE (or our own tools) can easily interact with a wide variety of application servers without having to use a large number of APIs specific to suppliers.
Specification change
All specifications included in J2EE have varyed to the extent to which J2EE 1.4 has varyed to. However, some changes are very small, but J2EE's "four major" (EJB, JCA, Servlets, and JSP) have increased important new features.
The following is the most important change:
Enterprise Java Beans 2.1EJB 2.1 The improvements of the specification are mainly for web services and messaging. This will be described in detail below. However, EJB 2.1 also adds the timer service and enhances the EJB-QL query language of the entity bean managed by the container. The new timer service allows any EJB (except for a stateful session bean) to register to obtain a time-time callback function from the container. EJB can request a single callback signal after a specific time (such as 10 seconds), or can also schedule a periodic (such as every 10 minutes) callback. This feature is very helpful in some cases, but there is also potential possibilities that are greatly misuse - this can only let the time tell us the answer.
Enhancements to EJB-QL are operators Order by, sum, count, avg, max, min, and mod. Most application servers provide these operators in their specific-specific extensions. Now, they are finally written in the specification.
Enterprise Java Beans 2.1 - Web Services endpoints For web services, EJB has joined the ability to use stateless session beans as web services. This ability can be used to implement a new web service or publish the first ejb in the Web service interface.
Configuring an existing stateless session bean into a web service endpoint is relatively easy. Generate WSDL (using JAX-RPC tools) from a remote interface, then add a service-endpoint element in the EJB-JAR.XML file. This service-endpoint element does not look like an additional interface that is like visiting your EJB - so that your EJB has a remote, local and Web service endpoint interface now. Next, add a deployment descriptor WebServices.xml, and the file contains both of the service-imp-bean and EJB-LINK. This will connect the WSDL to the EJB and inform the application server to publish it through the web container.
Also, existing web services can be implemented as stateless session beans unless you use the JAX-RPC tool from WSDL to generate an interface.
Enterprise Java Beans 2.1 - Web Service Client EJB 2.1 Specifications Now clearly allows any EJB to be a client (via JAX-RPC interface). The way to call the Web service and call another EJB is very similar. Using Service-Ref elements in the deployment descriptor, the web service will be mapped so you can use the "Java: Comp / Env /" name to query this service in JNNI.
By the way, this technology not only can be used in EJB, but also in any J2EE component - so you can also call Web services in a servlets or JCA adapter.
Enterprise Java Beans 2.1 - Message Pass EJB Improvement of Message Pass is close to Java Connector Architecture. The EJB 2.1 specification improves the message-driven Bean (MDB: Message-Driven BEAN) to allow for any (non-JMS) message type. Similarly, a message connection tool is also added to the deployment descriptor, which is used to specify the MBD or JMS destination of the component sends a message (this and EJB-REF allows you to put the EJB "hook".).
J2EE Connector Architecture 1.5JCA 1.5 specification has changed. The new change in JCA 1.5 is an inbound source adapter that allows an external service (such as an EIS system) to send a message to the application server. So JCA now has become two-way. With a message connection tool, the tool connects the inbound adapter and the MDB that handles the message. Here, this main use case is to contact the message-driven bean (MDB), the inbound adapter receives information, processing information generating messages, and then queues the message to MDB for processing. The key to this feature is that the MDB changes use non-JMS messages. Other improvements in other aspects of JCA include improvements to the work management system for managing all threads required for different step-in station adapters. The Work Manager allows JCA to use threads, but will not conflict with application management of their threads. Servlet 2.4Servlet 2.4 Specifications Changes in web services are primarily the ability of the JAX-RPC class as a servlet deployment to implement the Web service endpoint. This provides an easy way to realize web services. Write a servlet-based web service endpoint and create an EJB-based endpoint almost no. Creating an interface from the WSDL using the JAX-RPC tool (or created a WSDL from the interface), and then implement this interface in a normal Java class. This class is then declared in Web.xml with servlet elements (but not using servlet-mapping), then create a WebServices.xml descriptor file containing service-impl-bean and servlet-link elements.
Servlet 2.4 also adds Listener to obtain properties (this is like existing session attribute listeners).
SingleThreadModel does not agree with it. If you have used this interface, you must already know that it doesn't really resolve the real-time concurrency of Serverlet. SingLethreadModel can only protect the domains and methods of the single process serverlet, but there is no doubt that it does not protect the ability of other resources (like references in the static method, or objects in httpsession). Therefore, SingleThreadModel will not agree with use, will be replaced by a good, thread security programming practice.
Java Server Pages 2.0JSP specification is finally mature. In JSP 2.0, you can finally write a script-free page (without any "<% ...%>" code that belongs to Java).
The first improvement is to increase the expression language (EL), the expression language is derived from the JSP Standard Tag Library (Javaserver Pages Standard Tag Library, JSTL). EL is a simple, exquisite and easy-to-use syntax, which no longer requires most of "scriptlet". EL is based on ECMAScript (JavaScript) and XPath, so its syntax will feel like a Web developer.
The tag library is also improved in JSP 2.0. Nowadays, we have a simpler API to write tags. SimpleTag interface has a simpler and simple lifecycle - only one dotag method and there is no instance buffer pool and reuse. SimpleTag and its JSPFragment partner (used to evaluate the marker) can complete the current "Classic Tags" now, but compared with the previous comparison, you can save much effort. In addition, these more simple APIs means that markers can be easier to implement, which means BUG less.
Another improvement to the mark is the ability to write tag files. These tags are implemented as a JSP file rather than a Java class. The writing tag file is simple, and the deployment is simpler - you just put these files with the name of foo.tag in Web-inf / tags. You don't need to write a TLD descriptor file because all important information is declared in the tag file. The maximum advantage of tag files is to mark some visual HTML elements. For example, the output of the BEAN is continuously formatted. Previously, HTML must be embedded in Java code or to take the way to contain a page. But the markup file is the most natural usage of this type. This also opens the door of the homemade creation tag to those non-Java developers. JSP 2.0 also improves syntax for supporting XML, joining JSR-45 support, and debugging support for other languages.
JSTLJSP Standard Tag Library (JavaServer Pages Standard Tag Library, JSTL) is a collection of very useful tags. These tags and JSP2.0 are well combined in other ways. Unfortunately, JSTL is not an essential component of the JSP 2.0 specification. However, since it is so useful, it has gained a wide range of support (eg, from Sun to Apache), it is worth mentioning here. Summarizing in the new version is full of new content, then how is the problem to use them?
All of these changes in the Web Development JSP specification have greatly improved the web development experience. Everyone is finally possible to write JSP pages that do not embed Java code. Also, the optionality of simple markers and tag files makes the label easier to write and easier to use. The separation between the user interface (view) and the rear end (controller) is also better. Message delivery messaging has many significance in MDB and JCA improvements. First, it is obvious that the two-way communication between the application server and EIS will increase J2EE integration with existing enterprises.
But other benefits are far more than this. First, in addition to the sockets owned by the container (RMI, IIOP, and HTTP), the inbound adapter has "right" creation and listening to the socket. So, for example, you can add a JCA adapter to make you telnet to the application server to perform some administrative tasks. Alternatively, the FTP server can be deployed as a standard J2EE JCA component, or the mail server can also be implemented. This possibility is endless.
Another possibility (this has been clearly stated in the specification) is the JMS provider. The J2EE specification requires the application server to implement JMS- but does not specify any requirements for a specific message delivery system. Therefore, each message provider usually implements their own message system to support JMS. Also, they usually have external systems to work with them to communicate.
With J2EE 1.4, the message provider is now possible to create a homemade JMS support, like a standard that meets J2EE, the portable JCA adapter. At the end of the adapter, one end of the adapter can handle the message user, and the publisher is processed at one end of the station. This JCA then deployed into any J2EE 1.4 application server. This makes it a potential ability to improve interoperability between application servers, which is at least for JMS messages. Web services have J2EE 1.4 specification, J2EE has been combined with Web services. This has a variety of options.
First, if you have an existing EJB-based system, any stateful session bean can be published as a web service as long as you add a JAC interface and some entries in the deployment descriptor. This opens interoperability of existing deployments and web services.
For new web services, you can write EJB implementations as above, you can also write simple Java classes (using JAX-RPC). No matter which way you use, you can deploy some deployment descriptors. In addition, you can use any Web services in the J2EE application, and the method is to call the web service using JAX-RPC when performing any other remote calls. Conclusion The enhancement of J2EE 1.4 is unquestionable and should enhance the usefulness and ability of the J2EE platform. Improvements in JCA and MDB are used to enhance the backend of enterprises. Increases support for web services to improve the usefulness and interoperability of J2EE. For those who wish to develop web-based user interfaces, the improvement of JSP reduces the thresholds they use. In short, this is a great combination.
Now, the most difficult thing is in front of you - J2EE developers, you need to decide, how to choose all these good things in your project. This will be an endless thing.
The technical list of J2EE developers is quite lengthy. In this article, we will not discuss J2EE technology, or even discuss new technologies. We will explore some of its main new features, then you will know which features to use in the J2EE project. J2EE 1.4 brings some new and interesting features. They have always around three main topics: web services, messaging and easier web development. To meet the needs of these topics, all major specifications that make up J2EE are upgraded - most specification is important. The most important (and most) upgrade is the JCA 1.5 specification and JSP 2.0 specification and the J2EE specification itself. In addition, there are some norms to be new (or new J2EE) - for example: JAX-RPC, Web Services, and J2EE deployment and management specifications.
The new specification contains some new specifications and technologies in J2EE 1.4. Overall, most of them are used to support Web services or XML in the most important expansion contents of J2EE. The most important one is:
Web Services for J2EE (JSR-109) This new specification describes how Web services are deployed as a servlet or EJB stateless session bean. The most striking change is to increase the new deployment descriptor, which will support the components as a web service to deploy.
JAX-RPC 1.1JAX-RPC is a Java API for remote procedure using SOAP. With these APIs, you can call the Web service with a remote object. The use of JAX-RPC in J2EE is very similar to calling remote EJB.
The JAX-RPC specification also defines a web service (through its WSDL) to map to the Java interface. The implementation of JAX-RPC also includes some tools for generating interfaces, stubs, etc. from WSDL, or generates WSDL from the interface.
J2EE uses JAX-RPC on the server side and clients of the Web service. The web service (as servlet or EJB) implemented in J2EE will be used to use the JAX-RPC interface. And if a component is to call the web service remotely, it will use the JAX-RPC as a remote interface.
SAAJ 1.2SAAJ is SOAP WITH ATACHMENTS API for Java (for Java with an attachment API SOAP), which allows accessories that are delivered in the SOAP calls can be accessed by Java.
JAXRJAXR is a Java API for an XML registry, which uses to access Web service registry, such as UDDI, EBXML, and OASIS. Unfortunately, J2EE does not require any particular registry, but can be used with an API and implement the API.
XML Support Now J2EE 1.4 specification requires support for SAX 2, DOM Level 2, XML architecture and namespace, requested to support XSLT. If you are writing a J2EE application that manipulating an XML, you must now support the latest version to work. J2EE Management and Deploy API (JSR-77 and JSR-88)
These two APIs are concerned by tools and IDE suppliers. They provide a vendor-independent API to control management and deployment activities on the J2EE application server. This makes IDE (or our own tools) can easily interact with a wide variety of application servers without having to use a large number of APIs specific to suppliers.
Specification change
All specifications included in J2EE have varyed to the extent to which J2EE 1.4 has varyed to. However, some changes are very small, but J2EE's "four major" (EJB, JCA, Servlets, and JSP) have increased important new features.
The following is the most important change:
Enterprise Java Beans 2.1EJB 2.1 The improvements of the specification are mainly for web services and messaging. This will be described in detail below. However, EJB 2.1 also adds the timer service and enhances the EJB-QL query language of the entity bean managed by the container.
The new timer service allows any EJB (except for a stateful session bean) to register to obtain a time-time callback function from the container. EJB can request a single callback signal after a specific time (such as 10 seconds), or can also schedule a periodic (such as every 10 minutes) callback. This feature is very helpful in some cases, but there is also potential possibilities that are greatly misuse - this can only let the time tell us the answer.
Enhancements to EJB-QL are operators Order by, sum, count, avg, max, min, and mod. Most application servers provide these operators in their specific-specific extensions. Now, they are finally written in the specification.
Enterprise Java Beans 2.1 - Web Services endpoints For web services, EJB has joined the ability to use stateless session beans as web services. This ability can be used to implement a new web service or publish the first ejb in the Web service interface.
Configuring an existing stateless session bean into a web service endpoint is relatively easy. Generate WSDL (using JAX-RPC tools) from a remote interface, then add a service-endpoint element in the EJB-JAR.XML file. This service-endpoint element does not look like an additional interface that is like visiting your EJB - so that your EJB has a remote, local and Web service endpoint interface now. Next, add a deployment descriptor WebServices.xml, and the file contains both of the service-imp-bean and EJB-LINK. This will connect the WSDL to the EJB and inform the application server to publish it through the web container.
Also, existing web services can be implemented as stateless session beans unless you use the JAX-RPC tool from WSDL to generate an interface.
Enterprise Java Beans 2.1 - Web Service Client EJB 2.1 Specifications Now clearly allows any EJB to be a client (via JAX-RPC interface). The way to call the Web service and call another EJB is very similar. Using Service-Ref elements in the deployment descriptor, the web service will be mapped so you can use the "Java: Comp / Env /" name to query this service in JNNI.
By the way, this technology not only can be used in EJB, but also in any J2EE component - so you can also call Web services in a servlets or JCA adapter.
Enterprise Java Beans 2.1 - Message Pass EJB Improvement of Message Pass is close to Java Connector Architecture. The EJB 2.1 specification improves the message-driven Bean (MDB: Message-Driven BEAN) to allow for any (non-JMS) message type. Similarly, a message connection tool is also added to the deployment descriptor, which is used to specify the MBD or JMS destination of the component sends a message (this and EJB-REF allows you to put the EJB "hook".). J2EE Connector Architecture 1.5JCA 1.5 specification has changed. The new change in JCA 1.5 is an inbound source adapter that allows an external service (such as an EIS system) to send a message to the application server. So JCA now has become two-way. With a message connection tool, the tool connects the inbound adapter and the MDB that handles the message. Here, this main use case is to contact the message-driven bean (MDB), the inbound adapter receives information, processing information generating messages, and then queues the message to MDB for processing. The key to this feature is that the MDB changes use non-JMS messages. Other improvements in other aspects of JCA include improvements to the work management system for managing all threads required for different step-in station adapters. The Work Manager allows JCA to use threads, but will not conflict with application management of their threads. Servlet 2.4Servlet 2.4 Specifications Changes in web services are primarily the ability of the JAX-RPC class as a servlet deployment to implement the Web service endpoint. This provides an easy way to realize web services.
Write a servlet-based web service endpoint and create an EJB-based endpoint almost no. Creating an interface from the WSDL using the JAX-RPC tool (or created a WSDL from the interface), and then implement this interface in a normal Java class. This class is then declared in Web.xml with servlet elements (but not using servlet-mapping), then create a WebServices.xml descriptor file containing service-impl-bean and servlet-link elements.
Servlet 2.4 also adds Listener to obtain properties (this is like existing session attribute listeners).
SingleThreadModel does not agree with it. If you have used this interface, you must already know that it doesn't really resolve the real-time concurrency of Serverlet. SingLethreadModel can only protect the domains and methods of the single process serverlet, but there is no doubt that it does not protect the ability of other resources (like references in the static method, or objects in httpsession). Therefore, SingleThreadModel will not agree with use, will be replaced by a good, thread security programming practice.
Java Server Pages 2.0JSP specification is finally mature. In JSP 2.0, you can finally write a script-free page (without any "<% ...%>" code that belongs to Java).
The first improvement is to increase the expression language (EL), the expression language is derived from the JSP Standard Tag Library (Javaserver Pages Standard Tag Library, JSTL). EL is a simple, exquisite and easy-to-use syntax, which no longer requires most of "scriptlet". EL is based on ECMAScript (JavaScript) and XPath, so its syntax will feel like a Web developer. The tag library is also improved in JSP 2.0. Nowadays, we have a simpler API to write tags. SimpleTag interface has a simpler and simple lifecycle - only one dotag method and there is no instance buffer pool and reuse. SimpleTag and its JSPFragment partner (used to evaluate the marker) can complete the current "Classic Tags" now, but compared with the previous comparison, you can save much effort. In addition, these more simple APIs means that markers can be easier to implement, which means BUG less.
Another improvement to the mark is the ability to write tag files. These tags are implemented as a JSP file rather than a Java class. The writing tag file is simple, and the deployment is simpler - you just put these files with the name of foo.tag in Web-inf / tags. You don't need to write a TLD descriptor file because all important information is declared in the tag file.
The maximum advantage of tag files is to mark some visual HTML elements. For example, the output of the BEAN is continuously formatted. Previously, HTML must be embedded in Java code or to take the way to contain a page. But the markup file is the most natural usage of this type. This also opens the door of the homemade creation tag to those non-Java developers. JSP 2.0 also improves syntax for supporting XML, joining JSR-45 support, and debugging support for other languages.
JSTLJSP Standard Tag Library (JavaServer Pages Standard Tag Library, JSTL) is a collection of very useful tags. These tags and JSP2.0 are well combined in other ways. Unfortunately, JSTL is not an essential component of the JSP 2.0 specification. However, since it is so useful, it has gained a wide range of support (eg, from Sun to Apache), it is worth mentioning here. Summarizing in the new version is full of new content, then how is the problem to use them?
All of these changes in the Web Development JSP specification have greatly improved the web development experience. Everyone is finally possible to write JSP pages that do not embed Java code. Also, the optionality of simple markers and tag files makes the label easier to write and easier to use. The separation between the user interface (view) and the rear end (controller) is also better. Message delivery messaging has many significance in MDB and JCA improvements. First, it is obvious that the two-way communication between the application server and EIS will increase J2EE integration with existing enterprises.
But other benefits are far more than this. First, in addition to the sockets owned by the container (RMI, IIOP, and HTTP), the inbound adapter has "right" creation and listening to the socket. So, for example, you can add a JCA adapter to make you telnet to the application server to perform some administrative tasks. Alternatively, the FTP server can be deployed as a standard J2EE JCA component, or the mail server can also be implemented. This possibility is endless.
Another possibility (this has been clearly stated in the specification) is the JMS provider. The J2EE specification requires the application server to implement JMS- but does not specify any requirements for a specific message delivery system. Therefore, each message provider usually implements their own message system to support JMS. Also, they usually have external systems to work with them to communicate. With J2EE 1.4, the message provider is now possible to create a homemade JMS support, like a standard that meets J2EE, the portable JCA adapter. At the end of the adapter, one end of the adapter can handle the message user, and the publisher is processed at one end of the station. This JCA then deployed into any J2EE 1.4 application server. This makes it a potential ability to improve interoperability between application servers, which is at least for JMS messages. Web services have J2EE 1.4 specification, J2EE has been combined with Web services. This has a variety of options.
First, if you have an existing EJB-based system, any stateful session bean can be published as a web service as long as you add a JAC interface and some entries in the deployment descriptor. This opens interoperability of existing deployments and web services.
For new web services, you can write EJB implementations as above, you can also write simple Java classes (using JAX-RPC). No matter which way you use, you can deploy some deployment descriptors.
In addition, you can use any Web services in the J2EE application, and the method is to call the web service using JAX-RPC when performing any other remote calls. Conclusion The enhancement of J2EE 1.4 is unquestionable and should enhance the usefulness and ability of the J2EE platform. Improvements in JCA and MDB are used to enhance the backend of enterprises. Increases support for web services to improve the usefulness and interoperability of J2EE. For those who wish to develop web-based user interfaces, the improvement of JSP reduces the thresholds they use. In short, this is a great combination.
Now, the most difficult thing is in front of you - J2EE developers, you need to decide, how to choose all these good things in your project. This will be an endless thing.
