Automatic system for customizable web form completing
Web Form Submission is an automated service for bulk massive submission of data to various Web forms. Examples of implementation are search engine URL submission forms filling, posting data to employment agencies, and any other postings that require routine Web page visiting and form filling.
HTTP-RAS is a daemon application capable of communicating with Internet servers via the widely used HTTP 1.0/1.1 protocol. The service uses any established Internet connection available in the operating system. HTTP-RAS is a scenario-driven application. It exposes a simple interface to control the processing and execution of communication scenarios.
The 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 the HTTP method to use, HTTP referrer and scenario execution timeout. Communication scenarios 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.
The scenario-oriented architecture provides the 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 a specific application. It may be especially useful in highly volatile Internet environments when there is no control over servers you have to rely upon, and they tend to frequently change resource location and/or set of parameters needed.
You can start the task on the service using the interface exposed by HTTP-RAS. The task includes all communication scenarios provided by the service administrator. HTTP-RAS has a non-blocking interface, i.e. calling applications may proceed further while HTTP-RAS takes care of requesting resources from remote servers. The asynchronous nature of HTTP-RAS interface calls may be crucial when tasks are launched from some script executed on an 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. The application can also retrieve extended information about the status of the last tasks executed (or being executed) from the persistent storage maintained by HTTP-RAS.
Being designed for the multi-threaded environment, HTTP-RAS can handle several tasks simultaneously. Actually, the number of tasks executed simultaneously is restricted by the bandwidth of the Internet connection.
HTTP-RAS is designed with the 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 of possible errors and exceptions during HTTP sessions with the remote server and stops scenarios correctly in case of unrecoverable errors. Moreover, the service provides a reliable mechanism to enforce execution timeout for each request in the scenario. If the remote server fails to finish the response in time, the connection with the remote server is closed anyway, and HTTP-RAS continues processing the scenario.
See similar projects on our blog.
