I look forward to the day when military staff colleges refer to the debates in this Group when looking for instruction and inspiration.
Gervas --- In [email protected], William Henry <[EMAIL PROTECTED]> wrote: > > 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 > > > > > > > > > > > > > > > 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/
