I see the services as a whole being a network model whereas the internals of a service itself could be object-oriented (inheritance, etc.)
--- In [email protected], "Robin" <[EMAIL PROTECTED]> wrote: > > What Gregg has been showing here is really interesting, I am not sure > to interpret it correctly, it looks like service or operation > inheritance. I would do it in Java this way: > > ShoppingService > SellGoods(Goods) > BuyGoods(Goods) > > Goods class > Food class > Hoagies > Meat > Beef > Chicken (well maybe not a good idea at the moment) > Cheese > Swiss > Cheddar > SharpCheddarCheese > MildCheddarCheese > and so forth... > > I think there is a fundamental difference between Object Orientation > and Service Orientation there. The problem is not in the Goods > sub-classes tree, I will use composition or extensions instead of > inheritance in XML but that's not the problem, the problem is in the > ShoppingService design. > > I got this same kind of discussion already with my technical architects. > > When I design an OO API, I will always try to work with abstract types > or interfaces (Goods). That gives me the potential to use polymorphism > and use the same set of operations to manipulate different flavors of > the Goods class. The idea is that I should have no idea of what kind > of object implementation it really is from the moment it fulfills the > interface I will use on top of it (ex: BuyGoods and SellGoods). > > In contrast, a service oriented way of thinking would prohibit the use > of abstract types. The service consumer MUST be aware of the concrete > type returned. All the possible attributes and sub-elements must be > exposed in the service interface, only concrete stuff in there. That > means avoiding <ANY> kind of XML types. If you do that, the service > interface is no more self-describing and well-designed I guess. > > You could design a service that offers a SellGoods operation and would > accept a list of possible types (Sandwiches, Chips,...) OR design a > set of specialized SellXYZ operations. > In both designs, adding a new type like Chocolates (I am Belgian) will > result in a new service interface. In some cases, I may find it to be > more convenient and less disruptive to just add a specific operation > than changing an existing operation. It does not mean I will start > replicating code within the service implementation, of course. > > Am I wrong? > > Robin > http://blogs.ittoolbox.com/eai/applications/ > --- In [email protected], Gregg Wonderly > <gergg@> wrote: > > > > > MonetaryTransaction > > SellSomething > > SellFood > > SellSandwiches > > SellChips > > SellDrinks > > BuySomething > > BuyFood > > BuyHoagies > > BuyMeat > > BuyTurkey > > BuyBeef > > BuyChicken > > BuyCheese > > BuySwissCheese > > BuyCheddarCheese > > BuySharpCheddarCheese > > BuyMildCheddarCheese > > > Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
