Transport/protocol abstraction
This article may meet Wikipedia's criteria for speedy deletion as a copyright infringement(Copyvios report) of http://elemenope.org/doc/userguide/userguide-1.0.pdf (Copyvios report). This criterion applies only in unequivocal cases, where there is no free-content material on the page worth saving and no later edits requiring attribution – for more complicated situations, see Wikipedia:Copyright violations. See CSD G12.
If this article does not meet the criteria for speedy deletion, or you intend to fix it, please remove this notice, but do not remove this notice from pages that you have created yourself. If you created this page and you disagree with the given reason for deletion, you can click the button below and leave a message explaining why you believe it should not be deleted. You can also visit the talk page to check if you have received a response to your message. Note that this article may be deleted at any time if it unquestionably meets the speedy deletion criteria, or if an explanation posted to the talk page is found to be insufficient.
Note to administrators: this article has content on its talk page which should be checked before deletion. Note to administrators: If declining the request due to not meeting the criteria please consider whether there are still copyright problems with the page and if so, see these instructions for cleanup, or list it at Wikipedia:Copyright problems. Please be sure that the source of the alleged copyright violation is not itself a Wikipedia mirror. Also, ensure the submitter of this page has been notified about our copyright policy.Administrators: check links, talk, history (last), and logs before deletion. Consider checking Google. This page was last edited by Butseriouslyfolks (contribs | logs) at 03:27, 29 May 2007 (UTC) (17 years ago) |
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 connectivity interfaces within for all service transport protocol implementations.
This architectural abstraction offers great benefit to architects and developers, as it lowers risk involved with regard to technologies and service protocols deployed. An organization may determine at a later date that a different protocol is required. This may then be changed at runtime via a configuration file.
The originally deployed service transport protocol might also be augmented with another service implementation in a differing protocol, configured to offer the same business logic implementations or a subset thereof.
This architectural abstraction also allows alternative environments (e.g. development, testing, etc.) to simplify deployment configuration without change to the business logic implementation code.
Source
elemenope User Guide