Understanding Web Services and SOA
Web Services and Service Oriented Architectures are two of the coolest words in technology today. However not many of us know much about what these technologies really have to offer.
In this interview, we speak to Sameer Tyagi who is an Enterprise Architect with Sun’s Client Services Group and has several books to his name. Sameer speaks about SOA and Web Services and their relevance to the kind of Java development happening today.
IndicThreads >> Hi Sameer. Welcome to IndicThreads. Could you introduce yourself to IndicThreads members?
Sameer Tyagi >>I work as an Enterprise Architect with Sun’s Client Services Group. What that means is that we work directly with customers helping them architect, design and build out large scale enterprise applications based on Java technology.
I have also authored some books in this area and also write for different periodicals (more at http://blogs.sun.com/sameert)
IndicThreads >>Thanks. There has been so much hype around Web Services for the past few years that it has become quite difficult to figure out what it really is capable of. Where do you think lies the real appeal and use of web services?Â
Sameer Tyagi >>Web Services is a great technology. Web Services enable transparent application to application integration across disparate technology platforms.Â
They enable new channels for business services and lower barriers for business collaboration by providing a means to build loosely coupled services using standards driven technologies.
In particular the combination of Java and XML is appealing because Java offers portability of applications and XML on the other hand offers portability of data. When combined though standards like J2EE they offer an integrated platform for real world enterprise application development.
“Web Services enable transparent
application to application integration
across disparate technology platforms“
IndicThreads >>In which cases do you think it is wise to avoid web services and go for a more traditional approach?
Sameer Tyagi >>Architectures that require real time responses or highly predictive performance, applications that don’t necessarily need to interoperate across platforms, and inter-tier communication in the same application – all don’t necessarily make good candidates for Web ServicesÂ
IndicThreads >>The J2EE 1.4 platform provides various APIs for web services. Could you tell us a little more about these APIs and their features?
The major theme for J2EE 1.4 is Web Services. You have a core set API within J2EE 1.4 that facilitates this. JAX-RPC, JAXP, JAXR, EJB 2.1, JSR 109 and SAAJ are some of them (see http://java.sun.com/j2ee for more details). There are many other JSRs (e.g. JSR 104, JSR 105, JSR 109 etc) that are being developed though the JCP.
IndicThreads >>The latest buzzword in the industry seems to be SOA. At JavaOne this year it almost seemed like there was an unwritten rule that every keynote speaker must use the word SOA at least 50 times. I am not sure how many in the audience actually got what SOA is all about. Can you shed some light on SOA?
“Service oriented design
is really a perspective on how
developers understand and
build out application functionality.“
Sameer Tyagi >>SOA is an architectural style, a philosophy and paradigm for building distributed applications. Web Services is an implementation of SOA with a particular technology. Also while SOA is a new term, the notion of services is not. Service oriented design is really a perspective on how developers understand and build out application functionality. Developers should look for more on this at the J2EE Blueprints Catalog (https://bpcatalog.dev.java.net/)
IndicThreads >>So when should one look at having a SOA based application? Is it ready for use now or is it better to wait for tools and technologies to mature around the SOA concept?
Sameer Tyagi >>SOA is real today. Like I said, the base set of technologies and API are there today. The vertical ones (like transactions, federation etc) are still evolving. The good thing about all this hype for developers is that vendors are motivated to provide the enabling tools and are consciously building out the necessary support in their various product lines. The key thing is to keep in mind is sticking to standards that everyone agrees upon (e.g. WS-I profiles). Going beyond that can compromise interoperability.
“SOA is real today“
IndicThreads >>Is web services integral to SOA or can I have a SOA based application that does not use web services?
Sameer Tyagi >>Web Services is an implementation of SOA. You could build out SOA style applications using other technologies. In fact RMI, CORBA JINI etc are all technologies base don the publish-find-bind technique. SOA by itself isn’t a new concept. Whats new about SOA through Web Services is the portability of the data, the ubiquity of the transports and the emerging consensus on the standards.
“Whats new about SOA through Web Services is the
portability of the data, the ubiquity of the transports
and the emerging consensus on the standards“
IndicThreads >> I am sure that would have helped readers get a better understanding of the coolest terms in Java today, web services and SOA. Anything else you would like to share with J2EE users and enthusiasts from India?
Sameer Tyagi >>They should definitely try out the Java WSDP and J2EE 1.4 SI if they haven’t already. Some of the projects on java.net also contain a lot of good material and forums to discuss the different APIs. If you’re building document oriented applications then you should also look at this article on JAX-RPC Patterns and Strategies (http://java.sun.com/developer/technicalArticles/xml/jaxrpcpatterns/)
IndicThreads >>Thanks for sharing your views on IndicThreads. I wish you all the best in your endeavors.
Sameer Tyagi >>It was great talking to you too. I can be contacted at [email protected]
I’m reading a lot about SOA and it sounds good. Loosely coupled services that you can call to get work done; services calling services. I wonder about the applications. I’m seeing large groups of legacy applications moving into the relm of permanent infrastructure because developers are focused on writing cool SOA code rather than focus on improving the underlying application. If we think about service delivery through technology, SOA enabled or not, as a value chain it is only as good as the weakest link. Is the plan to re-write legacy applications as incremental SOA enabled services? Or just wrap them and hope they never fail?
:p :sigh [URL=http://abc]abc[/URL][B]abc[/B][LIST][*]null
The question is how to leverage SOA in the mid market entreprise where the applications that we currently deployed do not support SOA.
Folks, SOA is about significant steps forward in moving towards the BUSINESS of IT. IT as we knew it goes the way of all dinosaurs, slowly but surely. This is because very view of even the best developers engage actively with the IT as a business. Those areas that do not want to engage or believe they don’t have to, will slowly disappear: Funding will be the issue. SOA starts IT developments from the business end, eventually coming up with ways to provide synergistic solutions between what the business really needs and the best ways IT can provide it. Well understood Knowledge Management is the key.
In 1993 we implemented a (basic) 3-tier system with Tuxedo as the middle layer. From what I have seen, read and heard, SOA is an evolution of this. We’ve gone from objects to components, now to services, which can be exposed as a number of message types in a system. 3 tier has become n-tier, and the middle layer has become more robust and evolved.Not sure I can see a lot of businesses changing to this paradigm if they’re implemented business changes.
I noticed some of the comments here seem to question the validity of SOA or more broadly service-orientation. At our site we adopted an SOA (based on the Gartner Research of the time) in 1997. We have (as Sameer says) implemented it using tighly coupled approaches for linking our service in cases where performance is critical, but we always use Web Services outsaide the boundary of our Enterprise. The issue in implementation seems not to me to be the technology (Java, .NET whatever), but actually being able to identify services that are of any true value. Once you have these you have an SOA worth implementing.
I guess in terms of architecture, SOA is a fresh call raised on being truely generic and simple (character-set level) in approach re. interoperability. SOA is about loose-coupling, while the object-oriented approaches (incl glue stuff like COM and CORBA) has been founded on notions of tight-coupling. I believe what is emerging as most practical is to hide object orientation deeper into the core while wrapping it up with SOA shells for one and all to interface with.
In short folks, it is a bit of a deconstruction of the object-oriented paradigm. Hey, it’s only natural to evolve …..
who is using them
I hope the SOA fad dies out soon and I don’t have to actually study something that seems very vague and blown up from where I am sitting.
Even though Web Services had some obvious advantages, it wasn’t adopted as quickly and widely as expected, So will SOA be adopted by developers worldwide??