Tom Nolle is the chief strategist for ExperiaSphere, an open source Java project aimed at creating service logic and management abstractions, as well as CEO of CIMI Corporation, a private consulting firm that specializes in advanced computer and telecommunications technology. Nolle has over 30 years of experience as a private consultant and is a prolific writer and blogger on all things IT. His recent experiences with the ExperiaSphere project have leant Nolle an in-depth understanding of the pain points application architects face when working with Web services.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
In this three-part interview, Tom Nolle discusses where SOA came from, where it stands today and where it's going tomorrow. Here in Part one: Web service standards and requirements, Nolle discusses requirements and standards and how they play into application development for new technologies like mobile devices. In Part two, Nolle covers the impact of Mobile on REST, by explaining more about the effect that mobile devices are having on the realm of RESTful Web services. Part three covers the future of SOA. Nolle introduces the "chubby client", which has emerged as an alternative to the traditional thin client versus thick client paradigm.
SearchSOA.com: SOA has benefits but some implementations incur overhead. Has SOA's overhead at times caused a performance hurdle? Does that relate to ESBs – which are mainly about messaging – and messaging architectures as well?
As you move into an iPad dominated mind set where you're thinking about applications' interactions with a thin client. The notion now is about substituting back-end planning for front-end planning.
Tom Nolle, chief strategist at ExperiaSphere,
Tom Nolle: First it is worth considering the nature of functional and structural requirements. The functional requirements are the relationship between the application and the business case -- the structural requirements are the relationship between the application and the IT infrastructure. Now, IT practitioners are notorious for the last 50 years of understanding and focusing a bit more on the structural than on the functional because it is an area that is entirely under their control.
The recent trends in application development and what you would call the application architect principle that has kind of crept into programming tend to exacerbate that segregation.
I don't think that it is necessarily true that Corba or service buses are a bad thing. I don't think componentization with flexibility is an immediate problem for application performance. However, I do think that what has happened is we have developed a lot of application principles without any specific concern for functional behavior.
When you do that, whatever it is you are working on, it is likely to end up getting you into trouble.
SearchSOA.com: How will newer notions play out in new areas, for example in mobile devices?
Tom Nolle: Well if you look at SOA as it was first conceptualized, it came along in very large part to support the connection of Web-driven desktop worker mashup processes with central IT processes. You had a distinct front-end/back-end distribution of the workflow.
The back-end things had to be very secure because the front-end things were inherently insecure and so the coupling between the two was seen to be a place where you could introduce a lot of risk in a security and identity sense. So we ended up setting up very robust standards for that type of process – that is where the original WS stuff really developed.
Now, as you move into a iPhone or iPad dominated mind set where you're thinking about applications in terms of how they interact with a thin client. The notion now is about substituting back-end planning for front-end planning, meaning looking at how the application projects out over the Internet. So I am now more inclined to make my application security a function of communications security.
Also at this point because I am now dealing with devices that are much simpler, I am much less tolerant of heavyweight standards like the WS standards [WS-*]. They are heavyweight and they are harder to implement on thin clients, and I am also dealing with an ever-expanding, uncontrollable client universe. And it gets harder in that universe to impose WS rigor on all of the transactions because I don't even know if any of the WS standards are supported on the device.
We've always had the front-end and the back-end. The back-end parts of the processes were a focus of early melding of applications to a Web front-end. But as applications became themselves more componentized and as we focused more on the relationship between appliances and the application and less on the back-end to Web server focus, what we ended up with was a shift toward a Web-oriented world, one that has always leaned toward a RESTful architecture.