In recent weeks I've been researching Drools amongst other CEP/Rule Engines and I believe I would like to use Drools. I also have an JBossESB which is responsible for routing of messages between different services.
Unless I am totally missing the boat, I can't for the life of me see how I would get data into Drools via JBossESB.
Inside of my ESB I have data (facts) that needs to be monitored and routed correctly (some of the data properties also needs to be modified based on other properties in each of the facts, I figured using Drools (a combination of Fusion and Expert) would be the best way to handle this, however, I don't really see in any of the JBoss (or other) documentation how I would get that done.
Is this a cart-before-the-horse situation? Am I totally missing the boat somewhere?
Any help is greatly appreciated.
Thanks.
pretty late to respond...If anyone is still looking please see: http://java.dzone.com/articles/jbossesb-drools-integration
Related
We have a service that uses Drools quite heavily. Would like to improve the performance by running it on GraalVM.
Is it possible to run Drools on GraalVM without using Kogito?
Disclaimer: I'm one of the Drools developers
It's definitely possible, as you've already notice, we do indeed support native image compilation with our Quarkus backend, but it'll require you to write you some code, there's no such possibility in the current codebase.
Please note that only the executable model will be supported with the static component injection (the drools-core-static module in Kogito)
Is there a reason why you don't want to use Kogito though? We are really interested. Please join our community channels or the mailing list if you want to share your feedbacks, as SO is not the best platform for it.
Thanks for your support
I'm currently writing a document during an internship regarding the WSO2 Enterprise Integrator.
Problem is, I'm not going to work with it and definitely not going to write a single line of code, yet my job would be creating some guidelines that dictate how services (both SOAP and REST) should be orchestrated through the ESB.
The WSO2 documentation isn't helping me a lot because it mostly delves into explaining how to set up the Integrator and what tools are avaiable, and online I can only find simple tutorials which I can't really understand anyway because, as I said, I'm not even working with the platform.
So basically I don't understand if there is a specific conduct to follow when orchestrating services like "add this specific function in the service, create a dependency to the ESB" or whatever.
Any form of suggestion or just directing me towards the right documentation would be super helpful
Under my experience, what you must do is a proof of concept performing service orchestration, now by definition one of the characteristics of any ESB is precisely to be an orchestrator. I work daily with WSO2 and allows it in simple ways (with the same mediators) or complex ways (extending or creating new components)
PS: Excuse me for my English.
Regards !!!
I have recently built my own plugin for Glimpse to see all my Couchbase traffic, and would love to see statistics on what is going on in Autofac. Is there any work being done on an Autofac plugin for Glimpse? All I can find is the one from three years ago, but I don't think it shows a whole lot of detail.
Ideally what I would be looking for would be a full plugin that can do timings also, to measure the performance of Autofac using Glimpse and work out how much time is taken to resolve instances to isolate potential performance bottlenecks.
Has anyone done something like this? If not, does Autofac have hooks we could hook into to capture that stuff and log it?
I'm not aware of anyone who is currently creating a Glimpse extension for Autofac.
As you mentioned, there is an extension out there now, but it might not be as detailed as you'd like.
All that said, it seems like Autofac's Activation Events would make it pretty simple to create a new Glimpse extension to expose some of the data that you're after.
For timings, if you are using an IServiceLocator in MVC, you could also create a GlimpseServiceLocator which uses a Stopwatch to get timing information.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
How to version REST URIs
I'm new to REST-ful API design, and I can't seem to find a consensus for how to implement API versioning in the REST-ful style. The possibilities I've come across include:
URL-based (eg. /myApi/version5/someCall)
This approach works great for both servers and clients ... but it doesn't seem very REST-ful (urls are supposed to correspond to resources, and the API version really isn't a part of the resource)
Payload-based (eg. $.ajax({data:{version:5, ...)
This approach works great compatability-wise, but:
A) The server needs to actually parse the payload to determine the version (which tends to put the version-checking logic "deeper" in than it should be)
B) Again, from what I can tell of the philosophy, this isn't very REST-ful (as I understand it, the data I POST should only be the data for the resource I want to create)
Header-based (eg. Accept application/json;version=5)
This approach was suggested here, which I've found to be an excellent resource on how to make a REST-ful API. In this particular case however I keep running in to problems, as no matter what I do I can't seem to get jQuery to send the version in the header.
Now, I'm sure I can eventually solve the jQuery issue in approach #3 if I try, but it made me think that I might be going down the wrong road with header-based versioning; if I'm having trouble, it seems likely the consumers of our API would also.
So, when creating a REST-ful API, can anyone please explain which versioning approach:
A) will work with the best with other bits of technology (browsers, frameworks, etc.)
B) implement the "REST-ful" philosophy most faithfully
C) is most common (this one's not important on its own, but it does tend to be an indicator of the first two)
In other words, what's the best way to handle versioning in REST-ful APIs?
Solution 1 seems practical and simple. For your reference twitter(api.twitter.com/2) and linkedin(api.linkedin.com/v1) uses URL Based Versioning, Google Data(&v=1.0) uses Payload Based. My hands-on experience is in URL Based versioning.
If you want to do an analysis, check this api directory
I would strongly suggest solution 1, it's clear and easy - not only that even StackOverFlow uses it: https://api.stackexchange.com/2.1/questions?order=desc&sort=activity&site=stackoverflow :)
I am writing my own custom persistence instance store for WF4, based on the XmlWorkflowInstanceStore found in the .NET 4 WF and WCF samples. This sample is quite simplistic and the xml is produces is quite verbose. I have issues with how some of the objects are serialized.
I have tried using Red Gate Reflector to understand the Sql implementation used, but it is quite complex and difficult to learn from. The MS documentation for this is rather limited - often giving one sentence descriptions for complex methods.
Please could you point me at other examples of WF4 persistence (or proper documentation) around on the web that are not copy and paste versions of XmlWorkflowInstanceStore? Maybe someone else on StackOverflow has written their own?
You are completely correct that the docs are very much lacking here and the sample is of very limited use. I have started work on a custom instance store using the entity framework but, much like you discovered, found it slow going and am nowhere near anything I could use myself, let alone release onto CodePlex.
I am not aware of any blog posts or other information that help solve this.
You've probably seen this already, but I've found the code quite easy to understand: http://xhinker.com/post/WF4Xml-persistence-store.aspx
Ron Jacobs wrote an in memory persistence store for WF unit testing. Check out http://wf.codeplex.com/releases/view/73842