Excerpts from recent interview of Sandy Carter, responsible for driving IBM's cross-company, worldwide SOA marketing initiatives

The three business entry points for SOA are people, process, and information. The two technical entry points are connectivity and reuse.

The five most common questions from customers who are beginning their SOA journey are usually:
Can I still use my existing software and hardware?
Where do I begin with SOA?
Is SOA for large companies only?
How do I gain the much-needed SOA skills?
How do I prove the value of SOA to the executives in my organization

First, SOA is specifically designed to protect existing IT investments in software and hardware. The most successful SOA deployments are found at those companies that begin with a view of SOA as a long-term business strategy. These companies approach SOA incrementally, through one of the five entry points cited above, and continuously measure and monitor its success at every step along the way.

For those companies that are expanding their SOA, the questions are usually about, "how do I document and share my business processes?" To do this, it's important that the SOA initiative includes a strong governance strategy to make sure that its services can be easily managed, monitored, and reused while ensuring only best practices are shared.

In terms of developing skills, it's clear that the industry is facing a serious SOA IT skills shortage. In fact, a recent study found that 56 percent of IBM customers cited lack of skills, mainly individuals with a blending of IT technical understanding and business process acumen, as the leading inhibitor to SOA.

To address the SOA skills shortage, IBM recently announced new tools and certification programs to help organizations develop teams of individuals with so-called "T-shaped" skills, which encompass both deep business skills, represented by the horizontal line of the "T," and technical understanding, represented by the vertical line.

IBM recognizes that a successful SOA strategy requires both IT and business executives to collectively map out goals and illustrate the value of the SOA project. To this end, IBM offers free, online assessment tools to help executives at companies of all sizes determine their organization's business and IT needs. For example, IBM's SOA Business Analyzer helps an organization identify its greatest assets and opportunities that are ripe for an SOA project.

Also, the IBM BPM with SOA ROI Assessment Tools helps organizations assess their Business Process Management (BPM) readiness through 10 simple questions. It then delivers a BPM score, assesses an organization's position to realize benefits from BPM, and provides recommended next steps. Through this assessment, both IT and business executives can better understand the business value of an SOA strategy.

The significant advantages of the Java-to-WSDL approach are:
It is a quick way to expose legacy implementations as Web services.
It requires little or no knowledge of WSDL or XML because the WSDL document is generated by the tools.
It provides better and easier support for exposing overloaded operationsThe disadvantages of the bottom-up approach are:
The generated schema defining the data types in the WSDL document derives only from the Java classes from the provider's environment and not from any standards-based schema.
The provider-side data types may not be simple DTOs, in that they include additional business logic. Such logic can't be reconstructed on the requester side.
The generated schema is embedded in the WSDL, which makes reuse of the schema, perhaps in the definition of other Web services, more difficult. It is possible, of course, to extract the schema from the original WSDL document.
The development of the server-side Web service implementation and the client-side Web service requester can't proceed in parallel. The server-side skeleton and DTOs have to be developed before a WSDL can be generated that can be used to generate the client-side stubs and DTOs.
Incremental changes to the interface are more difficult to manage. For example, if the interface of the class that implements the service is changed and the WSDL is regenerated, more significant changes could occur in the WSDL, thus causing interoperability with existing clients to fail. The basic problem is that, on the server-side, the class implementing the service is deemed the master interface and, on the client-side, the WSDL provided by the server-side is the master interface. These two different masters can cause the interfaces to become out of sync and difficult to debug and fix.
The namespaces of the embedded schema types are typically generated from the Java package names of the server-side JavaBeans. Therefore, if the package names are changed, the namespace will be changed, which means the types are no longer compatible. Most of the tools allow a package to namespace mapping, but this must be explicitly set during the execution of the tool.

WS-Addressing Links

http://www-128.ibm.com/developerworks/webservices/library/ws-address.html

http://dev2dev.bea.com/pub/a/2005/01/ws_addressing_intro.html

ebXML Links:-

http://dev2dev.bea.com/pub/a/2004/12/ebXML.html

http://dev2dev.bea.com/pub/a/2005/01/ebxml_security1.html

http://dev2dev.bea.com/pub/a/2005/01/ebxml_security2.html

Must Read SOA Links

http://www-306.ibm.com/software/solutions/soa/

http://dev2dev.bea.com/pub/a/2006/03/enterprise-architecture.html

http://dev2dev.bea.com/pub/a/2006/08/soa-service-lifecycle-design.html

http://dev2dev.bea.com/pub/a/2006/11/soa-service-lifecycle-run.html

http://dev2dev.bea.com/pub/a/2005/12/soa-roadmap.html

http://dev2dev.bea.com/pub/a/2005/11/planning-for-soa.html

http://dev2dev.bea.com/blog/kemo/archive/2007/04/integration_ser.html

http://dev2dev.bea.com/blog/arch2archeditor/archive/2007/04/services_earning_their_keep.html

http://dev2dev.bea.com/blog/quinton_wall/archive/2007/04/the_state_of_ja.html