Async publish on a JMS topic using webmethods - asynchronous

How do I do an async publish for a JMS topic hosted on a webmethods broker? I am looking for something similar to what Active MQ provides, but using webmethods instead:
http://activemq.apache.org/async-sends.html

I'm not sure what you mean by "a JMS topic hosted on a webmethods broker", but you can publish any webMethods document anywhere in your flow with the pub.publish:publish service. You can subscribe to any published document by adding a trigger on that document type, along with the flow service that should be called when the document is received.
A bit different than ActiveMQ, but pretty straightforward.

Try this:
It has a sample C# project:
http://techcommunity.softwareag.com/ecosystem/communities/codesamples/webmethods/messaging/SAMPLE-20120523120201999.html

Related

Using grpc c++‘s async server api, should I add one (or more) cq per rpc method or just one cq for all service?

Using grpc c++‘s async server api, should I add one cq per rpc method or just one cq for all service?
I am taking over a grpc c++ service in my job. it use 10 completionqueue for a async service method , and yet another 20 completionqueue for another stream service method. The handling of the completionqueue is quite similar to the helloworld async service example, except that it use one thread worker per completionqueue.
Such a design is not very convenient for adding more service method. And I am thinking that refactoring it to using just one completionqueue, and dispatching the tags in the completionqueue to my own domain transactions handling thread pool.
Is it the right design pattern, or is there something better?
The best way to know the answer for your specific application is to create benchmarks with various scenarios and then compare the results from the different threading models.
Based on https://grpc.github.io/grpc/cpp/md_doc_cpp_perf_notes.html, the current recommendation is to use a pool of num_cpus threads with each thread polling over its own completion queue.

Publish Axon Events onto a Kafka Topic

I want to publish an event through one of my aggregate event handlers to the axon Kafka topic as I am using kafka as my event bus. What is the correct way to do that? Should I directly push the message to the topic or can I use AggregateLifecycle#apply(event) in this case?
I have multiple events getting published from my aggregate, through one of the event handlers I want to publish another event. I am using axon 4.2
Easiest would be to start using the Kafka Extension Axon provides. The shared repository contains all the necessary code to create a publishing end and a consuming end of Axon Event from and to a Kafka topic. For configuration convenience, there is a Spring Boot Starter present in that project too
Added, the repository has a (Kotlin) sample project showing how to configure it, which you can find here. Lastly, for a full description of how to set everything up, I strongly recommend to give Axon's Reference Guide a read, especially the Kafka page here.
I'd like to recommend you thought that this extension is perfectly suited to communicate between Axon and non-Axon applications, making Kafka a form of "Enterprise Service Bus". Using it as the EventBus replacement within Axon Framework is doable, but requires a bunch of fine tuning on you rend. It would be wiser to use Axon Server instead in those scenarios, or if you really must, share the data source containing your events directly between the applications.

WebApi loggin results async

I am using WebApi with Entity Framework to implement a REST service. I need to log the usage to the database. I can do this in the controller before it returns or in an ActionFilterAttribute. I want to be able to fire off a call to update the database, BUT I don't want to wait for completion. I want the response to return to the user without waiting for the update.
I was thinking about using a BackgroundWorker and passing in the objects.
Anyone have thoughts on if this is the good way to do this?
I think the question you should ask yourself is how much latency the database update can add to your overall response time. In most cases, it will be a lot simple to do the update as part of the request processing. Background worker is generally not a good solution but here is a good read related to that topic. If you absolutely need to do the database update outside of request processing, it will be better to consider a queueing mechanism like MSMQ, RabbitMQ, etc from the perspective of reliability.
I believe my performance problem is related to running in VS2012 debugger. When running the site directly, performance increased drastically. So I won't need to do any 'tuning tricks' if this proves out when deployed to test server.
Have you tried exploring NLog's async capabilities? We use NLog's async wrappers by wrapping a database logging target like so:
<targets async="true">
<target name="dbLog" xsi:type="Database" dbProvider="sqlserver" connectionString=".." />
.
.
</targets>
A quick startup on logging to MS SQL DB using NLog is found here
Moreover, you could make your logging method call async (.NET 4.5 required) and if you do not care for the result, choose not to await the method execution.
Look at this SO Thread for a sample NLog.config.

How does OWIN work?

I'm reading the OWIN 1.0 spec at http://owin.org/spec/owin-1.0.0.html and just can't wrap my head around how it works. I've downloaded Katana source, but that's huge and didn't help any. I'm familiar with the somewhat standard way of having a project/assembly with interfaces only, which allows to integrate two projects without direct regencies. But I can't understand how the web server will call into the web app with only Func<> and Action<> definitions.
OWIN boils down to two things:
1) an "environment" dictionary
2) a method that processes requests and sends responses.
For #1, this is just a property bag that gives you access to the request headers, request stream, response headers, response stream and server data. Think of this as your HttpContext for ASP.NET or HttpListenerContext for System.Net.HttpListener. In fact, in more recent builds of Katana (https://katanaproject.codeplex.com/, which is an open source implementation from the ASP.NET team, there have been improvements (more to come) to simplify this down to an easier to use object model, including an OwinRequest, OwinResponse, and IOwinContext.
For #2, this is often called the "AppFunc" and the signature is:
using AppFunc = Func<IDictionary<string, object>, Task>;
This signature is used for "Middleware" that is in a pipeline of request handlers or it can be the end application which is generating HTML, is a WebAPI, etc.
In Katana, there is a class you can inherit from that simplifies this signature to consume the IOwinContext I mentioned previously. Take at look at OwinMiddlware
You can also read this article which gives an overview of the Katana/OWIN effort: http://www.asp.net/aspnet/overview/owin-and-katana/an-overview-of-project-katana
OWIN just defines how the web server and web application will talk to each other. Your application must implement one side of this contact, the other side which connects to the web server must be provided by installing a NuGet package specific to the web server. There is one for IIS, one for self hosting (stand alone application) etc.

NServiceBus - How do I call NSB via web service but asynchronously

I want to achieve something similar to the webservice bridge sample but i don't want to wait for a response from the webservice. I want the call to be asynchronous.
What is the best way to do this?
Should I just use the webservice bridge and call ProcessAsync as opposed to Process?
or Should I not use the webservice bridge and just create a webmethod that calls Global.Bus.Send?
Thanks in advance
If you expose your NServiceBus endpoint using the built-in WebService functionality, then you'd do this like you call any web service asynchronously. The webservice bridge sample shows how you can set up your own web service rather than using the built-in functionality.

Resources