The disturbing thing about introducing a WS is that for one incoming HTTP request, you will have some arbitrary number of engines making yet another arbitrary number of Web Service requests. Because Web Service request/response pairs are performed over the same transport, you may wind up with a great, great deal of overhead.

My experience with Web Services is that they are great if 1) you can predict how many WS calls you need to make; and 2) you can live with the performance hit. Given that (1) is impossible if engines start talking to one another and (2) will always be an issue, I think Web Services is probably not the most appealing way to enhance engines.


On 3/4/06, Nathaniel S. H. Brown <[EMAIL PROTECTED]> wrote:
For instance, if we create the Engine API using a standardized web service
architecture, future systems such as the authentication_engine would be able
to communicate with other Engines, such as the upcoming Toolbawks Engine, or
Ferret Engine (to make sure they have access to search that content) with a
very simplistic manner. I haven't yet got much experience building Web
Services, but I know enough high-level that this is the way to go, we just
need to make it happen.

-Nb

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nathaniel S. H. Brown                           http://nshb.net
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


_______________________________________________
engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org

Reply via email to