I have a requirement where I need to upload a large file (can be 10 GB) to a shared space(windows) ( say APP1) . and we have a separate application( say APP2) different network now I need to download the same file from in second application via internet.
My approach is I need to create webservice to upload the document to shared space. and then expose a webservice for outer world to download the document.
My point is how I can manage the huge files upload/download through webservice ?
Please suggest if some one have any idea. I have flexibikity to use any third party APIs.but the application can talk only through webservices.
From your question it's not really clear which development platform you mean, .NET, Java, etc.
Also it's important to know how interoperable your services should be, security requirements, etc. Anyway will try to come up with a couple of solutions which you might research in more detail if you found them useful.
.NET
It's relatively easy to built such a web service with WCF. It supports streaming which could be interoperable, reliable and secure to some extend. You can read more on this here. This approach implies you have a huge disk to store files and you have a good recovery plan for that in case it goes down or just dies.
.NET, Java, etc. - cloud based
There are a lot of vendors who provide cloud storage and APIs to work with it. It's an ideal solution for a quick start. They take care of data availability, redundancy, etc. All you have to do is to use their API to upload and download files and to pay them for this :) In many cases it's worth it. Personally I used to work with Amazon S3. Their API is simple to use and there's plenty of docs for that.
EDIT:
Amazon S3 provides a simple web-services interface that can be used to
store and retrieve any amount of data, at any time, from anywhere on
the web.
I think you should take a look at Amazon S3 overview here.
This also provides API for a number of different platforms - Java, .NET, Node.js, etc. You an find the full list here.
Hope it helps!
I need to design and implement a Java web application that can be used by multiple users at the same time. The data that is handled by this application is going to be huge and may take about 5 minutes for a page to display the results(database records).
I had designed this application using HTML, Servlets and JSP. But when two users would try to get the records, only one user was able to view the results while the other faced an error.
I always thought a web application would take care of handling multiple users but this is not the case.
Any insights on this would be highly appreciated.
Thanks.
I always thought a web application would take care of handling multiple users but this is not the case.
They do if they're written correctly. Obviously yours is not. That's all we can tell you unless you give more information, most importantly details of the error shown to the second user.
One possibility is that everything is OK on the web layer but your DB access for the first user causes an exclusive lock so that the second user cannot access the data at the same time. This could be fixed by using non-exclusive read locks. How to do that depends mainly on what DB you're using.
Getting concurrency right requires you to choose the correct tools and use them correctly. It doesn't just happen magically because it's a web app.
What are are using to develop this web-application? If you are developing it in your own way from the start I must say you are trying to re-invent the same wheel which has been already created and enhanced by very solid frameworks.
I suggest you analyze your requirements thoroughly and study some available frameworks. Let them handle the things like multi threading and other aspects in the best possible manner.
Handling multiple request at a time is a container work and as an application developer we have to concentrate how we are handling and processing those requret being forwarded by the container.
I must suggest you to get some insight how web-application work and how request -response cycle happens
I have created a small game in Java and I would like to add the ability for a player to publish his highscores online.
I'm willing to write the server software myself (it's easy these days with Ruby Mongrel, or even C++). I just need to have some sort hosting. One solution that immediately comes to mind is Amazon EC2. But that's kind of expensive for my needs. Since the requirements are very minimal (I don't even need a website, just a web service) I think there may be a cheaper solution out there.
Does anyone know of a free or cheap provider for this kind of thing?
Update
For those interested, this is solution I came up with:
a SliceHost
purchased a domain name
C++ HTTP server
built upon the Poco HTTPServer
uses SQLite database via Poco Data
Server implements a REST API supporting
High Score table
/hs content type deduced from accept header
/hs.xml forces xml
/hs.txt forces plain text
/hs/add html form, does a POST using XMLHttpRequest
/hof Hall of Fame, content type deduced from accept header
/hof.txt forces plain text
/hof.xml forces xml
game: my own Tetris clone written in Clojure
Something like Slicehost or any other small-scale VPS provider could probably work. You might even be able to write it as a small app and publish it on Google App Engine, which is free up to a certain point.
google app engine comes to mind: http://code.google.com/appengine/
I need to make a dashboard application using data from http://www.projects.zoho.com
It is a project management site.
ZOHO provides data about projects by APIs available at http://www.zoho.com/projects/developers/projects-api.html
So can I use XCelsius engage to make my dashboard?
Is it feasible & advisable?
Also tell me if any other tool like XCelsius is more suitable for me....
expecting satisfactory answers....
This shouldn't be a problem as long as the results returned via XML aren't too complex. Unfortunately Xcelsius has a hard time dealing with nested XML tags of more than a few levels so it is best to ensure that you try to conform data to a table structure. Taking this into consideration depending on complexity you may or may not have to massage data received from ZOHO prior to loading it into Xcelsius.
You also need to be mindful of flash domain security practices if you are not already aware of them.
Before you start flaming, I'm going to tell you that I am trying to convince myself that this is a bad idea.
Basically, I'm trying to create a website with some basic accounting functions. My friend, a consultant who only knows excel, asked if this could be an excel spreadsheet instead of a web interface.
I found myself thinking, why is excel not the better tool in this case? It has all the tools a web2.0 app has (scripting, access to a db, basic formatting), and is made for accounting. You could basically use excel to write a program that fetches data from an SQL database, populates some cells, and use formulas for the rest.
Is there precedent to using excel as one would use the browser to make an ajax-y web2 app?
Why is this a bad idea?
Update: just to clarify I meant this to be more a "rhetorical" discussion. I'm not sure why the rest of the message didn't clarify that...
Well, if you made it in excel, then it wouldn't really be a web application. It would be an Excel application.
Not that that's a bad thing though. If it makes more sense to build the app in Excel, then go for it.
The problems you'll have doing it in Excel will be the same as the problems you run into with any desktop vs. web application. For example, How do you handle deploying new versions of the app? How do you handle updating the app for new (or older) versions of Excel? etc.
ETA:
If you want to avoid the bugginess of Excel VBA and the headaches of managing a desktop application, you might want to look into the Google Spreadsheets API. You can use it to create/update Google docs spreadsheets on the fly, including formulas and lots of other spreadsheet goodness. Using a hybrid of web application and Google Spreadsheets might give you the best of both worlds, depending on what exactly you need to do.
After years of programming in Excel-VBA, the best answer that I can give you for not doing this:
Excel-VBA is buggy! It is probably the most bug-filled app that Microsoft has produced. It's great for some tasks, but forcing it to do a job for which it was never intended will lead to trouble.
I have a few spreadsheets that do similar things, (things Bill never intended), and without exception, they teeter on the brink of failure, and tend to crash with only the slightest provocation.
Sure, you can do it, but the headache is not worth it.
Excel was not meant to be used that way, so it will be painful.
Two better ideas for web-spreadsheet integration:
Take a look at Resolver One, a programmable Excel-compatible spreadsheet with an integrated web server.
Use Google Docs spreadsheets. There is an API to interact programmatically with them.
It's not a bad idea, but it does come with some limitations. If deployment isn't an issue for you, and you don't need "universal" access to the application, your solution will likely save you some time. A web application would certainly be a more elegant approach, particularly if you want to make the software available publicly.
The web is inherently based on HTML and added to with Databases, CSS and server-side languages and javascript (possibly others). As with most things, you should use the right tool for the job. If you want a website then you should use the tools for creating a website.
Excel is not meant to make websites, forcing it to do so will likely lead to more frustration than happiness.
Well, you're going to run it on the server side, you'd probably run into licencing and performance issues.
If you're delivering .xls to the client, then you'd need for all your clients to have Excel or something compatible. But you also lose control over your "site" - what's the point of visiting if you have everything you need locally?
So, the SQL statements would be on the client? That's rarely a good idea.
It's a bad idea for the same reason that writing a graphics editor with MS Access is bad, or coding a MMORPG using Powerpoint is bad :)
I would also say that once you stop using a browser as the client it ceases to be a "web application" - you are really just talking about an Excel sheet which fetches its data via HTTP.
+1 to everyone who said "an excel app is not a web app."
BUT... If you want to use the spreadsheet metaphor for server-side calculations for a web app, or if you want to access the library of financial functions that come with Excel from server-side code, you can use Excel Services. It's exposed via SOAP, interoperable, callable from any SOAP-capable platform.
It's server-capable. It does not actually load Excel on the server, but a non-GUI runtime of the functions.
I think that using Excel as Browser is bad idea, however i think better idea is to use Excel Control in Desktop App.
This way you can control the sql and connections. you can save data as often as you like. you could also implement some update mechanism. App would be more secure and harder to hack.
I think Excel freezes when you try to connect to some outside resource and this way you would control everything.
Did you start by getting user requirements for this application? It doesn't sound like they wanted a website to begin with. Sounds like they wanted an excel spreadsheet with macros.