After having read a few articles on Web service architecture, you are indeed right, it does add a layer of complexity. With that complexity comes significant advantages, such as the UDDI layer. Whereby, in such instance as we are discussing with the Engines, we would have a centralized uddi_engine that would serve as the hub for the discovery of the local web service engines and provide the communication layer between each of the Engines.
For light reading I recommend checking out: http://www.w3.org/DesignIssues/WebServices.html Don't get me wrong, I am not one to choose a more difficult path without understanding the risks involved in doing so. And with something as important as what we are trying to do, whereby having a common thread by which inter-dependant Engines can communicate with each other, and even remote applications, is a very noble goal. It will be a tougher path to take, which I can see why you my be adverse to following. Consider this though. Either we iron out the issues with local Engines that communicate with each other using Ruby alone, or we look at ironing out Engines communicating over a local Web Service infrastructure, there will be problems and complications, but when each are both done. Which will allow is a more flexible approach to growth in the future? Without a doubt, it would be the Web Service architecture. The one and only primary concern I have with utilizing a 100% Web Service architecture is speed. This is something that will need to be seriously considered, but having this as the only road block in my mind is really quite trivial. And something we can optimize when the time presents itself. To quote Tony Hoare, "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.". -Nb ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Nathaniel S. H. Brown http://nshb.net ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > One of the ideas that James and I have been discussing, is > an API for > > each of the engines, allowing each engine to communicate > with another Engine. > > This API, in my opinion, would be absolutely best served > with a local > > Web Service gateway. Which would provide the obvious later > growth into > > having it as a public web service, allowing things such as the > > ferret_engine be able to be searched on by remote or even > local disseparate applications. > > This is definitely the way I want to go as far as engines API are > > concerned. It provides extreme flexibility when it comes to > > communication of functionality. > > > > 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. > > > > My instinctive response is that a webservice is NOT the right > way to do this. > A webservice would be useful for communicating between > multiple machines/processes, or between multiple languages. > We certainly do not have the latter, and while the multiple > process/machines do exist, for the engines I'm aware of, > there's no reason to not simply communicate in ruby using Ruby. > Webservices just make it complicated. > > There might be value in an engine publishing it's API as > webservice, but let's start with a Ruby API. _______________________________________________ engine-users mailing list [email protected] http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
