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:
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/
