Next Wave of Tools, IDEs To Support 'Process Development'

A new wave of web services tools and IDE extensions are coming to support process-driven services, predicts ZapThink, a web services research firm. These tools will sport better web services modeling and some high-performance cross-platform extensions for both the Java and .NET worlds. See why ZapThink says your next toolset should have "integration" built-in.

Tags: Web Services, Messaging, Schmelzer, Business Process, Report, Developers, Language,


Developers will soon see a new wave of web services tools and IDE extensions to support process-driven services, according to ZapThink's latest report, "Service-Oriented Process."

For purposes of the report, ZapThink, a web services research firm in Waltham, Mass., defines SOP as the orchestration, choreography, composition, workflow, transactions, and collaboration of web services. While this SOP tools transformation won't happen overnight, once it starts, predicts Ronald Schmeltzer, ZapThink senior analyst and author of the report, the entire web services tool niche will explode to become an $8 billion market -- 70 times its current size of just about $120 million.

"Increasingly, we'll see that integration will be built into other things, like application serves, brokerage servers and even Windows" -- with the advent of new pre-bundled .NET functionality, Schmelzer told IDN.

"Once you get past a pilot project, it's hard to create discrete web services. There's a need to create them all together" and tie them into a single end-to-end process, Schmelzer added. That constructive process, he explained, will be done visually, providing developers with an experience much like the one they get using Visual Basic or graphical front ends to some Java-based app servers, such as WebSphere and BEA's WebLogic.

"When you're building a service-oriented process, you're not supposed to say 'This is a web service and that's a mainframe, '" Schmelzer said. "You're supposed to just create the process, independent of what platforms -- service or mainframe -- contribute each piece."

The bigger development challenges lie in connecting processes, not simply building up vertical data or application to sit on a server or mainframe, he added. "For example," he went on, "I have a business process I'm trying to implement, and my process can consist of several web services that I need to connect to one another, and one way would be to wrap a higher-level process around that service and use the messaging platform to connect those services together. "

The key to this connecting process is to put a process-supporting engine behind the pretty GUI tools by merging IDEs and tools with messaging technologies, Schmelzer said.

"Microsoft has some key messaging technologies in BizTalk, and they have Project Jupiter, which is certainly pushing work in this area," Schmelzer stated. "In the Java world, there's JMS [Java Messaging Service], and in the mainframe world, there's MQ[Series] and other messaging queuing.""Because every tier has some access to some messaging, in the first round of SOP tools, there will have to be a way to tie in traditional IDE and development tools into these messaging systems."

But, Schmelzer concedes, an overarching standards effort is necessary to ensure tool and platform interoperability, and business processes that run across multiple vendor platforms. "We're getting to the point where app servers and messaging technologies need to converge on some standard ways of defining and transporting messages," he said.

The standards landscape will converge on a single choreography, orchestration and process flow specification in the next 12-18 months. Schmeltzer's candidate for such a standard is BPEL4WS. Despite reports of vendor conflicts and disagreements over BPEL4WS, Schmeltzer said he's encouraged because "BPEL4WS is already getting a lot of traction" from vendors since IBM and Microsoft handed the proposal over to OASIS.

To placate worried ORB developers, Schmelzer hastened to add that these new messaging-oriented tools will not "make the concept of an object model obsolete." But, he added, it will mean that objects or ORBs "don't have to be the center of the world anymore."

Other key findings of the report include:
  • A loosely coupled (SOP) "Service-Oriented Process" is key to meeting business agility requirements.
  • By 2005, over 70% of web services implementations will be process-driven.
  • Services must be developed devoid of process to participate in an SOA that meets the goals of business agility.
  • Service-Oriented Management techniques can assist in managing discrete services as well as end-to-end business processes.
ZapThink's "Service-Oriented Process" report highlights key concepts in orchestration, choreography, composition, collaboration, coordination, workflow, and transaction management. Among them:
  • (BPEL4WS) Business Process Execution Language for Web Services,
  • Business Process Modeling Language (BPML),
  • WS-Coordination,
  • WS-Transaction,
  • WS-Reliability,
  • WS-ReliableMessaging,
  • WS-Addressing, Business Process Modeling Notation (BPMN),
  • Business Transaction Protocol (BTP),
  • Conversation Support for Web Services (CS-WS),
  • ebXML Business Process Specification Schema (BPSS),
  • RosettaNet Partner Interface Processes (PIPs),
  • SOAP Conversations, Web Services Choreography Interface (WSCI),
  • Web Services Flow Language (WSFL),
  • Extensible Process Definition Language (XPDL),
  • Microsoft's XLANG and
  • W3C working group on Choreography.



    back