EDABlog

I posted this a year ago.... I'm really against this make each class a separate service concept. It reminds me of the Microkernel and especially workplace OS but worse. The idea of microkernels was each service ( like memory) was an easily managed entity with carefully defined inputs and outputs which could be consumed.) Workplace OS took this to limit and performance was so poor that no amount of optimization would help. So they had no choice but to scrap the project ( were talking $2B 10 years ago) the bad thing is once such a design is made and implemented just like workplace OS it is very difficult and expensive to fix. Classes by nature frequently communicate with other classes ,serializing everything makes this far to slow. Think about big orders with 10,000 line items each line item could be a separate service call to add up some total and what do you gain ? I consider service to service communication and some sort of nearness analysis a vital part of SOA and grouping related classes into services will help significantly by - Increasing performance - Allow for better maintenance and less change as related changes will deploy together . - Allow for better OO/maintenance and Agile techniques within each service. ( though less outside) - Allows better integration and use of different services such as Java , CRM/ERP services etc. - Encourages chunkier cross service calls and better attention paid to the service interface ( for easier use, compatibility/maintenance and performance) - Discourages the service as a DB store proc wrapper. - Avoids having to put performance hacks in the wrong place to try to avoid cross class calls. This does not mean services should be 20 classes 3 is a good line but 1 to 9 is ok in a number of cases depending on class relationships. Basically if 2 classes communicate all the time they should be in the same service. I can see in 5-15 years hosted environments/frameworks hosting classes which can be moved to machines or be in proc though its far too early for this and you NEED the ability for classes to communicate via normal inproc ( without serialization) . I not you mention this for the future but telling people to use each class as a service now without some more comments on the hazzards ( especially when they don't have a lot of experience in SOA) will lead to a lot of frustration for some .