Just to add some more color (as if light blue wasn't enough). I think
we're all missing (or maybe assuming or glossing over) a key point:
SOA is not the implementation - it's the APPROACH. Another way of
putting it, SOA is not a thing you buy, it's a thing you DO. It's a set
of approaches by which we treat IT assets as Services that can be
composed in loosely coupled ways in order to create applications that
can change. Or at least, that's definition #2,356.
So, can you do SOA with CORBA? You bet,.
Can you do SOA with Jini? Why not!
Can you do SOA with COBOL? Hey - it's been done!
Can you do SOA with PHP? Not only can you, but that's the way that
ZapThink.com works. (well, ok, maybe SOAP over PHP with a smattering of
small, atomic Services)
Can you do SOA with Web Services? Yes... but then again, what do you
use to implement the Web Services? (That was a trick question)
Can you do SOA on a Commodore 64? Well, I'm waiting for that day, but
why not!
What is SOA? It's an architecture oriented towards Services.
(That's just the same as saying SOA, but backwards). So, then what
is a Service? Well, we've had this debate many times before, but
the answers seem to come back that it's not what implements the
Service interface, but rather it is the Service interface and
associated metadata that defines the Service. The implementation of a
Service is just that -- an implementation of a Service. An architecture
oriented towards Services is just that - an architecture.
So, don't get hung up in confusing an implementation of something with
the abstract something. That's why we all get so burned trying to
define SOA. We try to define it by its implementation rather than its
abstraction, and boys and girls (or joims and gents, for those
vaudevillians), it's all about the abstraction. SOA is architecture,
just like n-tier is architecture.
I love the debate in this group - it helps to sharpen the arguments.
You need dissent in order to have a sharp sword to attack the REAL
problem - the lack of understanding by end-users. Despite what may seem
to be antithetical positions here, we're all MUCH closer than you
think. Boy, if I could tell you the number of end-users that can't even
tell the difference between tightly-coupled EAI and loosely-coupled
Services. Hoo-boy.
Well, keep on keepin' on. It's not the destination, it's the journey.
<GetAphorismService>
Best,
Ron
Anne Thomas Manes wrote:
Although Gregg does occasionally get a bit passionate in
his arguments, I, for one, appreciate his comments and the insight into
an alternate approach. (I don't recommend it, mind you, but I always
welcome an opposing viewpoint.)
William -- if allowing Gregg to continue his tirades means you will
leave the group, so be it. I will be sorry to see you go. But I don't
think we should censor Gregg.
Anne
On 3/2/06, Gervas
Douglas <[EMAIL PROTECTED]>
wrote:
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/
__________ NOD32 1.1424 (20060302) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
__________ NOD32 1.1424 (20060302) Information __________
This message was checked by NOD32 antivirus system.
http://www.eset.com
--
_____________________________________________________________
Ronald Schmelzer
[EMAIL PROTECTED]
Senior Analyst
ZapThink LLC
Direct: 781-577-2779 / Main: 781-207-0203
SPONSORED LINKS
YAHOO! GROUPS LINKS
|
