I typically write articles that emphasize technology, such as "Use Enterprise Generation Language (EGL) in a Service-Oriented Architecture." (Subscribers can read this article at http://My.Advisor.com/doc/17767.) Essentially, that article discussed the nuts and bolts of constructing a Web service in an SOA. Web services technology is becoming fairly mature, including the WS-* specifications. What appears to be lacking is a clear purpose for Web services and a methodology that addresses the unique attributes of an SOA project. If an organization doesn't have basic process and control procedures in place, moving to a more advanced SOA, one that includes an Enterprise Service Bus (ESB), will be difficult. A concise definition of ESB can be elusive, but basically, an ESB has routing, transformations, protocol support, orchestration, and integration capabilities.
New distributed architecture
Some technologists measure Web services' great grandfather, CORBA's, maturity with respect to the number of program language bindings available as an indicator of maturity. In comparison, Web service clients can be a JavaServer Page, servlet, or Java application, or an executable written in languages such as C++, Perl, Visual Basic, or JavaScript. With respect to Web services in an SOA, you must determine when and where to deploy a true Web service and the appropriate modeling artifacts and specification approaches. However, organizations often have limited tolerance for protracted analysis and system design lifecycle phases; even though meta-data and model-driven programming are the wave of the future, whether the implementation is a Spring Web Flow or a standard Web service. (For more about Spring Web Flow, see my article at http://My.Advisor.com/doc/17767.)
Mission important, but not necessarily critical
My EGL article discusses exposing an EGL program (a fourth generation language for J2EE used by non-Java programmers) that integrates with MQSeries as a Web service. What the article doesn't discuss is when this type of architecture is appropriate.
Web services are, for the most part, an improvement in B2B technologies and standards for the Internet, including XML. An SOA doesn't necessarily mean you must expose all services as Web services, but there's a strong case for implementing B2B functionality as a Web service. So, during the discovery phase of an SOA project, a good candidate for a Web service is B2B functionality. Conversely, the technology doesn't have to be limited to B2B. It does represent a bridge technology for communicating between disparate environments; however, the SOA model, which uses Web service as its enabling technology, addresses a more complex problem set.