Software Development for Automatic Filling in the Web Forms Based on a Configurable Template
Automated service for bulk massive submission of data to various Web forms. The examples of implementation are: search engines URL’s submission forms filling, posting data to employment agencies, any other postings that require routine Web pages visiting and forms filling.
| Target server platform: | Windows 2003 Server, IIS 6.0 and more. |
| Server Framework: | ASP.Net 2.0. |
| Data sources: | SQL server, Access, MySQL, XML files. |
| Data accesses: | ADO.Net, XML parsers. |
HTTP-RAS is a daemon application capable to communicate with Internet servers via widely used HTTP 1.0/1.1 protocol. The service uses any established Internet connection available in operating system. HTTP-RAS is a scenario-driven application. It exposes simple interface to control processing and execution of communication scenarios.
Communication scenario is an exact description of resources (specified by URL), which should be requested, and all named parameters sent with each request. It also contains additional information such as HTTP method to use, HTTP referrer and scenario execution timeout. Communication scenario may include requests for more than one resource. In the latter case resources are requested one after another in the order they specified in the scenario.
Scenario-oriented architecture provides greatest flexibility possible when configuring and using our service. Communication scenarios are encoded in XML format and can be easily created and edited to suit the needs of specific application. It may be especially useful in highly volatile Internet environment, when there is no control over servers you have to rely upon and they tend to change frequently resource location and/or set of parameters needed.
You can start the task on the service using interface exposed by HTTP-RAS. The task includes all communication scenarios provided by service administrator. HTTP-RAS has non-blocking interface, i.e. calling application may proceed further while HTTP-RAS takes care about requesting resources from remote servers. Asynchronous nature of HTTP-RAS interface calls may be crucial when tasks are launched from some script executed on Internet server, as scripts usually have restricted execution timeout. Task execution protocol is saved on disk (if needed). Task execution protocol is saved in XML format and contains information about requests sent, responses retrieved from remote servers and various task status information. Application can also retrieve extended information about status of last tasks executed (or being executed) from the persistent storage maintained by HTTP-RAS.
Being designed for multi-threaded environment, HTTP-RAS can handle several tasks simultaneously. Actually, number of tasks executed simultaneously is restricted by bandwidth of Internet connection.
HTTP-RAS is designed with uncertain nature and vulnerability of Internet communication kept in mind. Typically, you are not even sure, if the remote server is running at all at this moment. HTTP-RAS takes care about possible errors and exceptions during HTTP session with remote server and stops scenario correctly in case of unrecoverable error. Moreover, the service provides reliable mechanism to enforce execution timeout for each request in the scenario. If remote server fails to finish the response in time, connection with the remote server is closed anyway and HTTP-RAS continues processing of the scenario.
