Thoughts on Interoperability and Web Services...
A fellow architect asked me to provide some thoughts on the meaning of INTEROPERABILITY and the significance to Enterprise Architecture.
It's easy to avoid the religious debate between the .NET and JAVA communities by touting terminology like INTEROPERABILITY . Its time to resurrect (and please help me amplify) concern on this topic...
I have seen posts here and here and here that discuss INTEGRATION and INTEROPERABILITY. Static interfaces evolved to loosely coupled integration and that's nice and all...but what about exposing .NET services to JAVA based consumers? and let's not forget JAVA based services for those MS consumers...
How we go about designing Web Services is critical. Development teams need to understand the differences in data serialization and as well as have and understanding of XML namespaces and the realities of WSDL:IMPORT. We all need to push INTEROPERABILITY and DOCUMENT bases Web Services as a primary design pattern. We all need to push for establishing the "contract" first in our projects. The WS-I Basic Profile helps but when at least 5 types of Web Services are possible how do you choose? Document Literal-Wrapped is my favorite...but do not expect SOAP with Attachments without SAAJ and MTOM or other meta-transformations...What about good ole' REST?
-->The first truth behind INTEROPERABILITY is that it requires more work
-->The second truth is that it is not easy to exhaustively test for
-->The third truth is that it does not solve for cross-platform or cross-protocol without additional infrastructure
Folks comfortable with tools such as WSDL4J, JAX-RPC and the equivalents in WSDL.EXE can generate their startup classes very quickly...but not so quick for the resulting service to be INTEROPERABLE. Some folks tout additional tools such as SOAPscope or SOA Editor (what a bad name) or StylusStudio or WSDL Editor or Visual Studio or Eclipse plugins or oXygen or others...
My problem is there is not one tool that does the job great...one is good graphically, one is better a testing, one is better at validating syntax, blah blah blah...I'll just write it myself in Notepad.
Can folks please COMMENT and help the 'Bloggernet':
1) amplify this dirty little secret
2) understand your choice in tools
3) learn some of your tips
The knowledge crisis continues...
posted by JT at 2:06 PM
5 Comments:
Beware that someone may consider you to be too enterprise since you didnt acknowledge dynamic langs like Ruby...
Everyone has a right to their opinions.
I would not distract my intended audience with a dynamic language debate...I just want people to start discussing about the realities of interoperability and proven answers.
"We can't solve problems by using the same kind of thinking we used when we created them." A. Einstein
I've wanted to talk about this for a while now. In this posting, the author talks about how interoperability is beyond most tooling. He mentions that using wsdl.exe or wsdl2java with wild abandon is a reckless exercise that will hurt. And he's right...
controlledAgility...
(Nice handle BTW)
Thanks for commenting and helping amplify this msg.
Will add you to my roll.
Cheers!
This is why I tout the need that Enterprise Architects and Integration Architects need to have and continue to maintain a lot of hands on skills. You are exactly right about the tools and you would not know that if you had not used them.
WSDL first design is a good point. I tend to think that helps a great deal with these issues. Especially if an organization is not mature with their current understanding of Web Services, the standards and the Interoperability issues(and how could they be, they seem to change daily). Auto WSDL generators tend to more often than not introduce the issues.
Don't you think this will continue to be an issue especially when you talk about third party applications that "have web services support". The interpretation of the standards is left up to the developers/implementers and that will probably vary for some time.
Post a Comment
<< Home