Re: [service-orientated-architecture] Re: What is a "well defined interface"?

Fri, 03 Mar 2006 13:31:43 -0800

You've hit the nail on the head Alex.

Though I've seen my share of badly formed "everything is a string" type interfaces like:

void doIt (in String stuff)    // I saw this at a customer .. actually in eight different interfaces where
     // the only difference was doIt1 doIT2, doIt3 etc. ... or was it runit ???:-) 

or with more specific CORBA type interfaces:

AnySeq dotIt (in AnySeq stuff);   // Where AnySeq was a sequence of Anys
 
The problem with these is that the semantics is lost as to what the business actually is doing. Then you have to look at various implementation code to find out ALL the different things that this interface is. THIS IS BAD!!! Indeed criminal if your a consultant charging money for this (perhaps he's reading now;-). Moreover you've just wasted money on technology (as well as the consultant) - 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 ;-)

On the other hand, as you point out having a specific interface operation for every product in your store is not practical or useful either. Your "2" below is  much more practical interface than "1" - which is too cheesy ;-) Especially considering that it's probably more like:
buyItem (ProductCode) 

Consider Amazon.com. You can be sure that there is not a placeItemTypeInCart for every subcategory of ItemType - i.e. placeNovelBookInCart or placeGardenHoseInCart etc.. Can you imagine the writing of code (or code generation) and maintenance and documentation for such an interface? And 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 I'm sure J2EE. Successful CORBA application implementations were more than likely SOA based (and one could argue even when they were embedded). And this is back to Ron Schmiezer's point which I'll express slightly differently: you can't should not, as much as possible let your implementation influence your SOA. Now sometimes it does because perhaps you're not starting from scratch and you are dealing with production code (aka legacy).

So taking a step back and looking at the big picture - without getting caught up in implementation details:
The only two things that ought to influence your approach to SOA are, in a sense, location, and of course, quality - and I'll say that again: location and quality have influence on your SOA. And I say location because I'm really discussing the impact of infrastrucutre (see below). What I mean by that is that you have to plan for the fact that you might want your service to become popular and therefore your service might become popular. Well designed services will make it easier for your service business to grow as it's reach expands. If your service design limits your ability to scale then your in trouble.

This makes perfect sense when you consider real walk-in-businesses  - location is vital. The infrastructure in and out is vital. If your business isn't accessible then people won't show up. If the store is badly designed and planned then people leave because they can't be serviced. If your store is popular then you might want to scale by opening up another store in another business park or mall with more good infrastructure. etc. (there is a danger in using the term mall because some people will translate that into a hub type architecture - remember the WWW is not a hub and has been a very scalable infrastructure!)

Amazon.com became popular because it was easy and often cheaper to purchase your books on-line through their service. The simple shopping cart made it an easy to use service - a "good service". There us of the www instead of some downloadable rich client with proprietary connection to their business meant that they used a scalable infrastructure. BTW at the start their infrastructure had to be "good" while many stories of the back office implementation would make many of us laugh today (there is as story that, allegedly, in the early days an order just produced a printout on a printer and someone ripped off the printout and then ran off and filled the order into a box - this goes to show how much location/infrastructure and service had a bigger impact over the implementation. The implementation then had to grow to support the demand for the service (the good service) - and they did I guess.

And, of course, if you have great location and infrastructure but have "bad service" then it doesn't matter ... there will be a "going out of business" sale ;-) The customer experience is vital. Bad service will kill you.

So a "good service" is defined by location/infrastructure and how good the service is. 

Perhaps location and infrastructure should be broken out? And of course if your selling product then quality product is an assumption - otherwise who cares?

Is there anything else of missed. Perhaps I should have broken the second part out into a separate discussion rather than under the inheritance subject - though  "well defined" is what made me bring it up.

I may have to blog on this!

Regards to all - Not leaving yet Anne ;-)

William

On Mar 2, 2006, at 4:05 PM, Alexander Johannesen wrote:


On 3/2/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
There are many standard ontological layers that already exist.
Some are part of programming language platforms such as the Java serialization implementation. There's the whole CORBA layer, that's implemented by libraries available for lots of languages. There's SOAP (cleans the crud off of a lot of things they tell me :-).  There' s
lots of choices.

Hmm, are you sure you're referring to ontologies, and not just semantically rich abstraction layers? In ontologies you specify the realtionships between things and what they are far beyond simple structures and inheritance models. 

What features are you finding missing that you think make a generic interface better? 

With this as everything else; it depends. We can go back to the previous example ;

   1. buyFoodCheese() ;

vs.

   2. buyFood ( 'cheese' ) ;
 
With 1, if you're a business that deals in cheese but now wants to offer pork, you need to extend and version that interface. With 2 you replace 'cheese' with 'pork' and in ontolgoy theory, everything should Just Work (TM).

Of course, reality is somewhat different but it gives you the advantage of dealing with the semantics of your 'types' (if you like) in a cleaner way, meaning your interface syntax and semantics don't change when your data semantics does. In some areas this is very valuable, for example in applications that constantly deal with new things; the ontology is governed by an external trusted party. Anne was talking about WS-CDL which seems to be a lever for this.

Are you using a language or platform that requires so much low level detail
manipulation that you have resorted to doing all the work because nothing useful is done for you?

No, but I do work in an area where there are no good business opertunities and hence we have to do this ourselves since no one sees any moneies in it. :) For some general things there are no problems, but in some specific critical areas of our business, we have to come up with pretty specific semantics. I don't want my interfaces to handle those semantics; I want a more general ontology level to deal with the relationships leaving me to worry about the business aspects of it (basically, what we need to do with those relationships).

Maybe you can talk about the specific features of your implemenation which are addressed by other invocation layer implementations?

At this stage I'm not even quite sure of what you're talking about :) but based on my assumption that I do and from what I think you're saying, you already have ontology layers in place with a 80/20 interface? And that would be fine, but I'm not mapping from db to db, I'm already working in a Topic Maps environment where ontologies are a big part of data modelling, and I want to create interfaces that has a separation of data and the semantics.

But hey, maybe what I'm doing is to far from general business reality that it doesn't really apply here. :0)


Alex
--
"Ultimately, all things are known because you want to believe you know."
                                                         - Frank Herbert
__ http://shelter.nu/ __________________________________________________

SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS






SPONSORED LINKS
Computer software Computer aided design software Computer job
Soa Service-oriented architecture

YAHOO! GROUPS LINKS



Reply via email to