I am looking for an MQ Client to use with Python \ Jython.
Looking for a stand-alone program so that I dont have to install anything in the machine I am running as it may have to be run on multiple machines. So I guess Websphere is ruled out. Want something which is stand alone, may be a jar that can be imported through Jython but if something could work using Python compiler and additional library that would be great.
As well as the download of the redistributable client that JoshMc mentions, you might be interested in the fact that the MQ jars are also available through Maven https://developer.ibm.com/messaging/2018/01/09/developing-mq-java-applications-maven/
There are also open source ways to talk to MQ with Python. For a simple pub/sub API there is the MQ Light API that talks AMQP to MQ (client can be found here https://github.com/mqlight/python-mqlight).
There's also the PyMQI project (https://pythonhosted.org/pymqi/), this requires an MQ client on the system, so you'd use the same redistributable MQ client package to obtain that.
Related
I know how to talk to MaprDB from Java program with Mapr client installed. But, want to know how can I connect to MaprDB without Mapr client installed? Is there a pure Java API (i.e. without needing to install any other software, just using some jars) for my requirement?
Please note - these are binary tables (and not JSON tables).
There is an approach that you can use.
The so-called DAG (data access gateway) is a gRPC-based gateway that you can use. There is a pure Java client for this. Performance impact is significant, but not massive and the API is the same OJAI API as when you access the database using the thick client.
See the following links for more information:
https://mapr.com/docs/61/MapROverview/MapRDataAccessGateway.html
https://mapr.com/docs/61/AdvancedInstallation/InstallingDataAccessGateway.html
https://mapr.com/docs/61/AdministratorGuide/AdminMapRDataAccessGateway.html
https://mapr.com/docs/61/EcosystemRN/MapR_Data_Access_Gateway_2.0_release_notes.html
Depends upon your definition of "without needing to install any other software".
You don't need to install the mapr-client package to access the MapR Cluster from a Java application - the MapR jars can be installed to your preferred location on the classpath or even shaded into an "uber" jar.
But you do need to be running on a supported client platform (Linux x86-64, MacOS x86-64, Windows i386 or x86-64), because the maprfs jar does contain JNI libraries packaged within it that it unpacks at initialisation time.
Our enterprise datawarehouse (EDW) sources data from many interanal & external sources. We use Oracle data integrator (ODI) as teh ETL tool to extract data from the sources. ETL jobs are executed using an ODI agent which is nothing but a Java process. One of the external sources for the warehouse is a webservice. Data is extracted from this webserice using Jython (wrapped within ODI). Jython as you might know is a Python variant which runs within JVM. The Jython job runs under the ODI agent (java) process and extracts data from the webservice.
Coming to the problem we are facing now- The external webservice provider has indicated that soon they will support only TLS 1.2 and will remove support for older TLS connections. The ODI agent is currently on JDK1.6 Update 33 and support TLS 1.1. We are planning to upgrade the ODI agent to Java 7 (which supports TLS 1.2) so that we will be able to connect to this webservice. The Java upgrade involves lot of work mainly to ensure that it does not break existing ETL jobs. If there are any impacts, we might not be able to upgrade. An alternate option is it create a separate Java process (outside of ODI) running under its own JDK (which can be even Java 8) to connect to this web service.
Are there any risks in the above options? It is going to take a while for the provider to give the webservice which supports only TLS 1.2. Are there any public webservices which support only TLS 1.2 that can be used by for our testing? Can you please share them?
Maybe not entirely what you're looking for, but it might be wise to have two seperate development projects for both the old and the future ODI agent to keep things transparent. Especially when testing the new version. It's also advisable to set up a dedicated testing/QA environment for this.
Be sure to keep your production ODI repository safe, you could use a testing repository with some exported projects for this. Maybe this link below might be useful: https://www.redbridgesoftware.com/products/life-cycle-management-for-odi.html
Is it possible to setup the IBM HTTP server as the front end for a non IBM Websphere application server (Glassfish, Apache Tomcat or other Java application servers) and is it supported by IBM? I tried to look for similar articles online but to no luck. I also tried asking IBM support but they haven't gone back to me as of this posting. Feedback will be very much appreciated.
It is possible, but not supported. To summarize the license options across different releases: you have either totally unsupported or bundled with an IBM product (like WAS) and supported when used in a way direct and necessary to support that product.
It's generally inadvisable, too. Because you IBM cares very little about the alternate modules used for this kind of thing and you can't service them yourself as a user. Contrast with just using Apache or nginx.
IBM HTTP is an enhanced variant of Apache HTTP Server. I have used it in the past as a reverse proxy in front of Tomcat Server (as well as other non application servers for example Websphere Message Broker) in the past. I am not really sure if the entitlement allows support from IBM to permit this , you will have to specifically check if the entitlements allow support on non WAS instances.
We have a requirment to connect to a JMS queue provided by an externally controlled IBM Websphere MQ server. Now, the easiest way to do it would be to include the Websphere MQ client into our application and just use the queue.
But IBM was so far not able to tell me about possible licensing costs of this setup. I saw forum posts and hints on IBM download pages that using the client is free of charge, but I do not know for sure. Maybe it's even the case, that the owner of the MQ server is allowed to provide us the client jar to use it for connecting to them, but again, I don't know for sure.
So I am evaluating the possibility to setup my own open source JMS server, for example an Apache ActiveMQ, and then bridge over to the Websphere MQ. For this, 2 questions rise up for me:
Technical solution: How would that be done exactly? I read a bit about bridging between JMS providers and something about the Apache Camel project, but have so far no exact idea how much work this will be and what needs exactly to be done.
Impacts: What should I bear in mind when implementing such a scenario? Do I still have to include the MQ client and such would not benefit over a direct connect? Are there any negative impacts compared to a direct connect that I must consider?
Update: Our application is a Java EE 6 application running on a JBosss 7.1. Concerning the MQ server version I have no information yet.
2nd Update: The MQ server version is 6.5.
The client to MQ is available for you to use; there's a license agreement to accept not a charge.
There are several options for how these client libraries could get to you practically.
You mention JMS is being used - within what container/environment is this? JavaSE/JavaEE/OSGi or something else.
JavaSE or the 'something else' would the JMS Client JARs.
JavaEE would need the IBM MQ Resource Adapter
OSGi would need the OSGi Bundles
In earlier versions of MQ there was the 'extended transnational client' that had a charge associated with it (pretty much the same as a full server) but that is no more.
As this is for JBOSS 7.1 - the solution would be to follow this link
http://www-01.ibm.com/support/docview.wss?uid=swg21633761
.. and download the IBM MQ Resource Adapter directly from the instructions there... 7.5.0.4 has also been released this last week. Please consider this as downloading the MQCxxx support pac will give you too much. This download does have the license agreement to accept but it's the same as the one has been highlighted elsewhere. It does mention Liberty but it's the same RA that is supported for within JBOSS.
For information on configuring the RA inside JBOSS please look at
http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_7.5.0/com.ibm.mq.dev.doc/q031820_.htm
The version of the RA or JMS client code is not tightly coupled with the server version. Client or bindings.
You won't have any support apart from via the web; unless you get the company running the externally controlled server to raise it.
Edit: have added download links
Pasting from this page
Category 3 WebSphere MQ SupportPacs are supplied under the standard terms and conditions provided by the International Program License Agreement (IPLA) and thus, carry program defect service for WebSphere MQ customers. Please read the IPLA and LI files that accompany the SupportPac, to ensure you understand the conditions under which the SupportPac is provided.
If you encounter what you believe to be a defect with the SupportPac, and you have a current license for a WebSphere MQ server product, you may request Program Services by reporting the problem via the same defect reporting channel you employ for the WebSphere MQ server product(s) on which you are using the SupportPac. No proof of entitlement is required to use this SupportPac.
Service is available for the v7.5 version of this SupportPac for as long as the WebSphere MQ V7.5 server product is supported by service. Refer to the WebSphere product lifecycle pages for the relevant service information. It is only supported with MQ platforms which are themselves supported.
I am thinking text in bold indicates MQ Client is free.
WebSphere MQ Client has no licensing fees. The only fees (and I think they did away with this one) would have been for the XA client. The client download should come with Client for JMS, which is not the same as Client for Java (native IBM API in java). When you install the client, just check to ensure you have /java/ which will contain all of the dependent jars for connecting to IBM MQ.
I would highly suggest using Apache Camel as your bridge vs creatng your own. You can then choose to run the camel route inside of the ActiveMQ JVM or other supported container. Most of the work will be learning how to do it the first time. Once you have it set up you will realize the time savings and power of Apache Camel.
No matter what you need MQ Client. MQ Server includes MQ Client, so if all this is on the same host you have nothing else to install. If by direct connect you mean bindings mode vs client mode, then yes, bindings mode is always the most efficient. And on the flip side, if you run your route in your broker you can take advantage of the VM transport.
The main considerations you need to think about for messages bridging between ActiveMQ and WebSphere MQ are really typical messaging questions. For example, Do you need the message to survive an outtage? If so, then consider using local transactions with your routes.
Bridging an ActiveMQ broker with a WebSphere MQ queue manager requires the same client libraries as a direct connection.
You are correct that you can pretty easy setup such a bridge using Apache Camel, that comes bundled with ActiveMQ.
One possible benefit from having a local broker as a buffer might be that your application can rely on a broker that is up and controlled by you. The remote/external controlled WebSphere MQ might be taken down for maint. by external parties or the network might be shaky. Of course, your application can handle such things using logic and rescheduled transmissions but it's far easier to set up a Camel route in ActiveMQ to do that and focus your logic in the application to do business logic.
I want to build an FTP server that has no actual files in the background. Rather I want the files uploaded to it being immediately processed by my backend. The file listing of the upload directories should contain those files that are not yet processed. Deletion or moving should not be possible.
Also, on the download side I want to present those files that I'm able to deliver. But files shall be created - again by the backend - on demand.
Since I don't want to reimplement FTP, does anyone know a Java library that helps implementing the server side of the FTP protocol, that is customizable as I need it to be?
I have looked into the always helpful Jakarta Commons but they seem to focus on the client side.
Thanks
Mike
[;-)
Check out http://mina.apache.org/ftpserver/.
The Apache FtpServer is a 100% pure Java FTP server. It's designed to be a complete and portable FTP server engine solution based on currently available open protocols. FtpServer can be run standalone as a Windows service or Unix/Linux daemon, or embedded into a Java application. We also provide support for integration within Spring applications and provide our releases as OSGi bundles.
The default network support is based on Apache MINA, a high performance asynchronous IO library. Using MINA, FtpServer can scale to a large number of concurrent users.
Maybe you can use Apache FtpServer.
The Apache FtpServer is a 100% pure Java FTP server. It's designed to be a complete and portable FTP server engine solution based on currently available open protocols. FtpServer can be run standalone as a Windows service or Unix/Linux daemon, or embedded into a Java application. We also provide support for integration within Spring applications and provide our releases as OSGi bundles.
Above mentioned links to Java FTP Server doesn't work because they have been moved to below:
http://mina.apache.org/ftpserver-project/index.html
Here's a couple which might be helpful:
http://drftpd.org/
http://mina.apache.org/ftpserver/
Since you do not actually want the files to be transfered and listed in a usual FTP behaviors, you'll need to intercept the codes of how the files are listed and retrieved by the clients.