I have the following requirements:
Implement a simple pipelined job service (further PJS).
Client writes a very simple application form and put it to PJS.
PJS consists of several individual processes that handles application in sequential order:
Verifier is responsible for verification of the application form format. It might be very simple handling mechanism i.e. check the matching user by his individual identity number (ID) in database (you can use simple text file).
Acknowledger receives verified application form and assigns it an unique identificator (autoincrement id or uuid).
HR receives application form from Acknowledger with assigned unique number, put it to the database and generate notification to the original sender (client) to message that he receives application form. Response have to be piggybacked with unique number assigned by Acknowledger.
There should be no intermediaries involved in the process of forwarding a job between servers: i.e. each server should pass the application directly to the next server. Stay focus on the system architecture and the process of passing applications around. Don’t implement complex data structures to represent application. It can be as simple as tiny json message.
How to implement this task?
I don't know how to return response from HR part to client directly, because client initially starts calling from Verifier.
I've understood the problem and solved myself, posting github link:
PJS
Related
I am building a REST API with a POST method which will be called from AWS Kinesis client, all works fine, but sometimes, data gets replayed and stored twice? Any Spring Java suggestions would help my problem.
What I usually do is simply hash incoming requests and store them in the user’s session or in a temp table.
Each hash is compared with the list of previously stored hashes with duplicates resulting in an error before the Spring request dispatcher invokes the appropriate handler.
If you don't use a session that use whatever distincts your user and act accordingly.
I'm playing around with setting up a microservices / cqrs architecture for a personal project, and there's one point I don't understand in the "standard" setup.
By standard setup, I mean
https://www.ibm.com/developerworks/cloud/library/cl-build-app-using-microservices-and-cqrs-trs/index.html
Say I have an orders service and a pickup points service, and I have a command like "send order summary email".
How should the orders service get the data about the pickup point (eg opening hours etc) that it needs to send the email ? I see 4 possibilities, but there are surely others.
The command goes directly to the orders service, and then the orders service queries the pickup points service to get the data.
The command goes to the pickup points service, and then pickup points service publishes a new event for orders service with the needed information attached.
The command goes directly to the orders service, and the orders service then queries the read-only client-facing database.
Merge the 2 services... given that they have no other shared context, this would be a pity...
Thanks !
how to get data from another service
There are two use cases for this. In your specific case, what you are describing is somewhat akin to UI Composition; you are creating a view that pulls data from two different sources.
Key point #1: the data you are composing is stale -- by the time the email reaches its destination, the truth understood by the services may have changed anyway. Therefore, there is inherent in the requirements some flexibility about time.
Key point #2: In sending the email, you aren't changing the state of either service at all. You are just making a copy of some part of it. Reads are a safe operation.
Key point #3: Actually sending the email changes the "real world", not the services; it's an activity that can be performed concurrently with the service work.
So what this would normally look like is that one of your read models (probably that of the order service) will support a query that lists orders for which emails will be sent. Some process, running outside of the service, will periodically query that service for pending emails, query the required read models to compose the message, send it, and finally post a message to the input queue of the order service to share the information that the message was successfully sent. The order service would see that, and the read model gets updated to indicate that the message has already been sent.
You are describing a process of sending an order summary email to the customer after the order is completed.
In CQRS this is implemented with a Saga/Process manager.
The idea is that OrderSummaryEmailSaga subscribe to the OrderWasCompleted event; when such event is fired, the saga queries the Pickup service for the information it needs (most probable from a read-model) and then:
it builds+sends a complete SendOrderSummaryEmail command to the relevant aggregate from the orders service or
it calls an infrastructure service that, having all the data, it builds an email and send it to the customer
or a combination of the previous points, depending on how you want to manage this process
The details are specific to you case, like what domain services (building and formatting the email) or infrastructure services (actual sending of the email using sendmail or postfix or whatever) you need to build.
Read/Write operations by multiple users.
A user may be able to make the editor read only i.e only the creator of the session writes.
You should be able to share the link of the current session to add more users to work on simultaneously.
It should be concurrent(synchronization) and avoid editing conflicts. Suggest approach to do this.
Please focus on a correct and scalable functionality.
Should have auto save
Editor should maintain changes/edits on each save.
Support rollback to any change.
Must have share/like functionality for social media.
I was able to come with the following, need help identifying classes to build a class diagram for this:
It will be a client server implementation.
For website, client can be written in HTML5 and Javascript. We can use additional javascript frameworks for specific requirements(eg. angularjs).
For sending request two methods are available:
1. Request/Response
-- Sending request every second
2. Long pooling
-- Make a never ending http request to server and communicate through it. This method will be way faster that earlier one because multiple http request will not be made.
Its the work of client to send the changes to server on fixed interval (1 second).
Its the work of client to understand the changes done by other users and display the same to current user.
Server will be expose an API which will be used to
-- Get current document
-- SendUpdate request whose response will contain modification done by other users on same document. We will try and capture the delta and represent the changes on the client side.
Server Stack has to be very fast(.node.js or golang will be suitable for such requirement) because of its very short response time.
Data should be stored in memory, we can use Redis to store data. We can on intervals or on explicit save requests, save data on the file system or non in memory databases also.
Every request will contain set of changes made by client.
These changes will be saved in Redis along with timestamp.
We wont be store whole file in database, we will just store historic changes. As redis is based on memory, it will take very little resource to compute final document from set of stored changes.
For every document there will be unique id associated with it. Unique id should be long enough.
You can create a url for notepads like example.com/notepad/{unique-id}
This will load the client and then load the document related to that unique id.
For every request this unique id will be send to identify which document is being edited by user.
Save
As every change is being sent to database, it will be auto saved.
Revert
You can keep historic data in AngularJs. If you want persistence between sessions, store data to file system.
You can also retrieve historic information from server using API. Which can be undone.
Facebook Share
We can also use FB graph api to post link in user;s timeline or Facebook exposes a sharer.php url, which can be used to share Post / Share a link in user's timeline.
Scalability
We can use cloud based scalable solutions like Mmazon AWS EC2 instances to implement this solution. We can keep webserver behind a load balancer.
We have to keep redis as separate (large) ec2 instance. There can be multiple webserver behind load balanacer.
All of them will be communicating with Redis instance.
We can keep static data like css and js in CDN (AWS CloudFront behind S3)
It will be a client server implementation.
Where server will be expose an API which will be used to
-- Get current document
-- SendUpdate request whose response will contain modification done by other users on same document
Its the work of client to send the changes to server on fixed interval (say 1 second).
Its the work of client to understand the changes done by other users and display the same to current user.
For website, client can be written in HTML5 and Javascript. You can use AngularJs as javascript framework for the same.
For sending request two methods are available:
1. Synchronization
-- Sending request every second
2. Long pooling
-- Make a never ending http request to server and communicate through it. This method will be way faster that earlier one because multiple http request will not be made.
Server Stack has to be very fast. node.js or golang will be suitable for such requirement, because of its very short response time.
Data should be stored in memory, you can use Redis to store data.
Every request will contain set of changes made by client.
These changes will be saved in Redis along with timestamp.
You wont store whole file in database, you should just store historic changes. As redis is based on memory, it will take very little resource to compute final document from set of stored changes.
We are evaluating the technology to be used for a web based application and some suggestions are to go with RESTful based services approach.
Tech Stack
1) Spring
2) Apache CXF ( JAX-RS)
My questions are
1) How state is managed between requests. For example, a user has been authenticated and now he is making a series of requests lets say going through a paginated report. I would imagine the URL for this will be like
domain.com/reports/customreport/page/1
domain.com/reports/customreport/page/2
etc...
a) Where is the user information & request parameters are stored so that it can be shared between requests.
b) Lets say the result is being streamed, where is Rowset is stored?
Is there a complete sample application something similar to Petclinic that can provide the best practices for such an application.
If you are doing RESTful strictly / properly, then user authentication is done in each request and there is no concept of a session. Each request contains enough context information (in the URL and/or request parameters) to allow it to work independent of a session.
1) How state is managed between requests.
It must be managed by the client.
a) Where is the user information & request parameters are stored so that it can be shared between requests.
User authentication information is stored by the client and provided to the server with each request. The server will recalculate any derived information about the user on each request. Any request parameters that would normally be stored in a server-side "session" must be passed afresh with each request.
b) Lets say the result is being streamed, where is Rowset is stored?
In the first instant, nowhere. The query is reissued each time with a parameter saying where to skip to. If performance was an issue, you could
read-ahead a few pages of the result set and store them in a server-side cache, or
tune the database query caching for the query.
1) The user information is not stored anywhere, the user has to send his credentials (or whatever authentication method you're using) on every single request.
2) Streaming doesn't make much sense in a RESTful API, if you would like to do streaming I'd greatly advice you to look for something like WebSockets (in Java you can easily do this with Jetty)
If you said streaming but you meant paginated results, same as 1, there is no state kept, the client has to send a new request with all the information and the server has to query the database (or go to a cache, or do anything needed) and return the result to the customer.
You should also read more about REST, as your question is quite vague, one good start is the Restful Web Services book or, if you feel adventurous, you can try Roy Fielding dissertation that defined what we call REST today.
I am trying to resolve a design difference of opinion where neither of us has experience with JMS.
We want to use JMS to communicate between a j2ee application and the stand-alone application when a new event occurs. We would be using a single point-to-point queue. Both sides are Java-based. The question is whether to send the event data itself in the JMS message body or to send a pointer to the data so that the stand-alone program can retrieve it. Details below.
I have a j2ee application that supports data entry of new and updated persons and related events. The person records and associated events are written to an Oracle database. There are also stand-alone, separate programs that contribute new person and event records to the database. When a new event occurs through any of 5-10 different application functions, I need to notify remote systems through an outbound interface using an industry-specific standard messaging protocol. The outbound interface has been designed as a stand-alone application to support scalability through asynchronous operation and by moving it to a separate server.
The j2ee application currently has most of the data in memory at the time the event is entered. The data would consist of approximately 6 different objects; a person object and some with multiple instances for an average size in the range of 3000 to 20,000 bytes. Some special cases could be many times this amount.
From a performance and reliability perspective, should I model the JMS message to pass all the data needed to create the interface message, or model the JMS message to contain record keys for the data and have the stand-alone Java application retrieve the data to create the interface message?
I wouldn't just focus on performance for the decision, but also on other non-functional considerations.
I've been working on a system where we decided to not send the data in the message, but rather the PK of the data in database. Our approach was closer to the command message pattern. Our choice was motivated by the following reasons:
Data size: we would store the data in BLOB because it could bu hughe. In your case, the size of the data probably fit in a message anayway.
Message loss: we planned for the worse. If the messages were lost, we could recover the data and we had a recovery procedure to resubmit the messages. Looks maybe paranoid, but here are two scenario that could lead to some message being lost: (1) queue is purged by mistake (2) an error occurs and messages can't be delivered for a long time. They go to the dead message queue (DMQ) which eventually reaches its limit and start discarding messages, if not configured correctly.
Monitoring: different messages/command could update the same row in database. That was easy to monitor and troubleshoot.
Using a JMS + database did however complicates a bit the design:
distributed transactions: this adds some complexity, and sometimes some problems. Distributed transactions have subtle differences with "regular" transactions, such as distributed timeout.
persitency: the code is less intuitive. Data must first be persisted to have the PK, which leads to some complexity in the code if an ORM is used.
I guess both approaches can work. I've described what led us to not send the data in the message, but your system and requirements might be different, so it might still be easier to send the data in the message in your case. I can not provide a definitive answer, but I hope it helps you make your decision.
Send the data, not the pointer. I wouldn't consider your messages to be an extraordinary size that can't be handled.
It will be no problem for the queue to handle the data, the messages in the queue are persisted anyway (memory, file or database persistence whatever fits better for the size of your queue).
If you just put a handle to the data in the queue the application that process the queue will make unnecessary work to get the data that the sender already has.
Depending on your question I cannot say what's the best in your case. Sure there are performance implications because of the message size and stuff, but first you need to know which information needs to be sent to the remote system by your message consumer, especially in a system which may have concurring updates on the same data.
It is relevant whether you need to keep the information stored in the remote system in sync with the version of the record just stored in your database, and whether you want to propagate a complete history along to the remote system which is updated by the message reciever. As a lot of time may pass in between the message send and the processing on the other end of the queue.
Assume (for some reason) there are a whole lot of messages in the queue, and within a few seconds or minutes three or four update notifications on the same object hit the queue. Assume the first message is processed after the fourth update to the record was finished, and its update notification is put in the queue. When you only pass along the ID of the record, all four messages would perform exactly the same operation on the remote system, which for one is absolutely superfluous. In addition, the remote system sees four updates, all the same,but has no information of the three intermediating states of the object, thus, the history, if relevant, is lost for this system.
Beside these semantic implications, technical reasons for passing the id or the whole data are whether it's cheaper to unwrap the updated information from the message body or to load them from the database. This depends on how you want to serialize/deserialize the contents. The message sizes you provided should be no problem for decent JMS implementation when you want to send the data along.
When serializing java objects into messages you need to hold the class format in sync between sender and consumer, and you have to empty the queue before you can update to a newer version of the class on the consuming site. Of course the same counts for database updates when you just pass along the id.
When you just send the ID to the consumer you will have additional database connections, this might also be relevant depending on the load on the database and how complex the queries are you need to execute to get the objects.