Re: [service-orientated-architecture] Inheritance in SOA?

Thu, 02 Mar 2006 03:03:37 -0800

Okay has anyone else had enough of this? Is this the Jini list or the SOA list?

I've tried to ignore this Java centric stuff, as I know others have too. We do this in the hope not to get drawn into tedious fruitless arguments. I've watched several people try to teach that there are other technologies in the world that we must deal with in SOA and that Java will NOT be acceptable in those environments. Not that Java can't solve the problem but because it's not appropriate. Heck many of us could integrate everything in C, or Perl or even assembly language but we wouldn't because it's not appropriate in many places. Our "teachable" remarks have often been met with ... well more Jini. 

Java is a wonderful language. I've developed in it many times since 1995/96 (recently doing some JBI stuff) Jini may be wonderful - I may never know because I've been put off looking further into it. But many of the rest of us work in large enterprise environments where there is lots of heterogeneity. And we want to integrate natively with that environment in a high performance way. The idea about SOA is that all technologies should be able to participate as first class citizens. We should not have to wrap everything in one technology/language.

To those of you implementing SOA with Jini then maybe the Jini advise is good. I'm certainly no expert in Jini.  There is a Jini group that much of this advice would be more appropriate on: http://groups.yahoo.com/group/jini_javaspaces/. Perhaps this advise is already been posted and maybe ignored there. To those of you implementing SOA in a more heterogeneous environment, be cautious.

If I've offended people I'm sorry but I can't sit back and just ignore this. I was enjoying learning and sharing on this group and then noticed I'd stopped watching it more because I was getting bombarded with Jini and missing the important SOA discussions. 

Gervas if I'm no longer welcome on this group then fair enough.

William


On Mar 1, 2006, at 11:06 AM, Gregg Wonderly wrote:

Spork, Murray wrote:
I would hope that I could just do a Jini lookup using the
interface named BuyCheddarCheese. 

But this way we would have to agree on the names of every single complex
type - whereas the alternative and more decoupled approach is where we
only have to agree on the names of the atomic concepts and on the
operators that we use to compose them. Some refer to "minimal
ontological comittment" to describe this.

I want to buy cheddar cheese.  When I go to the store, there are a bunch of gray 
boxes with no labels that I have open to find out whether I've got the box of 
cheddar cheese right?  And, I also don't have to whack of a bit to chew on and 
hope that I got the cheddar cheese, and not the orange bacterial culture.

Less formal pattern-based approaches really try to achieve the same
thing - i.e. "duck typing".

There are well-known tradeoffs of course.

Duck Typing involves type modification based on type analysis, not the lack of 
typing.

This is an important design issue.  Is it more important that
goods can travel the network or the transaction?

I don't understand this point.

Are we shipping cheese around the network or are we using the network to perform 
a transaction to buy cheese?  It's the transaction that needs to be performed!

Thus, I would choose a service interface named BuyCheddarCheese instead of 
BuyGoods that received a Goods parameter that was CheddarCheese extends Goods.

If I wanted to find the Schwanns food companies service, and ask for inventory 
and look it over to select a product, that's where Goods would be fine.  But in 
my example, I specifically need to find the CheddarCheese.  BuyCheddarCheese 
might just be an implementation of the interface BuyGoods, whose implementation 
is aimed at the system methods for purchasing CheddarCheese.

public interface BuyGoods extends Remote {
public double buy( int quantity )
throws InvalidTransactionException, IOException;
}

public interface BuyCheddarCheese extends BuyGoods {
}

This is an example implementation just to show how the typing can be applied in 
an execution path that is separate from the interface definition.  Thus, this 
interface is very generic, yet it is strongly typed to allow precise matching to 
occur.

public class CheddarCheeseImpl implements BuyCheddarCheese {
private Patron patron;
Vending vend;
public CheddarCheeseImpl( Patron pat, Vending vend ) {
this.patron = pat;
this.vend = vend;
}
public double buy( int quantity ) {
FoodProduct fp = vend.getProduct( FoodProduct.CheddarCheese );
Transaction trans = vend.getTransaction( patron );
Order ord = fp.placeOrder( trans, quantity );
double price = order.getCost( pat );
if( patron.canPay(price) == false )
throw new PriceExceededException(price);
trans.commit();
return price;
}
}

Somehow I have to know who is selling cheddar cheese.  Searching through 
10,000,000 vendors lists of products is insane.  I should be able to through out 
a type based query.

On Google, you don't open a web page and search with your eyes through 
1,000,000,000,000,000,000,000 documents.  You use a "type" based query giving it 
the type of information that you want.  The type mapping system is faulty 
thought, because its not strict.  So, you won't always get what you want, and 
you can't guarantee that every day, the query you ran yesterday will provide the 
same results.

Only through specific typing systems can production software make exacting 
requests and have well formed requirements that can be met.

My observation is that a lot of the friction around strict typing comes from 
people implementing poor type systems and also from them using insufficiently 
rich technologies to allow typing to not be a barrier.

The people implementing really strict typing languages are, from my perspective, 
the people that grew up with the UNIX shell environment in the 70's and 80's and 
learned all about how bad "everying's a string" can be.

Gregg Wonderly







Yahoo! Groups Links

<*> To visit your group on the web, go to:

<*> To unsubscribe from this group, send an email to:

<*> Your use of Yahoo! Groups is subject to:







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

YAHOO! GROUPS LINKS



Reply via email to