March 26th, 2014, 03:51 AM
Architecture/design approach for this ecommerce middleware problem?
I was asked the below design problem in an interview two months back but that time i did not have any idea about webservices/jms so i could
not design it that time. But now after i have gone thru them and know how it works i came up with the design to the best of my ability.I am sure
there will be scope of improvement here or may be its not good design but i wanted to give it a shot. The reason i am going thru it is because
i found the design problem good to understand how should we construct the architecture of a system.
I need to design the backend system for ecommerce site.Lets call it EcomMiddleWareSystem(EMWS). This system can recieve
the request from various channels like webrequest(webservice/web request),messageQueue,File system. EMSW will reject the invalid(just consider some business validation)
request.This request will be the having details for orders like sender info, product id etc.Now this EMWS has mapping of productId and Supplier Id.
Now EMWS at End of day will process all the requests and send it to individual suppliers based on the mapping of productId and Supplier Id along with order id.
Supplier once receives it, send the acknowledgment.
My approach for high level architecture/design :-
As request can be be anything webrequest(webservice/web request),messageQueue,File System (but it will always be xml), we will have listeners corresponding
to each possible requests like jms consumer for jms queue, file listener for file, servlet for webrequest,rest servlet for restful webservices, soap handler
for soap request so that each has its own responsibility.Now these listener will send the acknowledgement as soon as they reciive the request.This way Sender
knows its request has been recieved and also will be asynchronous. Now all these listeners will call the central api say ProcessOrder.java so that we can reuse the code. More maintainable and reusable.
Now apis does business validation and send the acknowledgement for valid/invalid request in email.
Now For valid ones ProcessOrder will put the messages in java object form on JMS queue(we will have separate queue for each supplier) based on the mapping of productId
and Supplier Id.Now at the end of day consumer of this queue will make the xml request from java objects using xtreme api and send it to
to supplier as restful request (lightweight and simpler). Also important point is lets keep consumer on separate server it may be spring remote/or ejb server
so that we can distribute the load and saves cpu cycles. (I am assuming its big system where it gets millions of request in an hour)
Supplier will send the acknowledgement as soon as it recieves the request.
Folks let me know howz the design (be frank it would really help me to improve if you criticize for good reasons )and where it can be improved.
March 26th, 2014, 11:49 AM
Guyz any comments/advice would be really helpful. Eagarly waiting for the same
Originally Posted by LearnSoftware
March 21st, 2016, 07:56 AM
I think you should layer up the interfaces between the different components, to seperate all data handling to their single components ie ->
One component to handle the messageQueue, one component to handle filesystem, etc.
Once those have components to handle requests independently, you create an interface between them, and a single "facade" object, that then translates this information into some sort of XML request, that mimicks the existing system, if any. If not, you need a system spec, or to be the contractor, to know what is needed.
The facade, will handle acknowledgements, so a message tracking system would be required. I am thinking using an observer pattern, that fires events to a queue of requesets, is the easiest way to do that.
Create a single-ton object of the facade, but let it work in async, and if you have access to some sort of load balancing system, use that in front of the facade. So the requests cant be sent to a facade, that doesn't hold the request.
Either PHP or .Net can do this relatively easily. I would go for .Net solutions, because you could use a "biz-talk server to do all the message handling really. But that also depends on the budget? Yet it might actually be cheaper than building this system from stractch?
Or did I completely miss your point/question?