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.
Related
QtConcurrent is extremely convenient as a high-level interface for multithreaded processing in my data-heavy/CPU-heavy application. The Qt6 upgrades vaguely referenced "Revamped Concurrency APIs" but I didn't see much change, except a reference to being able to pass a custom QThreadPool.
That got me wondering... is it possible to extend QThreadPool into a class that manages threads/tasks on other machines, not just the host machine? Or is that too far from its original design? Or is there another Qt class that can manage distributed processing?
Don't bother linking me to non-Qt solutions. That's not the point of this question.
QtConcurrent doesn't deal with any of it, unfortunately.
In a most general approach, you only need some worker machines on the network, and a way to connect to them via ssh (if they are Unix), or via Windows credentials (on a Windows network). At that point you can send a binary to the worker and execute it. Doing this in Qt is of course possible, but you'd need to wrap some other libraries (e.g. Samba for RPC calls, or openssh) to do that.
No matter whether the software can "distribute itself" or is otherwise installed on the workers, you got it running on multiple machines. Now they have to communicate, with one being a master, and the other being slaves. Master selection could be done via command line arguments, or even by having two binaries: workers that include only the back-end functionality, and a front end that includes both (and has some sort of UI).
At that point you can leverage Qt Remote Objects, the idea being what you'd "distribute" is QObjects that do work in the slots, and return results either via return value of the slot, by sending a signal. It's not as convenient as using QtConcurrent directly, but in general there's no way to distribute work transparently without some introspection that C++ doesn't quite provide yet.
I know that OpenMPI is not a Qt-based solution, it certainly works and makes life easy, and for sure it can interoperate with Qt code - you can even distribute methods and lambdas that way (with some tricks).
If you manage worker objects encapsulated as QObjects, it's not too hard to distribute the work in e.g. round-robin fashion. You could then have a front-end QObject that acts as a proxy: you submit all the work to it, and it signals all the results, but internally it invokes the slots on the remote QObjects.
Would you be interested in a demo? I could write one up if there was enough demand :)
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.
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.]