On 9 April 2010 18:20, Stuart Charlton <[email protected]> wrote:
> > > 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). > Ummm but is that the reality? I'd argue that a REST interface has a poor supporting infrastructure around this as well as without decent service documentation then I don't really have a clue about what each element means and what the structure of the return elements mean. There is no Mime type for order book so you have to work it out yourself. At least with SQL there would be a published data model. Theoretically I agree with you I just think that practically this isn't the reality. > > 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. > I'm not a big fan of SQL, I was just making the point that traditional client/server applications that exist across enterprises today are architecturally pretty similar to the limited client/server models over HTTP on the iPhone. Sure SQL has limits and Stored Procedures are the Pat Robertson of technology but you can see the lack of real evolution that has happened. > 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. > Don't get me started on WS-TX.... I think that _anything_ would be useful in this area to help formally describe the REST-* world that just doesn't exist. I've seen lots of problems that would be appropriate for a REST approach (Data navigation problems in the enterprise, MDM, etc) but without having formal ways of describing the interfaces and models its just a non-starter from a long term viability perspective. I can't design systems that require only the very best to use because the very best don't work in AM. > > > > > >> 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. > I agree completely, I actually did some Java stuff on this in around 2000 using fixed interfaces and dynamic proxies. Time as ever is the problem. > > > >>> 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. > Take OO as an example. I worked in Eiffel, I thought in OO, it was a completely natural way for me to work. I worked in Ada and C after that but always thought in OO terms and my code matched that despite the languages not being OO. I then worked with some folks who were using C++ but in reality just coding in C with a different C pre-processor. The technology wasn't worth a damn in getting them to shift to OO it was about changing the mindset. Its the same with everything in IT IMO. New technologies come along and they succeed or fail based on whether they change a mindset. Ada, Eiffel and other languages which (IMO) are massively superior as languages from a development and support perspective, but the developer mindset was that terse languages were "efficient" and that actually the number of characters you typed was in some how related to actual productivity. That mindset hasn't changed and even the DoD with their research, money and technology couldn't change it. > > >> 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 ;-) > Don't worry if you like WS-TX we'll find something else to argue on. My piece on REST has pretty much always been that it isn't a step forward until it can beat WS-* from a documentation and automation perspective. > > > 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. > And requires massive amounts of people to make it work. MDM matching is a great example as its always the probable-matches that take the effort > > 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... > I agree with all of this. What I'd like to see is people progressing this stuff more formally via the likes of OMG and OASIS rather than having lots of home baked competing stuff and no real long term philosophy or ambition. > > Cheers > Stu > No Worries Steve > > ------------------------------ > Looking for the perfect gift?* Give the gift of > Flickr!*<http://www.flickr.com/gift/> > > >
