I am building a web app for which I need a bit of guidance in design. We have one application from vendor which uses SQL Server 2005 as database. Let’s say vendor’s application provides details on Order etc.
The web app that I am building will have its own database (SQL Server 2005). For my application to get any details about “Orders”, it needs to go thru BizTalk. So the flow would as below
a. User will type the order id in
TextBox (Web App), click submit
button.
b. Biztalk needs to receive this
order id, give this order id to
Vendor’s SQL Server Database to
retrieve the order details.
c. Order details should be sent back
to the Web App.
d. I also want to make sure that this
whole process (from a-c ) should be
real quick, as we do postback to
retrieve the information from
database.
Adding BizTalk into the application flow that you described will add a lot of overhead. It would be simpler, run faster, and likely be cheaper to create a WCF service that sits between the web app and the vendor's database for Orders.
BizTalk provides reliable messaging. So the application flow, as described in the question, would look something like this:
Web App Submit/Postback (IIS)
BizTalk Receive (IIS or MSMQ or whatever adapter you want)
BizTalk SQL Database
BizTalk Send (Request)
SQL Server Query Result
BizTalk Receive (Response)
BizTalk Database
BizTalk Send
Web App Receives Response (IIS)
With that you get message persistence and reliability. If something breaks (e.g., the vendor's SQL database is offline) there will be a suspended message in BizTalk and the web app will time out waiting for the synchronous response from BizTalk. Or you could also capture the error and pass it back to the web app using BizTalk and add more overhead to the process.
If you are only getting existing orders (i.e., not creating/updating/deleting orders), then you do not need your messages/transactions to be so reliable or expensive. If something fails the user will see an error and just submit again until it works (you can log the errors on the server to notify an admin, if desired).
Using something like a WCF service—perhaps with Entity Framework sitting atop the vendor's database—would still allow you to abstract the vendor's database from your web app and also provide:
Faster response times
No additional infrastructure (e.g., additional BizTalk services and SQL Server databases) since just runs in IIS
Less additional training for a developer who is already familiar with ASP.NET and not with BizTalk
This is really not an appropriate use for BizTalk. It would be more appropriate to write a WCF Serivce on your web server to expose the SQL Data. Have the app call the service directly. This will meet your requirement for real quick. BizTalk's reliable messaging comes at a cost... peristence points. By the time you request and receive the data, BizTalk will be writing and reading the data to the database many times. If the user was submitting an order, BizTalk would be preferrable for this as once the web app passes the order to BizTalk, you're guaranteed it will not be lost.
As another quick note, I am not up to date on all the cool new features in SQL Server, but I believe there is a way to have SQL exposes your data directly as a web service for consumption by your web app.
Related
i have a bit theoretical question.
When creating web applications, there is difference to desktop applications with working and active connection to database. So im curious if there is some solution, which can provide more desktop-like access to database e.g. transactions on asynchronous requests from client (web browser)?
edit:
So i figured out, that there can be a transaction process of asynchronous request, from client. Is there solution, which can provide it in web apps?
e.g I have assynchronou ajax call, which consist of multiple operations, and i wana to process them as transaction. If everything is okay, operations will be all done. But if one of them fail, just rollback it. Like its in DB. Is it possible?
edit2: maybe im wrong and the issue is not about ajax, but about whole web applications, but i dont think there is a way how to make a asynchronnous request from web client.
Transaction need continuous connection to database. To make it work with web application you need a platform which allow the application to run continuously independent of client request. Java servlet is best fit, php is a no-no. So I asume you will use java servlet.
In java servlet, you can create a db transaction, create an id for it, and then store them in a static variable or in the provided application-wide object, context. Then, return the id to the client.
When the client want to send another request, make it send the id. The application then can locate the transaction variable based on the id. As long as the application doesn't restarted between the two requests, the transaction is still there and active.
Because web application don't know when the user leave the application, you must create a mechanism to check the transactions periodically, and then rollback it if the user leave them for a specified time period.
The database has no knowledge of who is connected outside of authentication.
I'm designing a database monitoring application. Basically, the database will be hosted in the cloud and record-level access to it will be provided via custom written clients for Windows, iOS, Android etc. The basic scenario can be implemented via web services (ASP.NET WebAPI). For example, the client will make a GET request to the web service to fetch an entry. However, one of the requirements is that the client should automatically refresh UI, in case another user (using a different instance of the client) updates the same record AND the auto-refresh needs to happen under a second of record being updated - so that info is always up-to-date.
Polling could be an option but the active clients could number in hundreds of thousands, so I'm looking for a more robust and lightweight (on server) solution. I'm versed in .NET and C++/Windows and I could roll-out a complete solution in C++/Windows using IO Completion Ports but feel like that would be an overkill and require too much development time. Looked into ASP.NET WebAPI but not being able to send out notifications is its limitation. Are there any frameworks/technologies in Windows ecosystem that can address this scenario and scale easily as well? Any good options outside windows ecosystem e.g. node.js?
You did not specify a database that can be used so if you are able to use MSSQL Server, you may want to lookup SQL Dependency feature. IF configured and used correctly, you will be notified if there are any changes in the database.
Pair this with SignalR or any real-time front-end framework of your choice and you'll have real-time updates as you described.
One catch though is that SQL Dependency only tells you that something changed. Whatever it was, you are responsible to track which record it is. That adds an extra layer of difficulty but is much better than polling.
You may want to search through the sqldependency tag here at SO to go from here to where you want your app to be.
My first thought was to have webservice call that "stays alive" or the html5 protocol called WebSockets. You can maintain lots of connections but hundreds of thousands seems too large. Therefore the webservice needs to have a way to contact the clients with stateless connections. So build a webservice in the client that the webservices server can communicate with. This may be an issue due to firewall issues.
If firewalls are not an issue then you may not need a webservice in the client. You can instead implement a server socket on the client.
For mobile clients, if implementing a server socket is not a possibility then use push notifications. Perhaps look at https://stackoverflow.com/a/6676586/4350148 for a similar issue.
Finally you may want to consider a content delivery network.
One last point is that hopefully you don't need to contact all 100000 users within 1 second. I am assuming that with so many users you have quite a few servers.
Take a look at Maximum concurrent Socket.IO connections regarding the max number of open websocket connections;
Also consider whether your estimate of on the order of 100000 of simultaneous users is accurate.
I'm working on a client and server application, in which client requests 'client-specific' data from the server. I'm planning on switching to ASP.NET WebAPI for server so that client can take advantage of available .NET APIs to query server for data.
This scenario works perfectly fine when the client initially connects and requests data from server, However, instead of client constantly polling for data, it should just establish a persistent connection and the server should be able to monitor the database for changes and push new data to the client that has stale data. I came across SignalR and found that it can be used with WebAPI, but can't figure out how to integrate it with database monitoring i.e. a thread or process that is constantly monitoring database for updates. Any solution? I'm open to other non-WebAPI based .NET technologies as well - basically anything .NET based that will cut-down on the development time.
ASP.NET Web API supports PushStreamContent. Take a look at the section "Push Content" in http://blogs.msdn.com/b/henrikn/archive/2012/04/23/using-cookies-with-asp-net-web-api.aspx. Here, a timer triggers content written into the stream but you can use that to poll database and write into response or build some other better mechanism
signalR could fit your requirement. You can broadcast a message to all your user or just to part of them. Your client could be a browser (with javascript) or a .net client (WPF or else).
From the server, you can call a method on the client just like that
Clients.All.MyMethodOnTheClient(param1, param2)
or
Clients.Client(connectionId).MyMethodOnTheClient(param1, param2)
The topic is too broad to answer it in 5 min. I can advise you to start here.
Then browse the server api guide, the javascript guide and the .net client guide.
Don't worry. It's quite fast to have a complete tour.
I am trying to find the right approach for an application, that I am trying to develop.
Situation:
ASP.Net Website. User can make a request on a page. The request must result in an item in a qeue on the server. The qeue targeted is specific for each customer.
WPF client at customer site. The WPF client has a local qeue. The qeue gets filled by either polling the qeue on the webserver or getting a message from the web server. The WPF client uses the qeue to display items as specified in the qeue.
Each WPF client user has it's own account and can only access the qeue that is meant for him.
I dont have any constraints yet as to which solution to use, as long as it is .Net technology and the customer only requires my deployment package and the .Net framework. I can't hassle customers to install something like MSMQ.
I think a database on the webserver containing all the requests could do the trick, but I am wondering if there are any other slick methods that could be better.
Cheers, Momoski
You are going to want to have your clients pull from the web server/service and not try to push updates out to your clients. There is way to much complexity for a push solution unless you have complete control over all systems involved (i.e. network, firewalls, etc...).
I have a c# window form application (which is basically a game).
And an ASP.NET Website. the window form application has a database with a table that contains the username and his cash. The asp.net database has a table that contains the username and his cash.
Now I want to sync between to the two servers. Once I get point in my game, It'll also update the database of the asp.net site.
You could expose a web service endpoint in the web app which the Windows app can call to post updated user stats.
Likewise a web service could return updated stats to the Windows client for synchronization into the Windows app database.
As Uwe Keim mentions, the web app can only expose a service or data feed that the Windows client must poll regularly. There is no feasible way that the web app can call the Windows app directly.
Why not host the database on one location and let the game/website connect to your DB through a web service? This way you only need one database with all the relevant data compared to two. You'll have to recode some parts of your website and game but in the long run this is more optimal than two databases with the same data.
More information regarding web services can be found here.
You can develop some kind of an API (Service) in the web application and do the sync between the two apps. You are talking about two servers at the end of your post. What kind of servers are you talking about? Is the game available in standalone also? If not, can't you think of having a single DB for both of them?