name = elemenope
caption = elemenope
latest_release_version = 5.1
latest_release_date = August, 2006
SOA Service-oriented architecture* Software framework
license = Apache 2.0 License and
website = [http://elemenope.org elemenope.org]
Created and maintained by
createTank, elemenope is a Service Oriented Architecture [SOA] 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.
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 Software
FOSSin 2003. Originally licensed under the GNUGeneral Public License GPL, the Apache License 2.0 was added as an additional licensing option in 2006.
*Simplification of Application Architecture
*Separation of Service from Operation (functional) implementations
*Decoupling of an enterprise’s components through standardized communications interfaces.
*Platform for simplified software development on top of an extremely advanced architectural environment.
*Fully developed application toolkit
*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.
*Architected at a much higher level than most other SOA implementations to be transport and protocol agnostic, and to concentrate on providing multiple architectural abstractions.
*EAI components for integration of mainframe application.
Abstraction of transport/protocol connectivity—Abstraction of connectivity issues promotes ability to integrate new software with legacy applications through simplification of connections.
Functional logic (business logic) abstraction— ability to separate business logic implementation code from the service protocol implementation which is calling 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 (the object sent to the Operation) 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.
upported open standards
*Java Message Service [JMS]
*SOAP Web Services (SOAP over HTTP)
*XML-RPC Web Services
*Native IBM MQSeries (WebSphereMQ)
*Built-in mainframe connectivity classes for use when connecting to a mainframe running IBM MQSeries with the IMS Adapter or IMS Bridge
Goals of elemenope
*Abstraction of connectivity within an enterprise application
*Ease incorporation of detailed knowledge from subject matter experts
*Implementation of multiple transports
*Transport agnostic business logic implementation
*Ability to configure and reconfigure service transport protocol and services
*Simplification of Enterprise Application Architecture
*Powerful and extensible SOA through separation of Service from Operation
oftware Library Utilizations
* [http://elemenope.org/ elemenope home page]
* [http://elemenope.org/doc/userguide/userguide-1.1.pdf elemenope User Guide]
* [http://elemenope.org/content/view/10/37/ elemenope FAQ]
Wikimedia Foundation. 2010.
Look at other dictionaries:
Payload abstraction — is the ability to send a payload (the document or request object sent to a Service) without regard to what protocol might be configured.This architectural abstraction is made necessary due to Transport/protocol abstraction, which is the… … Wikipedia
Fault Tolerant Messaging — or Failover Abstraction is 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. In elemenope, this ability… … Wikipedia
Abstraction of transport/protocol connectivity — is the ability to connect to various components or services through multiple protocols without code change or addition, via change to a standard configuration file. Connectivity abstraction may be achieved through a service transport protocol… … Wikipedia
Functional logic (business logic) abstraction — Functional Abstraction (or Business Logic Abstraction) is the ability to separate business logic implementation code from the service protocol implementation which is calling it. This architectural abstraction allows the user to implement the… … Wikipedia
Transport/protocol abstraction — Transport Abstraction is the ability to change service transport protocol implementations in a configuration file with no change to business logic implementation code.Transport abstraction may be achieved through the use of standardized… … Wikipedia
Synchrony abstraction — Abstraction of Synchrony is the proposed ability to generically call a Service/Operation without regard to whether the target service is configured as a Synchronous or Asynchronous protocol. The user may then call all services and expect a reply… … Wikipedia
Charles Bernstein — For the composer, see Charles Bernstein (composer). Charles Bernstein at Writers and Literary Translators International Conference (Stockholm, June 30, 2008) Charles Bernstein (born April 4, 1950) is an American poet, theorist, editor, and… … Wikipedia