>Ultimately I would be willing to bet that your customers want whatever
>you provide them to be integrated with the web. That happens best
>through HTTP. Working back from there, needs may arise that are not
>best met using HTTP. Just don't bet too heavily on any other specific
>solution. Mitigate your short-term costs and protect your long-term
>interests
This is actually very similar to the current direction of the discussion at W3C - i.e. how to improve the connection or interworking of the Web and back office systems.
 
Eric

 
----- Original Message ----
From: patrickdlogan <[EMAIL PROTECTED]>
To: [email protected]
Sent: Thursday, June 29, 2006 2:29:29 PM
Subject: [service-orientated-architecture] Re: SOA Reference Architecture

>> To me we should all just pick a horse and back it,
>> as long as it works well enough.

Aye, there's the rub.

>> WSDL...

Seems simple enough, doesn't it. Except it's not. An interface
definition language is not an architecture. An interface definition
language without good mechanisms in place for evolution may run you
into trouble eventually.

A good architecture specifies what can change and should not
change or is unlikely to change. Be careful where you place your
bets with your architectural decisions.

In Anne's blog reply she writes...

> After you have designed the fundamental requirements of the service,
> then you can expose that functionality using as many middleware
> technologies as you need in order to support your customers'
> requirements. As long as you maintain clean separation of interface
> from implementation, you can do that.

Saying this another way (I think)... one has to plan for systems to
evolve and be replaced. There is no single horse that can be backed
for any length of time.

If there were such a horse I had to bet on today, I'd have to wonder
why it would not be HTTP. It's been around a long time in quite a few
installations.

Ultimately I would be willing to bet that your customers want whatever
you provide them to be integrated with the web. That happens best
through HTTP. Working back from there, needs may arise that are not
best met using HTTP. Just don't bet too heavily on any other specific
solution. Mitigate your short-term costs and protect your long-term
interests.

-Patrick


__._,_.___


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


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to