Who needs an SOA, then? Just build ONE Service and be done with it. But I think we're devolving into a point here that very few companies would find useful to implement. We're not looking for a single Service we can reuse, but a collection of the *right* Services that can be used to solve ongoing IT problems.

This requires some level of coupling to make it usable. A theoretical exercise in a grand-unified-theory of Services serves very few end-user companies in practicality.

Ron

Gregg Wonderly wrote:
Ron Schmelzer wrote:
> Wow -- very insightful response. That's quite correct. In general,
> that's why we only have a certain amount of looseness in coupling.
> You're always coupled at SOME level, and in this case, we have semantic
> tight coupling, even though we might have delivery loose coupling. So,
> can you ever truly be "decoupled"? Probably not.

public interface DoesItAllNoMatterWhatYouWant extends Remote {
      public Object doItAllAsFastAsYouCan( Object val ) throws Throwable;
}

There it is, the interface that does everything.

Now, will it actually be useful?  Looks to me like a REST service interface.

Gregg Wonderly




__________ NOD32 1.1418 (20060224) Information __________

This message was checked by NOD32 antivirus system.
http://www.eset.com


__________ NOD32 1.1418 (20060224) 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
Computer software Computer aided design software Computer job
Soa Service-oriented architecture


YAHOO! GROUPS LINKS




Reply via email to