Jan - It's always important when discussing SOA to separate the design principles and best practices from the various technology options for implementing them.
As we hear a lot on this list, for example, it's possible to implement an SOA using Java alone. And if that's the implementation choice you may not need loose coupling at all. The extent to which an SOA is coupled is an orthogonal question to whether it's an SOA or not. I believe behind this seemingly endless debate over custom vs. standard APIs is the age old discussion about how much information you pack in with the data, and how much information you place outside the data - using an interface, a description language, schema associated with the data, action header, etc. The reason we probably can't ever get to the bottom of this debate is that solutions to IT problems are possible using either approach, or in fact both approaches. If you think about old file transfer systems from the earliest days of computing, we would put everything into the data that the programs processing it would need because that was all we had to exchange - and sometimes only on sequential tape, punched cards, etc. Today we can think about using very simple asynchronous message queueing systems for all distributed communications - distributed computing having the goal of sharing data across computers somehow. The question about which method is optimal cannot be answered in the abstract so the debate continues without end. Anyway in the case of using message queueing for everything, you put into the message all the information the destination system needs to process it. Including a method name and method signature if what you want to do is invoke an object. If you just want to transform to SQL or something then you can do that instead and you don't need a method name or input/output argument definitions. To me this is a form of standard interfaces that has been around along time, although the API for it wasn't really standardized until JMS came along (and even then that's an API only for the Java "half" of the world). File systems such as relative record, sequential, and indexed sequential have had more or less standard interfaces for a long time, too. Anyway, the point is that for me the issue is how much help to provide the programs processing the data. If you are just dumping HTML or XML into a browser then the browser knows what to do and the system works great. However if you are dumping XML into a Java or COBOL program, especially an existing program in a legacy application (legacy being basically anything in production that works), the program is going to need some help understand what to do. Custom interfaces can help - it isn't the only thing, but it is something that developers understand. Eric --- Jan Algermissen <[EMAIL PROTECTED]> wrote: > Ron, > > On Feb 26, 2006, at 2:01 PM, Ron Schmelzer wrote: > > > A theoretical exercise in a grand-unified-theory > of Services serves > > very few end-user companies in practicality. > > An essential aspect of SOA is to achieve looser > coupling - right? > This is significant since looser coupling is likely > to cut down > development and development coordination cost, which > makes loose > coupling interesting from a business perspective. > > Some people here (including me) argue that there > exists a means to > achieve even looser coupling than with what current > SOA proponents > suggest. Does that not qualify as a practical issue? > > Or do you suggest that coupling beyond SOA is > *impossible* and > therefore the discussion must be impractical?? > > Jan > > > ________________________________________________________________________ > > _______________ > Jan Algermissen, Consultant & Programmer > > http://jalgermissen.com > Tugboat Consulting, 'Applying Web technology to > enterprise IT' > http://www.tugboat.de > > > > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com 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/
