Created and maintained by createTank, elemenope is a Service Oriented Architecture and general messaging framework. elemenope may also be considered an application toolkit. elemenope is correctly spelled completely in lowercase, and is pronounced L-M-N-O-P or \"el-em-en-O-'pE\.
History
elemenope has been in active development since 1999. The framework started as a manner in which to simplify the process of integrating legacy systems with new development. elemenope has served as a proving grounds for architectural concepts. elemenope was released as Free and Open Source SoftwareFOSS in 2003. Originally licensed under the GNU General Public License, the Apache License 2.0 was added as an additional licensing option in 2006.
Capabilities
SOA
Simplification of Application Architecture
Separation of Service from Operation implementations
Decoupling of an enterprise's components through standardized communications interfaces
Simplified creation of large scale multi-platform application for messaging or transaction processing
Simplification of the architecture of large enterprise systems through standardization of functional components and message pathways
Simplified tracing of problems and collection of metrics at multiple levels, as every unit of application functionality implements the same interface, and all requests follow a similar path
Designed at a higher level than some other SOA implementations to be transport and protocol agnostic, and to concentrate on providing multiple architectural abstractions
EAI components for integration of mainframe application
Architectural features
Abstraction of transport/protocol connectivity—Abstraction of connectivity issues promotes ability to integrate new software with legacy applications through simplification of connections.
Functional logic abstraction — ability to separate business logic implementation code from the service protocol implementation that calls it.
Transport/protocol abstraction — ability to change service transport protocol in configuration file with no change to business logic implementation code.
Payload abstraction — The ability to send a payload without regard to what protocol might be in use.
Synchrony abstraction—the proposed ability to generically call a Service/Operation without regard to whether the target service is configured as a Synchronous or Asynchronous protocol.
Fault Tolerant Messaging — the ability to transparently failover a call or request from one service transport protocol to another upon failure with no changes to the functional code or business logic implementation.
