Difference between revisions of "Apertium going SOA"

From Apertium
Jump to navigation Jump to search
(New page: The aim of this project is to design and implement a Client-Server architecture for Apertium. Actually, to translate many documents, many Apertium processes are created and each one of the...)
 
Line 1: Line 1:
  +
[[Image:ApertiumServerComponentDiagram.png|thumb|right|X.]]
  +
[[Image:ApertiumServerInternals.png|thumb|right|X.]]
  +
[[Image:ApertiumServerSequenceDiagram.png|thumb|right|X.]]
  +
[[Image:ApertiumServerUseCase.png|thumb|right|X.]]
  +
 
The aim of this project is to design and implement a Client-Server architecture for Apertium. Actually, to translate many documents, many Apertium processes are created and each one of them loads transducers, grammars etc. from scratch, causing a waste of resources and, so, a reduction of scalability. To solve this problem, a solution is to implement an Apertium Server (or Daemon) that doesn't need to reload all the resources for every translation task. In addition, this kind of service would be able to handle multiple request at the same time (useful, for example, in a Web 2.0-oriented enviroment), would improve scalability, and could be easily included into existing business processes in an existing IT infrastructure with the minimum effort.
 
The aim of this project is to design and implement a Client-Server architecture for Apertium. Actually, to translate many documents, many Apertium processes are created and each one of them loads transducers, grammars etc. from scratch, causing a waste of resources and, so, a reduction of scalability. To solve this problem, a solution is to implement an Apertium Server (or Daemon) that doesn't need to reload all the resources for every translation task. In addition, this kind of service would be able to handle multiple request at the same time (useful, for example, in a Web 2.0-oriented enviroment), would improve scalability, and could be easily included into existing business processes in an existing IT infrastructure with the minimum effort.

Revision as of 03:09, 22 April 2009

X.
X.
X.
X.

The aim of this project is to design and implement a Client-Server architecture for Apertium. Actually, to translate many documents, many Apertium processes are created and each one of them loads transducers, grammars etc. from scratch, causing a waste of resources and, so, a reduction of scalability. To solve this problem, a solution is to implement an Apertium Server (or Daemon) that doesn't need to reload all the resources for every translation task. In addition, this kind of service would be able to handle multiple request at the same time (useful, for example, in a Web 2.0-oriented enviroment), would improve scalability, and could be easily included into existing business processes in an existing IT infrastructure with the minimum effort.