I am new to playframework, so although this might be a newbie question, I need to ask. I have an application, where the database data can be changed by web requests, as well as by incoming emails.
I know that controllers are primarily used for web requests. Therefore, should I encapsulate the model modification logic in a separate class, which I should call from both the controller, and the guy who accepts the emails. Is this what the Service paradigm is used for?
Second, what should I use for the mail acceptor. A job or a plugin? Currently I created a job which refreshes itself every 10 seconds, but didn't know if it is appropriate to use a job to modify the DB. Perhaps, the job can trigger an internal event which a plugin will listen for ...
Yes you can update the model throught a job, job are transactionals.
For your common logic, if it relates to a specific model object, you can use a method on this object to put your common logic : put in static methods every code that is not tied to a specific instance and in non static methods logic that is tied to a specific instance.
Related
I am using Spring Framework to develop a web application. I have two services which are going to store some processed results into one table T in Database. The logic now is:
Service A
for all items:
result = func(item)
store result to Table T (with status = new)
is_running = False
Service B
for some items:
if is_running == False:
result = func(item)
store result to Table T (with status = new)
else:
store result to Table T (with status = inprogress)
The boolean flag is_running will be a field in Service A.
Since we have MicroService Architechture for the domain server, Service A and Service B may reside in different AP servers. How can I ensure Servie A and Service B refer to the same is_running?
Is it possible to use Spring's bean scope to achieve this?
Sprin is injection framework and itself does not have such functionality.
I'd re-write your question as following: how to implement cross-machine Boolean flag?
There are a lot of ways to do this. Te most straight forward ways are:
1. Via database. You can create table with single column and single line where you will store tor flag. You can even lock the table prior accessing it, so inter process communication will be guaranteed.
2. Use other tool that provides such functionality. For example I'd recommend you Haselcast. It is a java grid that among other features has atomic variables that share state among different processes and machines. BTW they have also a spring integration.
Short answer, No. Spring, is just a programming framework. It does nothing that Java inherently does't do. Cross process communication is one such thing. As suggested, you can store that is_running flag in some shared database and have both services access it before running their logic. There can still be race conditions and you need to consider your application's appetite for that. However, the logic might not just be that simple where you're not even checking what result is being stored with the given status. There must be some business logic around that, which would give you leverage with the synchronization logic to implement. The current logic mentioned will always depend on point in time value of is_running flag. Doesn't really look right.
Because we speak of microservices you are not allowed to share a database between them. One microservice should not depend/know/care about the other's technology stack. The state is owned by each microservice, it should not be accesed otherwise but through one's microservice API.
That being said you need a technology agnostic way of sharing that boolean flag between the two microservices. You can synchronously or asynchronously update the flag, that depends on your system's resilience requirements. You can use REST with JSON to hide the technology stack.
If you share a database you would loose the main benefits of the microservices architecture.
Global state is BAD for microservice architecture.
To solve your problem, both Service A and B should own their states (is_running) in its own database which is NOT shared with any other service.
Then expose that state via a simple API /serviceA/state and /serviceB/state. These endpoints should return the state (via JSON e.g.).
Each Service then should call the API of the other service(s) to check the state of that other service.
I have to save records to a database and then send some data to a restful web service. I need them to happen together. If one fails then the other should not happen as well. So for example, consider the following code:
saveRecords(records);
sendToRestService(records);
If saveRecords fails with a database constraint violation then I don't want the rest call to happen. I could make saveRecords happen in it's own transaction and commit it before the call to sendToRestService but there is still the potential for the rest service to be down. I could keep up with whether the rest service succeeds and if it doesn't then try to send them later. I was just wondering if there is a better strategy since this seems like it would be a common scenario.
Thanks for any advice.
why don't you try Observer design pattern?
I'm assuming saveRecords(records) and sendToRestService(records) methods are in two different classes.
If you use Observer design pattern, you can notify the class containing sendToRestService() method in case if the calling class object changes.
Ref: Observer Design Pattern
I need to poll a folder for changes i.e. files added, modified and deleted.
If I want to distinguish between the different types of events listed above would I need to implement a custom poller i.e. implement AbstractPoller. I have already implemented a poller that does this for a different project but would like to us spring integration and batch as I need to use other functionality.
What is the best way of doing this?
Thanks
Wouldn't you mind to share your code? BTW you always can utilize the custom code with <int:inbound-channel-adapter> as a ref and method, where an underlying POJO will return some object which will become as payload of message.
As you know the <int:inbound-channel-adapter> should be configured with <poller> how often you want to call that undelying POJO.
I have design issue when implement 1 simple web application.
I use struts2 web controller, spring’s IOC and Hibernate as persist layer.
Because this web application is very simple at begging. So I only have 2 layers:
1 DAO layer which used to access database. Almost every table have related DAO.
2 Action layer. User struts2.
I am satisfy with this architecture because can quickly implement my web application.
As project become bigger, I found the action layer become big and complex, and very hard to re-use.
I try to create service layer, to solve complex business logic is good, but my application still have a lot of simply logic. E.g: Load 1 object, save 1 object, and get collection by some condition and display it to webpage. If give each simple DB access method have corresponding service method. Still cost a lot of effort. How can solve this issue?
And I think, if service layer existing, direct call DAO layer still not good design for my application.
Is any good solution for this kind of small web application?
When planing the different layers in a web application it is good practice to explicitly protect attributes and associations in your model from being manipulated without providing an identity context.
This is something that should neither be done in the DAO layer nor in the Controller. You should wrap your DAO layer in a service layer and have the controller only talk to the services not the DAO directly.
Protecting your model against unwanted manipulation means that you for instance adapt the amount of information passed in a data structure between Controller and Service to the actual operation that you want to perform.
For instance: adding or removing an element from a collection is an explicit operation in the service, it does not happen implicitly by manipulating a collection as a member of a DAO object and passing that DAO back into the service.
Instead your service may look like this:
+ getAllCompanies(): CompanyType[*]
+ getAllEmployeesOfCompany(c: CompanyType) : EmployeeType[*]
+ addEmployeeToCompany(e: EmployeeType, c: CompanyType)
+ removeEmployeeFromCompany(e: EmployeeType, c: CompanyType)
The additional benefit of such an architecture is that the service layer serves as boundary for your transactions. Using the methods of your controller as boundary for your transactions is in fact a very bad habbit. You could even call it an anti-pattern. Why? Because for instance it would mean that when your client hangs up it would roll back your transaction. That is clearly unwanted in 99% of the cases.
As #mwhs commented, Apache Isis provides plenty of guidance on layering your app. To figure out whether it fits your requirements, you could run through this tutorial I presented at a recent conference.
Based on the question (How to create a client notification service for a webapp or should I use an Observer Pattern?) I will like to know.
I have a fully implemented DAO with Entity beans containing only getters and setters method. Each entity is mapped to an EntityManager.
Currently there are no way of notifying users of any changes added/deleted/updated to a persistent storage such as a database.
I want to know, how will I implement the Publish-Subscribe pattern (also known as Observer pattern) such that I don't have to extend my current DAO architecture. I don't want my entities to inherit the Publisher because not all entities are update-able.
If there are any tools/frameworks/libraries that I can use for my situation, please let me know. Also, I'm not using any persistent framework at all (framework such as Hibernate), the DAO manager and Factory was completely written from scratch by me.
Regards,
I am building a similar concept... I don't care about all events and within projects we want to care about different events. So, we are building a pattern where all DAO operations are submitted to DROOLS Fusion and based on rules and some temporal reasoning, it notifies listeners via a notification architecture. Depending on your needs, the architecture could be simple listeners or JMS or email... whatever. If you have no criteria, just care about a callback for DAO events, then have your DAO insert, update, delete operations submit the object to listeners or some type of JMS queue.
Hope that was clear...
Paul
The first suggestion I would have is to embed an observable object within your DAO. Then you would have your subs look at this object (I've done similar things in the past).
The other suggestion I have is that you could add a trigger to the database itself. This would be especially useful if there is anything outside of your app that could change the DB that you want to notify your sub of.
Good luck.