[IMAGE]
[IMAGE][IMAGE]
Paul Holm
[IMAGE]
[IMAGE]
A common requirement for business applications is to be able to manage documents from a Web application. Documents may include file types such as pictures, Excel files, Word files and video.
Related to that is the key requirement to upload images, video, illustrations, documents and many other types of files. What do you do when you want to upload and store binary files? I'll show you.
Our scenario
We needed to build several technical features. Those included the ability to upload any type of file from a user's system, store the uploaded files and present the files to users.
The code samples below are code fragments and I'll assume you have a working knowledge of HTML, SQL and Java.
More Information
[IMAGE]
Uploading files
This task involved prompting the user to select a file for upload, which can be easily achieved using standard HTML within a JavaServer Page (JSP). A common method for submitting data to the server within an HTML document is accomplished with the use of a form. A form allows for interaction with the user via several form controls, such as the select, input and button tags.
One of the most common tags that retrieves information from the us...
To continue reading for free, register below or login
To read more you must become a member of Search400.com
er is the input tag. A standard input can take on several behaviors, which are specified by the type attribute. The default type is text, and it results in a simple text input. Another useful type is the file input, which can be specified via the following HTML:
The file input type creates a field through which users can upload files from their local computer or network. The value attribute specifies the name of the initial file, but browsers typically ignore it as a security precaution. The accept attribute gives a comma-separated list of media types accepted, allowing the browser to filter out inappropriate files. Current browsers generally ignore the accept attribute. (Get more information about file input from the The Web Design Group.)
The file input presents a standard method to retrieve the data from the user; however, to actually read the data from the user's machine it gets more involved. To place a file input on the form, you must specify two attributes on the form. You must set the action attribute to POST and the enctype attribute to multipart/form-data on the form tag. Further detail about the format of mulitpart/form-data is available in RFC 1867 on the Internet Engineering Task Force Web site.
The enctype attribute specifies the content type used in submitting the form, it and defaults to application/x-www-form-urlencoded. This content type results in name/value pairs sent to the server as
name1=value1&name2=value2. . .
with space characters replaced by a plus sign (+) and reserved characters, like the pound sign (#), replaced by %HH -- where HH is the ASCII code of the character in hexadecimal. Line breaks are encoded as %0D%0A, a carriage return followed by a line feed.
The following example allows a user to upload a file to a servlet:
Storing files
We considered two methods for storing the uploaded files: the iSeries Integrated File System (IFS) and the iSeries DB2 database. Both approaches would have satisfied the requirements, but we chose the DB2 database and its Binary Large Object (BLOB) support for the following reasons.
The first reason was simplicity. Using the IFS requires the production of a naming scheme to associate files with a particular claim. That approach can become somewhat complex and problematic in that it requires you to manage the link, mostly likely contained in each database record, between your code and the directory structure where those files reside. If at some point the directory structure changes or is reorganized, or the data is moved completely, the links to those files must be changed for all the old records in order to reflect the new location and organization.
With DB2 BLOB support, we simply store the files in a traditional record, along with its associated "meta data." Referencing and maintaining the link between your attachments and your database record becomes a non-issue.
We needed to record "meta data," such as upload time, upload user and claim number, with each file. Using the DB2 approach, we were able to simply attach extra fields to our file and easily record this additional meta data. Using the IFS would have required an associated DB2 record to hold the meta data.
The second reason for choosing the DB2 database was adequate performance. We were concerned that the DB2 BLOB support would not perform well because of the need to read the BLOB out of the database for each viewing request. To minimize the risk, we put together a prototype application and verified that performance was adequate given our needs. We did not do any performance comparisons, but our thought was that the IFS may have an advantage because the Web server or browser could cache the files at their respective levels.
DB2 files with BLOB fields
A BLOB field is simply another DB2 field type. The following example shows the syntax for creating a database with a BLOB.
For this application, the field named FILE_BLOB was set to allow a file size of up to 10 MB. The size of this field would obviously be an area of consideration at design time, depending on the application being created and what was going to be stored in the BLOB.
The default size for a BLOB field in DB2, if not explicitly specified as above, is 1 MB. The maximum size for a BLOB field in DB2 is 2 GB. We felt that, in most cases, pictures, documents, spreadsheets, and the like would typically be accommodated by 10 MB. The larger the allowable upload, the more space your file will potentially occupy.
Writing the BLOB to DB2
Once the file has been uploaded by our Java servlet, it can be stored in the database, using standard JDBC. A very important consideration that comes with changing the encoding type of a form is that the standard method of retrieving values that are submitted to the servlet, out of the REQUEST object, changes with the multipart/form-data. Normally, the information entered on the form is stored in the REQUEST in the form of key-value parameters. The name of the HTML field for which the user entered data is the key that allows access to the value of the parameter.
Say, for instance, that we have an HTML text input field defined in the following manner:
The associated Java code that would get this value from the request would be
This scenario is changed with the multipart/form-data encoding. The process of gathering the binary data out of the request object, parsing the information and placing it an accessible form is involved and is beyond the scope of this article. A best practice that we recommend would be to wrapper the Request Object with a special object that would handle the parsing of the multi-part form data and place the data from the form in the attributes object of the request. (We recommend doing a Google search on "multi part encoding parsing Java" or similar keywords to obtain direction and insight into this process.) The following example assumes that such a wrapper class exists and we are able to retrieve the data from the request attributes.
Querying the BLOB fields
To display the files to the user, we again used traditional JDBC to read the appropriate records, as in the following example:
A BLOB field is read a little differently from traditional database types because of its possible large size. BLOB fields are read using the simple JDBC result set APIs. Once you have read the BLOB field, it is sent to the browser by obtaining the HTTPServletResponse and getting the outputStream.
You're ready for BLOBs
BLOB support provides a viable and powerful facility to store binary data of any type in a secured, well-managed fashion. Combining BLOB support with Web applications can allow your applications to store and manage binary files when your application requirements dictate. BLOB away! If you would like to see additional examples, fire me an e-mail, and I can send some more examples and code files.
---------------------------
About the author:Paul Holm is an iSeries WebSphere and Java specialist for PlanetJ Corp. He worked for IBM-Rochester for over 10 years as a DB2/400 and Java/WebSphere developer.
