Though I've seen my share of badly formed "everything is a string" type interfaces like:
String runIt (in String stuff); // I saw this in someones IDL once :-(
or with more specific CORBA types in the interface:
AnySeq dotIt (in AnySeq stuff); // Where AnySeq was a sequence of CORBA Anys
The problem with these is that the semantics are lost as to what the
business actually is doing. Then you have to look at various pieces of
implementation code to find out ALL the different things that this
interface is. THIS IS BAD!!! Moreover you've just wasted money on
technology - in this example CORBA. Why? Because now you have to
essentially do all the marshaling of data in and out of the strings or
Anys. Something that CORBA was designed to solve for you by giving you
the type mappings. (Anys had their place ... allegedly ;-) Similarly if
your Web service merely had a String parameter instead of some XML
structure or data types you couldn't take advantage of all the
marshaling capabilities of modern Web service enabling technology.
Some
advocate a much more granular interface operation. E.g. having a
specific interface operation for every product in your store! But this
is neither practical or useful.
void buyItem (ProductCode, Quantity);
is much more sensible than:
void buyCheese( Quantity ); // I've seen something similar suggested
Consider an on-line retailer. You can be sure that there is not a placeItemTypeInCart for every subcategory of ItemType - i.e. placeNovelBookInCart or placeGardenHoseInCart etc. It would be completely impractical writing code (even generating code), maintaining code and documenting such an interface. Every time a business partner brings more products to your "store" you need to write more code.
This is the problem with taking some of the OO type concepts into the SOA world. We saw this and the earlier everything-is-a-string type approaches in CORBA and other technologies. Successful CORBA based application implementations are more than likely SOA based. You cannot and should not, as much as possible, let your implementation influence your SOA design. Now sometimes it does because perhaps you're not starting from scratch and you are dealing with production code (aka legacy). Extra layers of abstraction might be required to make a legacy application more service oriented.
IP Babble is the personal blog of William Henry.
Leave a comment