Suppose you have a web site consisting of:
A web server serving your various users requests
A DB for persistence
A separate server asynchronously doing background stuff - preparing the data on the DB, updating it according to changes, etc. - regardless of what's going on in the main server.
You can easily translate this into another world and talk about threads for example - i.e. having one thread preparing the data asynchronously for a main thread which is running.
Is there a name for this pattern, if it is a pattern at all?
Are there any pros/cons for this method of processing data in terms of performance?
Let me just clarify that I'm asking specifically about the second web server doing background processing, and not the whole architecture.
Everything has patterns. If you've seen it more than twice, there's a pattern.
You've got three examples of Client-Server.
You've got Browser-Web Server.
You've got web server in the role of DB Client talking to DB Server.
You've got web server in the role of App server client talking to an App Server.
Sometimes folks like to call this N-Tier since there are at three tiers of Browser-Web Server-DB Server, plus an additional application server tier.
Some folks expand this into the Services Bus concept. Your web server uses DB server and application server.
The Asynchronous Back-End and Back-end Server are names I've heard to describe your application server architecture.
I don't have a pattern name for you (not to say there isn't one), but what you have here is an optimization to keep your main thread from responding slowly to requests. It doesn't have to calculate data, it just has to provide it.
This is similar to UI coding. You don't do any work on your UI thread, you just draw. Other threads should be responsible for figuring everything else out, so your UI is responsive.
I don't know if it's officially a pattern name but this looks almost like batch processing from the mainframe days.
Related
I'm trying to implement reasonably complex architecture using Heroku. I have a Java application that reads/writes data from one source using REST and puts results onto a queue using RabbitMQ. A Django application then reads from this queue parsing data collected then saves to it's database. The Django application feeds Android and ISO apps through GraphQL. The problem I have is Heroku only seems to let me define one web process in my Procfile where in fact I need two. One for the Java application and one for the Django application. Is there anyway I can make this work?
There is no un-hacky / good solution to this. And as the comments stated, it is a bad idea to combine codebases here.
Following Heroku's ideas here, you would split these into separate applications/services that communicate to each other via HTTP or the queue.
Many addons you can attach to multiple applications if they are shared. So you have the same queue.
I am working on a project using ASP.Net Web API that will be receiving a large number of POST operations where I will need to write many successive / simultaneous records to the DB. I don't have an exact number per second so this is more of a conceptual design question.
I am thinking of having either a standard message queue (RabbitMQ, etc) or an in-memory data store such as Redis to handle the initial intake of the data and then persisting that data to the disk via another process (or even a built in one of the queue mechanism has one).
I know I could also use threading to improve performance of the API.
Does anyone have any suggestions as far as which message queues or memory storage to look at or even just architectural recommendations?
Thanks for any and all help everyone.
-c
Using all this middle ware will make your web application scale, but it still means the same load on your DB. Your asp.net web api can be pretty fast with just using async/await. On async/await you just need to be carefully to do them all the way down - from controller to database and external requests - don't mix them with Tasks because you will end up with deadlocks.
And don't you threading because you will consume applications threads and this way it will not be able to scale - leave the threads to be used by the ASP.NET Web API.
I tried to take a more detailed look at REST - Spring seems to love it so much, and I am confused. REST is fine for basic CRUD operations on "resources", but it seems awkward for applications which need to keep state, such as workflow applications. I read in one of the answers on SO, can't find it now, that the state should be kept on the client. This seems strange: what prevents then the client from cooking up a request, claiming he is in a state which he is not in? A way around this could be that the server sends to the client his next state signed, and the client then uses this signed state on his next request to the server. If anyone has seen a "RESTful workflow application", is this how things actually get done?
REST = Representational STATE Transfer. Client and server exchange the state of a resource. So basically it's kept on the server and updated (/created/deleted) by the client.
REST isn't awkward at all for workflow applications, however you may define that. The most difficult part when designing REST applications is designing the representations and most of all the resources. A resource isn't merely an entity from the database.
As #NeilMcGuigan has mentioned, the RestBucks sample application deals with workflows. There's a video on the SpringSourceDev Channel on YouTube, where Oliver Gierke presents the application.
I am writing a Java EE application which is supposed to consume SAP BAPIs/RFC using JCo and expose them as web-services to other downstream systems. The application needs to scale to huge volumes in scale of tens of thousands and thousands of simultaneous users.
I would like to have suggestions on how to design this application so that it can meet the required volume.
Its good that you are thinking of scalability right from the design phase. Martin Abbott and Michael Fisher (PayPal/eBay fame) layout a framework called AKF Scale for scaling web apps. The main principle is to scale your app in 3 axis.
X-axis: Cloning of services/ data such that work can be easily distributed across instances. For a web app, this implies ability to add more web servers (clustering).
Y-axis: separation of work responsibility, action or data. So for example in your case, you could have different API calls on different servers.
Z-Axis: separation of work by customer or requester. In your case you could say, requesters from region 1 will access Server 1, requesters from region 2 will access Server 2, etc.
Design your system so that you can follow all 3 above if you need to. But when you initially deploy, you may not need to use all three methods.
You can checkout the book "The Art of Scalability" by the above authors. http://amzn.to/oSQGHb
A final answer is not possible, but based on the information you provided this does not seem to be a problem as long as your application is stateless so that it only forwards requests to SAP and returns the responses. In this case it does not maintain any state at all. If it comes to e.g. asynchronous message handling, temporary database storage or session state management it becomes more complex. If this is true and there is no need to maintain state you can easily scale-out your application to dozens of application servers without changing your application architecture.
In my experience this is not necessarily the case when it comes to SAP integration, think of a shopping cart you want to fill based on products available in SAP. You may want to maintain this cart in your application and only submit the final cart to SAP. Otherwise you end up building an e-commerce application inside your backend.
Most important is that you reduce CPU utilization in your application to avoid a 'too-large' cluster and to reduce all kinds of I/O wherever possible, e.g. small SOAP messages to reduce network I/O.
Furthermore, I recommend to design a proper abstraction layer on top of JCo including the JCO.PoolManager for connection pooling. You may also need a well-thought-out authorization concept if you work with a connection pool managed by only one technical user.
Just some (not well structured) thoughts...
I have started working in C# for almost a few months and I am looking for something more challenging and interesting. I use a media player called media monkey that supports custom vb scripts, well I made one that writes a file to a dir that has the current song playing, and is updated every time a new song is playing by rewriting what was there before.
Now I want to add this information to a database and keep a record of this and possibly add the information on my home page. I know I can hack a way for it to work, but I want to know what would be the "professional way" of doing things.
I came up with the following and got stuck. I would need an ODBC driver to connect to a database which seems messy, would a web service work? How would that work? Can a VbScript call a dll file to call upon a web service to modify data on a seperate server? Is that safe to do?
Many professional C# apps are n-tier. In your case, you would probably layer it like this:
On the server:
-Database Store
-Database Access/Business layer(sometimes two distinct components, depending on how complex the app is)
-Web Service
On the client:
-Web Service Client
-Any other layers to support client functionality.
So the Database Store would be something like some tables in an Oracle or Microsoft SQL Server, and would on your server.
Database Access/Business layer would be your code that retrieves and stores data to/from your database. It might also contain business objects, which are basically classes that have properties representing your data from your database. The benefit of the data access layer is that sometimes reading and writing to a database can require specialized code, and you don't want that code sprinkled throuought your application. So instead you can call functions in your data access layer that loads needed data into objects, so the rest of your application is just interacting with a regular old .NET object/class. These are called POCOs, which stands for something like Plan Old CLR Object. There are lots of variations on this of course, as people have taken different approaches to the problem of isaloting database access. Also it serves the purpose of minimizing breaking changes whenever the database changes. Since the database access logic is not sprinkled throughout the app, then there are fewer places that need to be updated if the database changes (such as adding new columns to a table or changing a name).
Sometimes the business layer will be it's own layer, and would contain most of the "logic" of the application. It would sit between the data access and web service layers. Using concepts from Service Oriented Architecture (SOA), you might have an authentication service, and a web request handling service. These services are a lot like a class that is always instantiated, there waiting to process requests. Your web request handling service would take a request, and maybe first call into the authentication service to verify credentials before honoring the request. SOA is one of those things I think should be used only when appropriate. It some cases just using Object Oriented techniques will give you the same benefits. Not always though. SOA, when done right, is more scalable, so it really depends on whether SOA offers you additional benefits that you need.
The Webservice would be responsible for receiving requests from the web, parsing/interpreting them, and acting on those requests by making calls into your business layer to update or retrieve data.
So the concept here would be that you could have many users of your service who publish their song updates through your service.
Your client would have a "web service client" layer which would be responible for formatting requests into messages, sending them to the web service, and retrieving messages from the web service. You would put very little application "logic" in your web service layer.
Now all this is probably overkill and inefficient for what you are wanting to do since you just want something for yourself, but it's the basic anatomy of a lot of webservice applications and would be a good learning exercise. The whole purpose of the layers is decoupling and simplicity. While more layers/components makes the application overall more complex, it means each component is simpler. This means it's easier to wrap your head around problems when you are only dealing with one component which interacts with only a couple other components(the sourounding layer). So there is a careful balance between few components and many components. Too few and they become monolithic and difficult to manage. Too many, and they become intertwined in complex ways. I have heard it said something along the lines of "If a class is getting too big and too complex, then split it up into a few more classes". In essence, don't start subdividing stuff for the heck of it just because it sounds like the right thing to do. Evaluate how complex your component is going to be before deciding if you want to split it up. Sometimes for simple cases your have a layer serving more than one purpose, for the sake of getting it done faster and making the overall design simpler. The point is, apply these concepts where appropriate. You will learn what is appropriate with experience, and you obviously understand that you can learn the most by "doing".
"Can vbscript call a COM component?" You can compile .NET DLLs with COM support. Many older things can call COM dlls.
I googled: vbscript dll
and got this: VB Script and DLLs
"Is that safe to do?" Your webservice will be where you would be most concerned with security. It's safe only if you design with security in mind and don't screw up. We all screw up sometimes though, which means there is no guarantee of it being perfectly secure.