I recently entered into some API management tools. I could see these API management tools can do whatever Data-power is doing and these are also placed in front of back-end services to protect the back-end servers.
So,what makes Data-power unique?Or is it fair to compare Data-power with API management tools as its competitors?If yes, why IBM itself brought in a tool named IBM API management?
Ok, so the API solution from IBM, now called IBM API Connect (APIc) is more or less just the GUI to handle, set or view your APIS and statistics about them.
The actual HTTP requests (or IBM MQ requests) when using one of your API's goes through the API run-time.
IBM offers two different run-times today, MicroGateway (former StrongLoop) or IBM DataPower. DataPower comes as either hardware appliance, a virtual appliance or as a Docker container.
If you select to run APIc on DataPower you will be able to use all of the other features of Datapower as well (and there is a ton of them!).
MicroGateway is a Node.js runtime so it requires its own server and cluster obviously.
DataPower has built in cluster support and of course a DataPower appliance is built to sit Internet facing in the DMZ so all security is covered!
You will also have a few more functions/features in APIc using DataPower as the runtime.
So, to answer your question; No, it is not fair to compare APIc on DataPower with the competitors of "just" API solutions as DataPower brings in so much more to the deal. DataPower is a full grown gateway solutions for all your integration needs and it comes with FTP, sFTP, IBM MQ, Node.js runtime, HTTP server, SOAP WS-I, AS1-4, EDI (X12 and EDIFACT), etc.
If you want to compare to other API vendors you should really compare APIc on MicroGateway in my opinion...
You can test both APIc and DataPower (Docker) for free in "non-production" use:
https://developer.ibm.com/apiconnect/getting-started/
https://hub.docker.com/r/ibmcom/datapower/
Related
We've started our journey on a hybrid setup where we use a BizTalk on-prem and other teams in the company is working in Azure and want to use BizTalk as the glue between on-prem stuff and Azure, and since Service Bus is the new hyped thing, everyone is talking about that's where eve-ryone is going because messages can be handled async.
My team didn't get much choice in terms of talking solutions etc. how to handle this, the other simply decided to just go with a service bus straight up and pay for a premium tier to allow filers larger than 256kb, however even in BizTalk 2020 the SB-Messaging adapter does not allow larg-er than 1 MB because it runs on the SBMP protocol and not AMQP as the later SDK versions which is described on Microsoft’s own documentation.
We would have preferred to use AzureBlobStorage adapter with an event driven design that send a message to the SB that a message is available, but we’re force by their choice to go with a service bus, however since we’re limited to 1MB size because of the protocol and it seems like Microsoft does not plan on implementing AMQP protocol for the SB-Messaging anytime soon, CU4 does not change anything.
I was wondering if anyone else has found ways around this other than just straight up code our own adapter since each internal department doesn’t talk with each other at Microsoft and get-ting our internal to change their mind is a challenge on its own.
Tried updating BizTalk and searching far and wide if anything has solutions for this, I'm hoping for a workaround or just the confirmation that we need to develop our own SB-Messaging adapter that supports AMQP
How should I access a serial port on a client PC from a webpage in a production environment?
Ideally coded in C# and client Blazor, but any suggestions very welcome.
Any example applications on the web?
Web Serial API and Javascript option works in Chrome if you enable the experimental option: "Experimental Web Platform features" : Enables experimental Web Platform features that are in development. – Mac, Windows, Linux, Chrome OS, Android. #enable-experimental-web-platform-features
https://bugs.chromium.org/p/chromium/issues/detail?id=884928
Being experimental precludes use in a production environment till it is formally released (experimental licence must be renewed every 6 weeks, expires in September 2020 and the functionality can be removed by Google at any time.)
So far the only solution I can think of is to create an ASP.NET Core Service application that must be installed on the client and the webpage application must connect to this local API to use the local serial port.
Any technical issues that would prevent this service approach from working? Other approaches I should consider.
The web application will be designed to interface with a central/upper arm blood pressure monitor that outputs large XML (or JSON) results after each measurement. The measurements will be saved into a "cloud" service for research and patient monitoring.
Thank you in advance for suggestions and comments.
We are using mainframe application and from mainframe we write lots of messages to MQ to send to downstream. We are planning to migrate from MQ to Solace on mainframe. Is it possible? Solace supports mainframe applications?
How can we put messages to solace from mainframe batch and online(IMS transactions)?
Thanks,
Praveen.
Solace does not support mainframe applications directly but Solace can be easily integrated with IBM DataPower appliances which can interface with mainframe applications. The DataPower appliance can handle the transformation requirement of the service and the Solace appliance can handle the messaging portion to provide quick and efficient message delivery downstream.
The 'Solace Integration with IBM Datapower' integration guide, available on the Solace Developer Portal, has more information on this:
http://dev.solacesystems.com/integration-guides/ibm-datapower/
You may also be able to use Solace's REST interface, depending on your Mainframe application. Solace's REST interface allows communication using standard POST HTTP requests.
There are also guides for Solace's REST interface available on the Solace Developer Portal:
http://dev.solacesystems.com/docs/open-apis-protocols-docs/
Old thread, but Mainframe is a long lasting tech.
Solace now provide an open-source bridge for IBM MQ Bridge, so MainFrame<->IBM MQ<->Solace is possible.
Datapower integration using JMS to connect to Solace is still possible.
Solace REST Messaging API is still possible.
And finally OpenLegacy can help here :
https://www.openlegacy.com/
Telegram is a cloud based chat service. All of their clients are open source. I was wondering if there's a way to host a 'private' telegram service on my own server.
If not, is there anything out there that can provide all or almost all features that telegram provides?
According to the official telegram FAQ the current answer is no:
Q: Can I run Telegram using my own server?
Our architecture does not support federation yet. Telegram is a unified cloud service, so creating forks where two users might end up on two different Telegram clouds is unacceptable. To enable you to run your own Telegram server while retaining both speed and security is a task in itself. At the moment, we are undecided on whether or not Telegram should go in this direction.
So as long as the server itself is not open-source the entire Telegram eco-system cannot be considered open-source, even though there is an open API and official open-source clients.
There seem to be some unofficial telegram servers, but it's not clear how compatible they are with existing clients.
Some possible telegram alternatives
Matrix is allegedly providing "an open network for secure, decentralized communication" and has both open-source clients (Element being the 'official' one) and an open-source server that can be self-hosted. BUT while it looks good on the surface, there are indications that companies behind it have undisclosed intimate links with governmental actors (similar to Signal).
XMPP/Jabber has been around for a longer time, is an open protocol with multiple server and client implementations, and might be the least tainted by third-party interests. XMPP was the underlying protocol behind the original Google Talk messenger before it was rebranded to Google Hangouts and switched to a proprietary protocol.
Teamspeak a collaborative platform for teams, intended originally for gamers, free client and server.
Mumble a voice oriented solution which allows self-hosted servers.
You could implement a full working Telegram-API, then have hosted clients on your server via this API.
Your users would login on your web, then you sign them in via the hosted clients on your servers.
You are basically performing a proxy service to these users , and you can even integrate other value added features for you users this way.
NServiceBus and MassTransit are two tools that can be used to implement messaging with MSMQ and other message queues.
I find that once you start using messaging to have applications talk to each other, you don't really want to go back to the old RPC style.
My question is, what other tools are out there? What tools do you use?
Apache ActiveMQ is probably the most popular and powerful open source message broker out there with the most active open source community behind it as well as commercial support, training and tooling if you need it.
One of the more interesting aspects of ActiveMQ is its wide support for a large number of different language bindings and transport protocols
WebSphere Message Broker is IBM's flagship ESB which runs ontop of MQ.
They also produce WebSphere ESB which is a slightly lighter offering which specialises in ESB across web services.
We use WCF services for synchronous message based operations, and nServiceBus for anything asynchronous.
Rogue Wave is very popular [ http://roguewave.com/products/hydra/ ]
So are IBM's Websphere offerings [ http://en.wikipedia.org/wiki/Mqseries ]
WCF is extremely powerful and should be looked into by anyone in the .NET space starting up a message based system.
I would recommend against BizTalk unless you can make a lot of use out of it's adapters (ie. you have a lot of old systems to communicate with).
Nuedesic makes a great WCF based ESB, Neuron, if you are willing to pay a bit.
I use IBM software stack because it has the widest set of features (pub/sub, async, sync) and platform support (60+ combination of platform, languages) and also a great set of free tools provided by IBM
For Operations, I use use the linear log rotation IBM WebSphere MQ supportpac
For development and testing, I like RFHUTIL to generate fake cobol, java, MS objects, other binary and text objects and SOAPUI to invoke HTTP web services. If I need to invoke MQ based web services, I go back to RFHUtil. Of course Websphere MQ Explorer for admin.
We use the old WebSphere Message Broker 6.1 (now IBM Integration Bus) that is fast and reliable once you are acquainted.