A Web Services Journey
by Jim Alateras
They want to be able to gather information and understand the scalability, maintainability, performance, evolution aspects of this product and how it applies to architectural and design decisions. It is a journey that will primarily cover the technical aspects of web services, but will occasionally look at the business side of the ledger.
The web services market covers quite a bit of territory and overlaps other market segments. Some of the technologies, standards or ideas we have already encountered include
WSDL - Web Services Description Language
SOAP - Simple Object Access Protocol
REST - REpresentational State Transfer
BPML - Business Process Modeling Language
BPEL - Business Process Execution Language
BPMN - Business Process Modeling Notation
UDDI - Universal Discovery Directory Interface
SOA - Service Oriented Architecture
POA - Process Oriented Architecture
WSCL - Web Services Choreography Language
WS-* - A whole lot of specifications that relate to the web services stack
Fortunately, we have been playing in this space for sometime and have experience with most of these technologies. The difference with this project is that we need to a deeper understanding of these technologies, which entails reading the specifications or the concepts or looking at the API again and again.
During my 20 years in the software space I have come up with some important observations, which I call What I Now Know (WINK) :-).
Read a specifications multiple times (i.e. 3-4) before developing or using it. The later reading will provide stronger foundations for any work ahead and will minimize rework.
Companies like Amazon, eBay and Google have already released Web Services, which support both WSDL/SOAP and REST style interfaces. These web services are used extensively, so we know they work. Are they designed using best practices? Are the abstractions adequate? What are the architectural constraints? What are the scalability characteristics? At the moment we do not have adequate front line experience to make a value judgment on the architecture or the design of these web services.
During the initial period we have already made some false starts and incorrect assumptions but have managed to overcome them and move forward. These stories will be the subject of other blog entries.
I will close with a classic quote from Lao Tzu (Chinese Philosopher) because these few words convey both simplicity and conciseness of what we are trying to achieve
To know that you do not know is best
To pretend to know when you do not know is a disease.
Drop us a line if you have been down this road.