Payara and GlassFish have supported classic remote EJB since its inception. Classic remote EJB uses RMI-IIOP (Remote Method Invocation over Internet Inter-ORB Protocol ) for transport and CSIv2 (Common Secure Interoperability Protocol Version 2) for security.

Following up from the first part of the Security Auditing  article, where we covered the audit logging,  in this part we will focus on creating a custom audit module.

Security is always a concern you must have when implementing applications that will run in production environments. Both the JVM and Payara Server have a strong tool set of security implementations for most use cases in the industry, so you won’t have to worry about implementing your own security measures from scratch.

In prior releases of Payara Server, it was not possible to control the maximum number of concurrent Stateless EJB instances in Payara Server. It was, however, possible to control the number of pooled Stateless EJB instances, as well as concurrent MDB instances. These features were available in Oracle GlassFish Server 3.1 and earlier but not in the GlassFish Open Source editions (3.1.2.x and 4.x).

In the current release of Payara Server (171), it is now possible to limit concurrent Stateless EJB instances that are dispatched, allowing fine-grained control of resources, limiting surface area for DDOS attacks and making applications run more smoothly and efficiently.