How do I declare a bolt that participates in state management in Clojure, as
shown with a Java example here:
http://storm.apache.org/releases/1.0.1/State-checkpointing.html
Related
I couldn't understand when I should consider to use Datomic Ions.
What are the benefits besides having plain Clojure + Datomic project setup?
The benefits are listed at https://docs.datomic.com/cloud/ions/ions.html#benefits. Develop your functions at the REPL, deliver them on AWS a minute later.
For an extended walkthrough, check out https://www.youtube.com/watch?v=3BRO-Xb32Ic.
I am planning to use Siddhi for rule evaluation engine
I have below scenarios to be met
when the conditions are created by user need a way to persist them, which can be used when the node running siddhi restarts due to some reasons
I need a generic interface to represent the rules which are in layman's language not specific to siddhi. Because user should be able to configure the conditions without knowing siddhi
Any inputs on this will be a great help
If you are doing manually you can create a siddhi query as a template by including placeholders for conditions which needs to be configured. Then for those placeholders so a regex replace based on the values provided by outside.
Almost similar thing was done for Siddhi in old WSO2CEP 4.0.0 by providing a user instance to do the configurations. In this blog i have explained everything in detail [1].
Successor of the WSO2CEP is WSO2 Stream Processor which was released recently. It provides a much enhanced Business Rules Manager [2] to provide a generic interface via stored templates, that can be created with the Business Rules Template Editor [3].
[1] http://blog.tharik.org/2015/09/user-friendly-execution-management-with.html
[2] https://medium.com/#senthuran16/all-about-the-wso2-sp-business-rules-manager-e7e730b2abe7
[3] https://docs.wso2.com/display/SP400/Creating+a+Business+Rule+Template
https://states-language.net/spec.html
Is there an API/library which I can use to process states as per this standard. I understand AWS resources are available; is there anything independent of AWS and in the java library that can be used?
There is complete lightweight microservice platform (probably fastest on the market) called light4j eventuate. One of subproject is https://github.com/networknt/light-workflow-4j which implements Amazon States Language completely.
As of now, there is no Java implementation/bindings outside AWS.
Netflix Conductor blog states:
Recently announced AWS Step Functions added some of the features we were looking for in an orchestration engine. There is a potential for Conductor to adopt the states language to define workflows.
So - since their decider component is a Java service - maybe that could become a Java implementation someday.
https://github.com/totherik/step is based on nodejs and focused on openwhisk compatibility.
Looking at the sse-chat demo of the Clojure Pedestal Framework - which relies on the SSE features in Pedestal - I noticed the following code:
(defn publish
[request]
(doseq [sse-context #subscribers]
(try
(sse/send-event sse-context "message" (-> request :form-params (get "msg")))
(catch java.io.IOException e
(remove-subscriber sse-context))))
{:status 204})
Basically this keeps a map of subscribers (a map of EventSource clients) and sends chat events to them.
My question is - suppose you wanted to scale this application across multiple servers. What is an idomatic pattern in which to do this? (hopefully in Clojure Pedestal - but could be a solution from across the Java spectrum)
There is presently no free lunch/ silver bullet for multi-node parallelism. Most people use an SOA approach (REST, queues, etc) to parallelize their application. Of course in the large you lose ability to coordinate access to resources, and the work-arounds can be hackish. I have heard good things about Immutant's (Jboss's) XA transactions that automatically apply to how their caching and messaging work, but have not used this approach personally. Another tool you may find useful is Storm, which allows you to set up a topology for distributed processing, adding some declarative abstraction in place of tedious manual development and provisioning of equivalent service architecture.
I am going to develop a webservice which will expose two operations. These operation will query/update data from database.
Please suggest do i use EJB for database operation and what advantage i will get?
or
in my webservice i use JPA directly like following, and create my entities and persist them
#PersistenceUnit private EntityManagerFactory emf;
#Resource
private UserTransaction utx;
Please answer with advantages/disadvantages.
Regards,
imran
Both approaches are valid and supported by Java EE, so this is only a design recommendation based on my experience:
Do never directly expose EJB operations as Web Services, it only increases runtime complexity. If you publish an EJB as a Web Service the container must still wrap it by using an internal Web Services servlet which (implicitly) tightly couples your WAR containing the internal Web Service mapping to your ejb-jar (depends on app server product). Furthermore, it's hard to debug in day-to-day operations.
My recommendation using only standard Java EE features without any additional libraries:
POJO defines the Web Service interface, aka its operations (#WebService annotation). It delegates to a functional implementation. Let's call this POJO WS-POJO.
Two options to implement the functionality:
WS-POJO calls stateless Session Beans which provide the required functionality. Pro: All EJB features available (dependency injection, declarative transaction mgmt, etc.). Con: "Heavyweight"
WS-POJO calls custom POJOs following e.g. the Command Pattern. Pro: "Lightweight". Con: Dependency injection not possible; Entity Manager etc. to be passed.
Today, I'd go with option #1... my 2 cent