| There is a great deal of discussion about web services and how they can be used to share information over the internet. Typically a web service is designed to receive a request and immediately respond to it. It allows applications to talk to each other by using a standard message structure known as XML. Of course, the whole web services concept is widely used in certain forms and well understood by many developers. |
| However, there are instances where we need to share information with outside parties over the web but may not desire an immediate response in the same way a web service would respond. Instead, what we need is a place to store the initial request and allow the recipient to complete portions of the request over time. Then pull the result of their work back into our application. This need really shows itself in the research and analysis field I currently work in. For instance, let's say that your organization's analyst constructs complex data models that include a wide array of product details and the leading vendors that compete in this arena. Wouldn't it be nice to create a way for vendors to accurately answer analyst questions and automatically feed the answers back into their data models? |
| As they say, necessity is the mother of invention and the idea of creating a Web Workspace began to take form. This concept allows for the extraction of data from the main application or process, upload that data to an internet web server(s), use an internet web site user interface to wrap itself around the data and collect responses, and eventually import the data back into our main application or process. Of course, I didn't invent the concept but I hadn't found an authority on the subject as I would have liked to have benefited from someone else's experiences. So, I put this together to give you a high level overview of my experience. |
| |
 |
| |
| As you can see, the whole concept is really not that complicated. But, it opens up quite a few doors of opportunity to help your organization be more efficient in the ways it collects data from outside parties. The initial design of your Web Workspace is critical (as it is with all software development efforts). So, I thought I would outline the steps I took that turned out to work extremely well and cut down my development time. |
| |
| 1. | Design and create at least 80% of the web site's user interface and functionality first. |
| You'll likely be able to determine about 70% of the data needed in the XML coming from your main application during your normal design meetings. However, you are likely to miss data elements needed to make the browser based user interface function as well as desired. An effective user interface may require data elements (even if they are left blank to start with) that aren't necessarily related to data from your main application. By mocking up test XML documents to build your web site around, these missing data points will soon become visible. Identifying the proper elements early on will reduce the amount of code adjustments and retesting needed. |
| 2. | Do not convert the uploaded XML streams from hierarchial data structures to relational database structures. |
| If at all possible, leave the XML document in tact. Mass data capture using an XML document is likely to be much more efficient than updating several individual rows in a database table. |
| 3. | Carefully review the size of the XML documents to be used and any security requirements. |
| Depending on these requirements, you may be able to work with the XML documents as physical files on the web server (with read/write permissions of course) instead of incurring the overhead of storing XML in a database table. You'll also want to review whether XML compression is needed. In my case, 1-5MB files were being used and sometimes uploaded over modem connections. Thus, compression was a must for speed. You may need to consider securing the web site with a certficate. It may not serve a real security purpose but may make outside parties feel more comfortable sharing critical information over the web. |
| 4. | Identify browser requirements |
| If possible, try to require that users have either IE 5.5 or NS 6.2 and above. I was quite successful with using iframes in a visually pleasing manner to create an extremely user friendly web site for mass data entry. This is key to getting outside parties to use your web workspace over existing cumbersome methods they are more familiar with. |
| 5. | User accounts |
| You'll want to allow your main application users to create web accounts for their outside parties and grant workspace permissions. Initially, they will be the primary contact and defacto trainer for outside parties who use the web site. They'll need to be able to log on with the same user info to test and confirm the site (and their data) works as expected. |
| 6. | Workspace administration |
| After you have created a prototype of the web workspace, meet with end users to discuss post web workspace creation administration tasks such as changing expiration dates or workspace descriptive information. Remember, the main application users will need a great deal of flexibility when managing their workspaces. |
| |
| Now that you've got a solid grasp of the Web Workspace concept, you can review areas within your own company where it may improve productivity. The article below provides a great code example to help get you started from a coding perspective. It contains other links that will be useful as well. |
| Web Service vs Web Workspace Part II |
| Web Services - Server To Server With XMLHTTP |