[PPenumarti]

Just as UML simplified OOD, it's time to embark on standardized symbols for depicting SOA.

Value added feature of UML tool has been code generation.
Likewise, a comparable value added feature for SOA tool should be BPM integration.

[jwenting]

UML simplified OOA&D?
hmm... At most it made communication between people easier, but the UML isn't exactly a "simple" tool. Many of its predecessors were quite effective and actually easier to use, once you were familiar with them.
All UML achieved was to make it easier to transition from one project to the next as there was no new diagramming syntax to learn. The tools of course are still (and always have been) pretty horrendous.

As to code generation, code generation from UML is a dismal failure anywhere I've seen it. At the very most you can use it to generate the skeletons of your first draft. The majority of tools will not take existing code into account, or if they do will require such cumbersome procedures to stay synchronised with the codebase that it's just not worth using them.

"SOA" itself is nothing, it's a marketing term and buzzword used to lure potential customers.
The implementing technologies have their tools and diagramming capabilities, their code generation, etc.
Many use UML or UML-like syntax for those diagrams on the technical level.
But as those tools are not generally meant for use by technical people (they're the umpteenth attempts to "make programming unnecessary by allowing managers to generate entire applications by inputting their business processes directly) the most seen interfaces are more fancy, more flashy, designed to please the marketing department who want to use them to show potential customers how quickly a demo application can be put together from a well rehearsed script.

[PPenumarti]

First of all I thank you for offering a debate. Let me put few aspects in perspective and separate some concerns.

Saga of UML has'nt reached moon or climbed mount Everest yet. It got drifted into marketing black hole :-)
I urge you to consider the state of affairs before Booch/Rumbaugh et al lead the UML notations and after. Is'nt it now easy to express singletons and proxys to developers?
I concede that Activity diagrams with forks and joins couldn't replace the grandfathered workarounds in Visio flowcharts. Visio was very handy tool for business analysts compared to any of UML tools.
We'll talk about market penetration strategies of tools on a separate note.

Likewise, code generation has been a challenge to tool makers - refinements lacked funding and support from user community.

Neverthless, a picture is worth thousand words. Purpose of diagramming tools is to provide insight and perspectives to variety of audience, at the least to two groups viz., developers and business side stake holders. Services aligned to business goals is the motto - broadly speaking about SOA. I see there is scope for standardizing notational semantics. Unless we depict the architectural layering of services, say horizontal layers like orchestration layer is above business services layer and it's inturn above application services layer, developers connect less into the big picture of the organization. LIkewise business stake holders need to visualize the processes that connect the services.

Irrespective of availability of industry standards - all such notations in some homegrown form are existing within the walls of organizations that adopted SOA. When the experts move across organizations, communication becomes easier as it happend in case of UML. Ease of transition and communication are sufficient concerns to begin deliving into standardization. Success of one tool over the other is a different discussion, IMHO.

And BPM tools are evolving in their appeal. Some of them are creative in luring customers - just play with these little blocks on screen, click deploy and boom there you go with a production running application without need for developer and tester. That's pretty ambitions marketing jargon. Don't get carried away yet. We all know that need of programming skill is inevitable if you need to optimize the production code. HQL cannot replace optimized SQL - though OR mapping has it's own scope in some projects. Risks versus Benefits and ROI should be the perspective for those considerations.

Connecting people with standardized notations and providing integration into BPM, has some scope to investigate further. We need participation and community process to make it happen.