|[swordfish-dev] Ideas for server adapter implementation|
We are planning to create a deployment feature in Swordfish that uses a WTP server adapter implementation. Essentially, there are two alternatives: implement a new publisher for the generic server adapter or make choice in favor of custom server adapter.
As far as I can see the first alternative is more preferable for simple scenarios, where a module is just published or unpublished from the server runtime and when using of default ant scripting is not enough. Such set of operations (publish/unpublish) is limited by generic publisher interface and it's extension affects the generic server framework.
The development of custom server adapter allows to obtain all advantages, that are absent for generic server adapter, however it's implementation is more complicated and takes more efforts. In turn, an approach with generic server adapter is best suited to J2EE servers and for deployment a module is typically required to put it into the special folder on the server runtime location, by the example of Jboss application server.
Is there the practical realization of generic server adapters for non J2EE servers? What are the dominant conditions, which can allow to say definitely that generic server framework is not preferable? Or that custom server framework is not preferable?
The next approaches follow.
1. Generic Server Adapter (Ant Publisher)
This approach realizes a simple way to publish-oriented tasks. Properly speaking, publisher uses an ant script that takes a module and copies it into the specified physical location on the server runtime.
- limited functionality that based on configuration aspects instead of realization by means of Java API;
- dependency from ant scripting: as the result, publish-oriented tasks are provided by ant scripting, and it cannot implement in full measure even though a special ant task can be developed;
2. Generic Server Adapter (New Publisher)
The generic server adapter allows to implement new publishers as alternative to ant publisher. In this case, the publisher will implement a generic interface (GenericPublisher) that contains two significant operations: publish/unpublish. It can be enough to use this way when only two such operations are required. And the result of these operations is shown in the context of the generic server framework. Introduction of new operations into the interface will affect the generic server API that should interact with this interface to handle more operations. Customization of the generic server API will be expected in this case.
3. Custom Server Adapter
The custom server adapter provides full possibility in implementation of server adapter solutions. However it takes more effort than generic.
What do you think about?
Back to the top