I am working on a project where we are planning to use WLP (WebSphere liberty) instead of traditional WAS.
The code is having ejb modules (ejb 2 and 3) for different components.
EJB client of one component is used by some other components to talk with the EJB server module.
I know that liberty has some ejb features. But does liberty have same level of support/features for EJB as available in WAS 9?
What are the limitations/issues of using EJB with liberty ?
WebSphere v9 and WebSphere Liberty both support the full EJB 3.2 specification (which includes back level support for EJB 1 & EJB 2). However, there are some limitations in WebSphere Liberty when it comes to supported optional features and extensions that go beyond the EJB specification. The current limitations in WebSphere Liberty compared to WebSphere v9 are:
Entity beans : Liberty does not support the optional 2.x / 1.x CMP/BMP Entity Beans API group.
JAX-RPC Web Service Endpoints : Liberty does not support the optional JAX-RPC WebService Endpoints API group. (JAX-WS Endpoints are supported)
Update: New in January 2022, a Maven/Gradle conversion tool is available to migrate JAX-RPC applications to JAX-WS. See the following blog post and documentation for details.
Embeddable EJB Container : Liberty does not provide an implementation of the optional Embeddable EJB Container API group.
Transaction propagation : Liberty does not support outbound or inbound transaction propagation for remote EJB methods. Transactions are propagated within the server process, but not from a client or with another server process.
EJB Thin Client support : Liberty does not provide an EJB thin client, though does support use of the WebSphere v9 EJB thin client. Liberty does provide the full Java EE application client. Also, Liberty does not provide tooling to manually generate EJB stub classes for use with a thin client, though stubs generated with either RMIC (EJB 2.x/1.x) or the createEJBStubs command (EJB 3.x) from WebSphere v9 are supported.
Custom JNDI names : Liberty does not support binding EJBs into JNDI using custom names (from ibm-ejb-jar-bnd.xml). EJBs are made available in the specification defined locations in java:global, java:app, and java:module. Note: this support is in development, and you may follow the progress as detailed here : https://github.com/OpenLiberty/open-liberty/issues/7918
Update: Now available starting with Liberty 20.0.0.12.
Persistent timer failover : Liberty does not support failing over EJB persistent timers to other server instances. Note: this feature is in development (and currently in beta), and you may follow the progress as detailed here :
https://github.com/OpenLiberty/open-liberty/issues/7774 Update: Now available starting with Liberty 20.0.0.5.
Stateful session failover : Liberty does not support failing over the state of Stateful session beans to other server instances.
WLM : Liberty does not provide capability similar to the Workload Management support available in WebSphere v9 for remote EJB calls.
PMI : Liberty does not support the WebSphere Performance Monitoring Infrastructure that is provided on WebSphere v9.
Local optimization for remote EJB interfaces : Remote EJB calls within the same server process are not optimized, they will go through the full RMI/IIOP stack.
EJB MDB support for listener ports : Liberty supports using Activation Specs with message-driven beans.
Based on the description of your application, you may have issues with the use of EJB remote interfaces, due to the lack of support for transaction propagation, an EJB thin client, and WLM. You may want to consider exposing those beans as Webservice Endpoints instead (#WebService). Also, if the application uses custom JNDI names, like ejb/ABean or ejblocal:ABean, then you would need to switch those to looking up the beans using the specification defined locations such as java:global/<app>/<module>/ABean!<interface>.
Related
I am working on migrating ejb application from traditional websphere 9 to liberty.
My application source code uses remote transaction propogation. Is remote transaction propogation supported in websphere liberty? Any workarounds?
No, Liberty doesn't support transaction propagation. Check this page - Using enterprise JavaBeans with remote interfaces on Liberty.
Liberty does not support outbound or inbound transaction propagation...
The client can start the EJB if the EJB is changed to use the RequiresNew or NotSupported transaction attributes. However, the transactional work that is done by the EJB is not committed as part of the transactions of the client.
So my typical recommendations for such case are:
check if you really need remote interfaces - this is often legacy code, which had remote interfaces by default, but in reality all calls are local (same app/jvm) - if true, then switch to local interfaces
check if you can 'safely' change the Required to RequiresNew or NotSupported, without impacting application logic
if you cannot use any of above, you will have to redesign/rearchitecture your app, or add some custom code to handle manually these transactions, that now will be separate.
I’ve been learning a little bit about SOA and Oracle SOA Suite 12c, I barely understand that I can use BPEL Process in a SOA Project and that I cannot use it with Service Bus Project and that SOA Composites are deployed into the Oracle Enterprise Manager, while Service Bus Projects are deployed directly to the Oracle Service Bus.
My question is, does anyone know what are the differences between use SOA Projects and Service Bus Project even if I can consume services or use DBAdapter from any?
Is there any good reason to consume my soap, rest, dBadapters, etc in a BPEL Process in the SOA Project instead of doing it directly in my Service Bus Project?
Thanks in advance for you help,
:)
OSB is generally used whenever your flow is simple and light weight like- just DB call, web service call, message routing with few mappings. It can used as a proxy service (to hide the actual implementation) to the external system who is calling this proxy as a web service.
Whereas, SOA is preferred where the flow is complex with bulk transformation or heavy orchestration involving multiple intermediate calls to third party systems, etc.
You can go through the below link to get more information,
https://community.oracle.com/thread/1077167?start=0&tstart=0
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 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.
I am building a new Java EE application (thin client), and here is the application layers:
The application presentation will be with JSF2 / Spring webflow and RichFaces 4
The businees layer will be with EJB 3
The Persistance layer will be with JPA2 - Hibernate implementation
The application will run on Websphere Appliccation server.
The company owns Websephre Message Broker as an ESB.
I have got two choices, and i am trying to find out the best depending on the scalability, maintenance, performance, Best practices and entreprise architecture design, for each of them:
Deploy the business EJB3 Services on the ESB and deploy the presentation layer on a dedicated server: The presentation Layer will call the business services through the ESB
Deploy the EJB services on a dedicated WAS and deploy the presentation layer on a dedicated server: The presentation Layer will call directely the EJB services without using the ESB
It depends (as always :) ) If you plan to extend your application in the future and integrate it with other clients apart from the JSF client then ESB would be a viable solution. Else keep the things simple, i.e. everything in an application server. In case you proceed with the ESB I recommend you moving the EJB layer to the application server and exposing your application from the ESB as web services.
Here's my rec.... build your app on WAS using the architectural decisions you've made. For integration of your app to the ESB, I would vote for JMS or WebSphere MQ. You could opt for web services but as your enterprise architecture team would most likely say.... you need to have time independent communications with confirmed delivery.
If you want to also see how this all works, I would look at the IBM SOA Design Patterns or feel free to read my Redbook (IBM SOA Retail Design Patterns) for an idea of how to glue apps to the ESB.