Comments inline
________________________________ From: Steve Jones <[email protected]> >To: [email protected] >Sent: Thu, April 8, 2010 2:51:42 PM >Subject: Re: [service-orientated-architecture] You on iPads > > > > > >> Architecturally it is an evolution of client/server. The big difference is >> on the data elements and in interface uniformity. >>> That's a pretty big deal for interoperability. >> Isn't SQL a uniform interface over ODBC/JDBC? >Close. SQL is similar in its generality at the language level, but has flaws >in the supporting infrastructure. It requires much deeper ties to the data >model to understand how to enact proper state changes (e.g. to order a book, I >have to know what table(s) to insert into, vs. in a Web Service, I can call a >method signature, or in a REST interface, I can follow hypermedia that >eventually leads me to a POST/PUT resource where I can order the book if I can >generate the proper representation(s) to transfer). ODBC/JDBC doesn't have the ability to just abstract an arbitrary action via the POST method, for example (though you could probably put a generic stored procedure in there to handle it ;) The network protocols themselves also aren't very uniform or self describing: SQL variants abound, proprietary protocols to the database are the norm & require an implementation library like an ODBC/JDBC driver to handle the interaction, so you're tied to a particular implementation, and thus SOL if the language bindings don't exist for your language, SOL if the drivers aren't compiled for your OS or runtime environment, SOL if your db's SQL variant doesn't support the standard feature you want, etc. In general, network-level protocols tend to be more interoperable than language-level or call-level protocols (see the desire to shift to WS-AtomicTransaction over XA, for example). I could see, for example, OData becoming very useful in this area. > > > > >> Firstly, I don't think dynamic interfaces are rubbish. I'll admit the jury >> is still out. > >> > I think they are rubbish for the mainstream, its one of those "nice" things > like proper concurrency where very very few people can actually handle it. Most concurrency today is handled with toolkits or frameworks that separate the concurrency management from the business logic. I think the same will need to happen in the area of interface resolution to make dynamic interfaces successful. I have some ideas here if I can get to them. > >>> The challenge is conceptual change not technical change. > >> They are reflexive, in that they both influence each other. > > Ummmm I agree that there is some mutual influence but the biggest change is > always in the thinking not in the technology. >This is a longstanding disagreement I think we've had, probably worthy of >beer. The above doesn't make a lot of sense to me. Technology to me is >just "applied thinking", or "applied knowledge". Of course the change is in >the thinking. But often the thinking is unevenly distributed and it takes >technology to catalyze the change in thinking. This can happen the opposite >way too, a change in the business or social perspective changes technology. >> I think one of the troubles is getting the terminology right. I have a >> feeling that what you call client/server is much ?? >>> broader than what I have in mind. I continue to work with and seek >>> extensions to REST because I think the data >>> elements in an architecture have huge impact on scale and interop, more >>> than just the topology of roles of the >>> components themselves (c/s, p2p, etc). The web is a client/server topology >>> with a p2p data >> model. >> I'm not disagreeing on that and I do think that some of the REST elements, >> if properly documented, could deliver some real benefits. >Careful now, we're agreeing ;-) > I got into the Semantic stuff at an IEEE conference in 2002 where people were > chuntering along about semantic matching and > dynamic matching between ontologies (one ontology says "car" another says > "automobile" then some clever maths will > manage to match it about 85% of the time). > >> The semantic web in terms of having explicitly agreed ontologies is a great >> idea and one I use pretty much daily. I just don't > think this really counts as semantics as you are using a limited dictionary > and really just tagging. >Well OK, probabalistic matching has it's place, I mean look at most data >cleansing software in support of MDM, but it's sort of an old hat and only >useful for some use cases. The stuff that really actually works are the explicit ontologies & reusable frameworks that can (in increasing order of learning curve): a) build an *interoperable* vocabulary for a limited dictionary, see SKOS, b) build a web-of-trust authentication mechanism, see FOAF+SSL, or c) query data from a database or across the web, but with the data model itself being independent from the implementation -- see SPARQL, or d) derive basic, simple logical inferences from existing data: inheritance (set-wise), equivalence or disjointedness, domain/range of relationships -- see OWL 2. The point, I believe, is to find way to reduce the amount of neurosurgery required to get people & systems to work together... Cheers Stu __________________________________________________________________ The new Internet Explorer® 8 - Faster, safer, easier. Optimized for Yahoo! Get it Now for Free! at http://downloads.yahoo.com/ca/internetexplorer/
