java-ee

Topics related to java-ee:

Getting started with java-ee

This section provides an overview of what java-ee is, and why a developer might want to use it.

It should also mention any large subjects within java-ee, and link out to the related topics. Since the Documentation for java-ee is new, you may need to create initial versions of those related topics.

Java RESTful Web Services (JAX-RS)

Unlike SOAP and the WS- stack, which are specified as W3C standards, REST is really a set of principles for designing and using web-based interface. REST / RESTful applications rely heavily on other standards:

HTTP
URI, URL
XML, JSON, HTML, GIF, JPEG, and so forth (resource representations)

The role of JAX-RS (Java API for RESTful Web Services) is to provide APIs that support building RESTful services. However, JAX-RS is just one way of doing this. RESTful services can be implemented other ways in Java, and (indeed) in many other programming languages.

The WebSockets API

WebSocket is a protocol which allows for communication between the client and the server/endpoint using a single TCP connection.

WebSocket is designed to be implemented in web browsers and web servers, but it can be used by any client or server application.

This topic about the Java APIs for websockets that were developed by JSR 356 and incorporated into the Java EE 7 specifications.

Java Messaging Service (JMS)

Java Message Service (JMS) is a standard Java API that allows applications to create, send, receive and read messages asynchronously.

JMS defines general set of interfaces and classes that allow applications to interact with other messages providers.

JMS is similar to JDBC: JDBC connects to different databases (Derby, MySQL, Oracle, DB2 etc.) and JMS connects with different providers (OpenMQ, MQSeries, SonicMQ and so on).

JMS reference implementation is Open Message Queue (OpenMQ). It is open source project and can be used in standalone applications or can be built in application server. It is the default JMS provider integrated into GlassFish.

Java Connector Architecture (JCA)

Let's clarify some terminologies first:

Outbound Messaging is where the message starts from the server (to be more accurate it's initiated from your app which you have on the server, WebSphere Liberty in this case) and end at the EIS.
Inbound Messaging is where message starts from the EIS and end at the server.
Message Endpoint in general the place where the message end up sitting/getting received at a specific stage of its life cycle.

So with outbound connectivity, we are referring the situation where an application obtains a connection to an external EIS and reads or writes data to it. With inbound connectivity we are referring the situation where the Resource Adapter (RA) listens for events from the external EIS and calls into your application when such an event occurs.

Illustration of an Outbound RA

Illustration of an Inbound RA

What is a MessageEndPoint mean in JCA?

The application server (ex: WebSphere Liberty) provides message endpoint MBeans to assist you in managing the delivery of a message to your message-driven beans that are acting as listeners on specific endpoints, which are destinations, and in managing the EIS resources that are utilized by these message-driven beans. Message-driven beans that are deployed as message endpoints are not the same as message-driven beans that are configured against a listener port. Message-driven beans that are used as message endpoints must be deployed using an ActivationSpecification that is defined within an RA configuration for JCA (Found in the ra.xml file) .

What does it mean activating a MessageEndPoint?

With message endpoint MBeans, you can activate and deactivate specific endpoints within your applications to ensure that messages are delivered only to listening message-driven beans that are interacting with healthy EIS resources. This capability allows you to optimize the performance of your JMS applications in situations where an EIS resource is not behaving as expected. Message delivery to an endpoint typically fails when the message driven bean that is listening invokes an operation against a resource that is not healthy. For example, a messaging provider, which is an inbound resource adapter that is JCA compliant, might fail to deliver messages to an endpoint when its underlying message-driven bean attempts to commit transactions against a database server that is not responding.

Does MessageEndPoint need to be a bean?

It should. Otherwise you will end up in a big mess by creating your own unconventional way of doing stuff which beat the purpose of following Java EE specification in the first place. Design your message-driven beans to delegate business processing to other enterprise beans. Do not access the EIS resources directly in the message-driven bean, but do so indirectly through a delegate bean.

Can you show some simple example on working/deploying a MessageEndPoint?

Check the second resource I'm mentioning below for a helpful example.

Useful learning resources:

The Javamail API

The JavaMail page on the Oracle website describes it as follows

The JavaMail API provides a platform-independent and protocol-independent framework to build mail and messaging applications. The JavaMail API is available as an optional package for use with the Java SE platform and is also included in the Java EE platform.

The primary site for the JavaMail project is now on java.net. From there you can find the javadocs for many versions of the APIs, links to the source code repositories, links for downloads, examples and hints for using JavaMail with some popular Email service providers.