Enterprise File Service [EFS]
Rationale
If we look closely at the evolution of Java specially Enterprise java. All
the development is in fact process of decoupling the application code
(Business code) from system code. Write once run any where is the very
first sentence that says java is loosely decoupled with the environment
where it is to be executed. Such development is seen in Persistence (EJB),
Messaging (JMS) and so on.
Enterprise File Service tries to loose the coupling between the
application and the native file system so that both can be developed
independently. Main rationale behind EFS is to decouple the application
and the file system and to add performance, security, transaction and
other features independently.
Need of EFS for performance for example,
Excessive file fetch-write routines decreases the performance of the
application. Applications such as Web servers and Application servers has
to adopt considerable amount of codes to relief itself from the loss of
performance due to slow file processing. Keeping the file in memory or
other other algorithms is coupled with business code. Writing system level
codes along with the business codes is not a good practice.
EFS act as the middle layer pluggable service between the application and
the native file system. Application never have to deal with the files
directly instead can rely upon EFS in return of which they get the above
mentioned features as well.
Working and internals of EFS
Enterprise File system is composed of three distinct layers
1. Client layer.
It is the gateway for the application who wish to use EFS for their
file need. It provides client API that reflect the current file API.
Application developer will have very easy learning curve. Using EFS
client API application coding is straight forward business coding with
minimum emphasis to the system issue of file handling. API in
additional reflects enhancement such as event notification and other
pattern benefits to application.
2. Instrumentation layer
Native file system is represented by this layer. Agents can instrument
anything such as Regular file system, Memory for fast file system or
Database or CVS or FTP. They are normal deployable modules written
with the accordance to the API provided by EFS.
3. Management layer
Management layer is a configurable layer that stands in between the
instrumenting agents and the client. The job of the management layer
is to selects among the agent and provide the configuration service to
the client. Management layer can be accessed through the API provided
by the management layer or through interface defined (such as JMX
console).
Example use cases for EFS
1. Web servers ,Application servers and JSP containers
They can benefit by using high performance EFS (using Memory File
System), Event notification for file changed scenarios loose coupled
security and transaction options.
2. Container deployed enterprise application.
Applications deployed in application servers can use the file system
configured by application servers under the security constrained by
the container provider.
3. Unit testing
EFS can act as the proxy file system or temporary file system for unit
testing.
4. Paging and temporary files
Different graphics application and compiler can use EFS for their high
performance file system usage and temporary scratch files.
5. Proxy file system
Different network resources such as FTP, CVS can be instrumented as
the file system.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
