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.
Related
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>.
By reading the docs, it is clear that the only way to interact with corda is via RPC. If you want to interact via http, then we have to write a web server exposing specific endpoints.
I am trying to write a rpc client to start a flow in the cordapp without webserver.
rpcOps.startTrackedFlowDynamic(ExampleFlow.Initiator.class, iouValue, otherParty)
I couldn't understand properly here. Should I duplicate the ExampleFlow class both on client end and in the cordapp? What is the structure of rpcclient and cordapp in this case of not having a web server?
tl;dr Write a client to start a flow on already running corda node without webserver? Thanks
Yes - currently, the client must depend on ExampleFlow.Initiator and have it available on the classpath. This is true whether it's a webserver or a regular command line client.
Let's say I have a gRPC Java service that is hosting a Server.
So when a client wants to call this service, they use:
ManagedChannel channel = ManagedChannelBuilder
.forAddress(grpcHost, grpcPort)
.usePlaintext(true)
.build();
No problem.
Now what if I want to call my service from the same JVM? Is this even possible? Or perhaps this is completely invalid?
You are free to use plain ManagedChannelBuilder to connect to the same JVM. It will work just like normal.
If you want to optimize the case because it can happen frequently and are in the same ClassLoader (so it wouldn't work between Servlets, for example), you can use the in-process transport. The in-process transport has relatively low overhead and can even avoid serializing/deserializing the Protobufs.
There is a Windows service that I need to communicate with (in a duplex way) from ASP.NET. Is it safe to turn the Windows service into a WCF service and organize two-way communication?
I'm concerned about a scenario when the service is trying to communicate but ASP.NET process is getting reloaded and the message gets lost. Though it's unlikely during development, I guess it's quite likely in production with many clients.
I'm leaning towards a solution that involves some kind of persistence:
Both the Windows service and ASP.NET write data to SQL Server and get notified via SqlDependency
They exchange messages via RabbitMq
Here's a couple of ideas regarding the general case where two independent systems (processes, servers, etc.) need to communicate reliably:
Transaction model, where the transmitting party initiates communication and waits for acknowledgment from the recipient before marking the message as delivered. In case of transmission failure/timeout, it's the sender's responsibility to persist the message and retry later. For instance, Webhook architectures rely on this model.
Publish/Subscribe model, used by a lot of distributed systems, where both parties rely on a third-party message broker (message queue/service bus mechanism) such as RabbitMQ. In this architecture, sender is only responsible for making sure that the message has been successfully queued. The responsibility of making sure that the message is delivered to the recipient is on the message broker. In this case, you need to make sure that your message broker satisfies your reliability needs, for example: Is it in-memory only? Or does it also persist to disk and is able to recover from not just a process-recycle but also a power/system recycle.
And like you said, you can build your own messaging infrastructure too: sender writes to a local or cloud database or a cloud queue/service bus, and the receiver polls and consumes the messages.
So, a few guidelines:
If you ever need to scale out (have multiple servers) and they need to somehow collaborate on these messages, then make your initial investment on a database or cloud-queue solution (such as Azure SQL or Azure Queues).
Otherwise, if your services only need to communicate within one server, then you can use a database approach or use a queue service that satisfies your persistence/reliability requirements. RabbitMQ seems like a robust solution for this scenario.
I need to build a Windows Service in VB.net under Visual Studio 2003. This Windows service should read the flat file (Huge file of about a million records) from the local folder and upload it to the corresponding database table. This should be done in Rollback mode (Database transaction). While transferring data to table, the service should also be listening to additional client requests. So, if in between client requests for a cancel operation, then the service should rollback the transactions and give feedback to the client. This windows service also keeps writing continuously to two log files about the status and error records.
My client is ASPX page (A website).
Can somebody help me explain how to organize and achieve this functionality in a windows service(Processing and listening for additional client requests simultaneously. Ex. Cancellation request).
Also could you suggest me the ideal way of achieving this (like if it is best to implement it as web service or windows service or just a remote object or some other way).
Thank you all for your help in advance!
You can architect your service to spawn "worker threads" that do the heavy lifting, while it simply listens for additional requests. Because future calls are likely to have to deal with the current worker, this may work better than, say, architecting it as a web service using IIS.
The way I would set it up is: service main thread is listening on a port or pipe for a communication. When it gets a call to process data, it spawns a worker thread, giving it some "status token" (could be as simple as a reference to a boolean variable) which it will check at regular intervals to make sure it should still be running. Thread kicks off, service goes back to listening (network classes maintain a buffer of received data so calls will only fail if they "time out").
If the service receives a call to abort, it will set the token to a "cancel" value. The worker thread will read this value on its next poll and get the message, rollback the transaction and die.
This can be set up to have multiple workers processing multiple files at once, belonging to callers keyed by their IP or some unique "session" identifier you pass back and forth.
You can design your work like what FTP do. FTP use two ports, one for commands and another for data transfer.
You can consider two classes, one for command parsing and another for data transfer, each one on separate threads.
Use a communication channel (like a privileged queue) between threads. You can use Syste.Collections.Concurrent if you move to .NET 4.0 and more threading features like CancellationTokens...
WCF has advantages over web service, but comparing it to windows service needs more details of your project. In general WCF is easier to implement in compare to windows service.