Is calling a remote #remote interface from within the same EJB-JAR or EAR would make the app server use RMI/RMI-IIOP?
Or the App Servers would be much intelligent and doing this call locally as if it calls a #local interface???
The container should not do a truly #local call because #local call pass by reference and #remote calls pass by value. However the container can optimise the #remote call so that the full RMI/IIOP network stack is not hit. As I recall WebSphere does such "local" optimisations, I can't speak to other vendors.
[History: Way back in early pre EJB3 versions of WebSphere there was an option to enable the moral equivalent of the "make #remote look like #local" but I don't think later version do offer this.]
Related
We have used "Yo!CorDapp" example (https://github.com/corda/spring-observable-stream) to build a POC.
In this POC, can we replace angular by .NET for frontend and use IIS webserver in place of springboot webserver to talk to Corda platform?
Thanks
You can use any front-end technology you want.
As of Corda 3, your backend must be JVM-based, for two reasons:
You need to load various flow, state and other class definitions onto the classpath to pass as arguments to flows, retrieve objects from the vault, etc.
You need to use the CordaRPCClient library to create an RPC connection to the node
If you really need to write your back-end in another language, there are a few workarounds:
Create a thin Java webserver that sits between your main webserver and the node. The Java webserver translates HTTP requests from the main webserver into RPC calls to the node, and RPC responses from the node into HTTP responses to the main webserver
This is the approach taken by libraries such as Braid
Use a library such as GraalVM to compile non-JVM languages to JVM bytecode
An example of writing a JVM webserver in Javascript using GraalVM is available here: https://github.com/nitesh7sid/cordapp-example-nodejs-server-graalvm
I want to have Local and Remote interfaces of an EJB in same JVM(Weblogic server instance) Is it possible and how can I achieve it.
calling Local EJB is performance benefit as call-by-reference is used.
If possible how it can be defined in deployment descriptor(ej-jar.xml, weblogic-ejb-jar.xml
You can have both interface of course, the client will use either #Remote or #Local depending on where it is located if local or remote.
But the point is, as you have already pointed out, the two interfaces serve a completely different purpose.
In theory a remote interface is supposed to be coarse grained, while a local interface fine grained. This 'graining' is driven by how objects are passed within JVM or between JVMs, and because of network issues.
To simplify (a lot), tipically with #Remote interface you pass the id and reconstruct the object in the business layer, while using #Local allow you to pass the entire object as a reference.
So, if you implement both, expect/design your bean to have different sets of methods serving specific purpose.
I'm trying to implement a inbound resource adapter which will receive a data through HTTP protocol. I have two variants of implementations: to use Jetty as inner server and to use web container from WildFly. I know how to use Jetty, but think that Undertow using is the best. But how? WildFly does not see #WebServlet in RAR. How can I tell to WildFly to deploy a servlet which is located RAR?
When it comes to the point where the whole ecosystem is against me, I usually ask myself whether I'm sure the whole idea is right. Your idea does not seem to be right at all. Still, if you're sure, I'll explain the way of doing something that is close to what you want.
The idea of using servlet inside a resource adapter is a bit odd. Implementing an inbound HTTP adapter is odd either. In some logical sense, servlet container is an inbound HTTP resource adapter itself. It doesn't really utilize JCA container, but it's quite close to what an inbound resource adapter would stand for.
Another reason for not doing so is that resource adapters and application deployments have quite different life cycle. While WAR/EAR deployment represents an application which 'serves as it lives', the RAR semantic is quite different: instead of doing some business logic, resource adapter just provides interfaces for other deployments. You can bundle RAR into your EAR for sure, but if you're not targeting a monstrous monolith, you'll end-up deploying RAR as a separate artefact for your applications to use. Resource adapter should not contain any particular business logic. If you need it to do so, consider rethinking whether you need an application server at the first place: JCA container is quite poor comparing to EJB and Web ones, and if you don't need all the power, Java SE might come in handy.
Now, if you're still 100 % sure you need this, let's take a look at your options:
You may try to implement ServiceActivator -- a JBoss-specific start point for custom extensions. From within this activator you can access UndertowService and perform servlet container bootstrap manually. Here is an example of SA-powered artefact from Wildfly team. Since your question is quite unusual, I cannot confirm whether JCA deployment will support it, but it seems to.
If you cannot just force Wildfly's web container to process RAR deployment, you could fall back to a manual container instantiation. Undertow itself is just a module inside Wildfly so you can access it by specifying module dependency clause in your RAR's JAR manifest like so:
Dependencies: io.undertow
Undertow's classes will then be available to you upon deployment through your classloader and you'll be able to instantiate a new server with custom servlets inside.
I have an EJB3 bean that needs to GET or POST from multiple HTTP servers. I have read the documentation on writing JCA adapters, as well as the documentation on Apache HTTPComponents, specifically the managed connections, managed connection factories, etc. that HTTPClient offers.
I note that the documentation for BasicHttpClientConnectionManager says to use it, rather than PoolingHttpClientConnectionManager "Inside of an EJB Container." It is unclear whether "Inside of an EJB Container" refers to user code in an EJB to be run in a container, or to the container's own implementation code (e.g. something you might put in a JCA adapter.
I'm still a little unclear, architecturally, how to handle the task to take maximum advantage of the servics offered by the container. Thus far, my choices seem to be:
From within the EJB, create a new BasicHttpClientConnectionManager, and then create a client, like so:
BasicHttpClientConnectionManager cxMgr = new BasicHttpClientConnectionManager()
HttpClients.custom().setConnectionManager(cxMgr).build()
This would, I believe, result in no connection pooling, but rather EJB instance pooling, which probably wouldn't be all that performant since the EJB container has no way of knowing which bean instance is holding an active connection to which remote HTTP server.
Write a (fairly minimal) JCA adapter that wraps the PoolingHttpClientConnectionManager, and then, within the EJB, grab that adapter with a #Resource annotation and use it to build the HTTPClient
Write a JCA adapter that manages a pool of HTTPClients and hands those out when needed.
I am unclear on which approach I should take, or on whether or not I'm ignoring some sort of HTTP Connection management service that's already built into the container (in this case, TomEE plus). How should I do this?
It's not that simple: none of those options match. The particular answer depends on whether remote side of your HTTP connection is a single resource or not.
If it's a single logical resource, then JCA matches best. Still, you should hardly avoid any references to it's HTTP nature in your adapter: design a proper logical interface for your remote system and then implement a resource adapter upon that interface. Your clients request the data they need and then receive it not as HTML strings, but as ready-to-use Java beans. You will be able to utilize much of advantages provided by EJB container without it's requirements violation.
If you need an entry point to access unspecified number of external services (HTML pages search indexing might be this kind of job), then things get tricky. JCA is not intended to be used for that kind of things, but it suites them quite for sure: I am maintaining TCP SocketConnector project which does almost the same and everything works like a charm. EJB won't fit here: stateless beans pooling is hard to control, singletons will require you to write non-blocking pooling implementation yourself and statefuls are, well, kind of single-threaded.
There's also an extra option: while JCA will be easier to integrate to your existing Java EE environment, it might be hard to implement a resource adapter from scratch if you're doing it for the first time. An external HTTP querying tool which is connected with a JMS queue might come in handy here. JMS will make it easier to balance workload, but it removes any interactivity and may slow the whole chain down.
P.S. For the third option of your original question: there's no need to implement pooling in JCA as container already maintains connections pool for all resource adapter instances by default. Just keep a single HTTP Client connection per JCA's ManagedConnection and everything will work out-of-the-box.
Suppose I have two or more different server applications developed in Clojure using ZeroMQ and BSON as protocols. How can I deploy them using a single JVM instance while also sharing common dependencies?
It seems a waste of memory to use a JVM instance for each standalone application. I plan to develop several Clojure applications in the future and VPS memory is not cheap.
Although not explicitly said, applications running in an application server (Jetty, Glassfish) seem to share the same JVM while isolating their state. However, they require a container and neither Servlets or Enterprise JavaBeans have an implementation that I could easily adapt to my custom protocol.
I've been thinking about using Servlets and implementing a dummy service() method though I don't like the idea of having a pointless HTTP server overhead. As for the EJB container, I cannot even figure out its implementation.
It would be nice to have a container requiring only init() and destroy() methods but I can't find an application server providing it.
Maybe there is a way around or I don't even need an application server. Could somebody point me in the right direction?
It sounds like you would be okay using an EJB container, but only if it were easier or simpler to work with. Have you looked at Immutant? It's basically a wrapper around JBossAS for Clojure, written by guys at Red Hat (who also own JBossAS).
In addition to being an application server, those guys have wrapped JMS and other Java-EE features around Clojure, such that sending messages between apps appears pretty simple:
Also, they have Daemons and Jobs, which may provide something similar to what you were describing as simple services with init() and destroy().
That being said, I haven't used it, so I'm can't vouch for it's awesomenss/awfulness.
So you have two applications that both share the same dependencies and both want to respond to and/or generate events on a message bus.
If I understand what you're saying, this should be as simple as starting the JVM with access to all code in the classpath and initializing your message bus and your code from a main method.
If you wanted to use a container, you could create some dummy message driven beans that sat between your clojure code and the message bus assuming there is a JMS adapter for your message bus. Using netbeans/glassfish, this may not be that bad. You might gain some in terms of monitoring, but I'm not sure what else you would gain.
I kept searching and found out that some application servers implementing the OSGi service platform have simpler lightweight containers than those offered by Java EE.
Apache Karaf for instance can load POJO applications directly from JAR files.
I am not sure what DDs are but any JAR is a valid bundle. Since clojure is not type safe you will need to bridge the clojure world and OSGi/Java world but the OSGi API is a wet dream for such bridges.
Not that in OSGi bundle do not automatically provide their content, in OSGi a bundle is by default private. However, the API allows you to punch holes where ever you want.