You can build services using BPEL. The only issue is that by nature most BPEL engines have a "one WS interface per process" rule which means you need to create a facade above it which represents the service interface and then implement the parts of it using BPEL behind the scenes.
Steve 2009/1/16 Nick Gall <[email protected]>: > On Fri, Jan 16, 2009 at 5:07 PM, David Chappell > > <[email protected]> wrote: >> I'll get more info but its easy to imagine that services that provide >> access >> to call detail records could be used by a variety of things besides fraud >> detection. >> Also if the design includes BPEL then it is by default more flexible than >> hard coded interactions between services. > > My point was that "leaving to the imagination" issues like sharability > and evolvability in an "SOA success story" fundamentally misses the > point of SOA. Yet virtually all "SOA success stories" are guilty of > this. > > BTW, BPEL can make some aspects of a design more flexible, eg the > process flow. But BPEL in itself has no impact on the flexibility of > the underlying services and the structure of the information that > flows between them. So even if BPEL enabled a particular change, a > brittle service interface may prevent it. Sort of a variation on "the > weakest link in a chain". The "most brittle link in a chain" is what > limits flexibility -- even in all the other links are BPEL-enabled > changeable links. > > -- Nick >
