Ann, I am confused about the following:
"It's a misconception to think that just because you're using BPEL toä design applications you might actually generate reusable service components in the process. The component services in a BPEL process are rarely reusable." BPEL uses existing services (and renders them as new services). Thus, the services you use from within BPEL are WYSIWYG, i.e. if they are not reusable, you cannot do anything. The services you create with BPEL are reusable if the modeler focusses on reusability. If they are not reusable it's not "BPEL's fault" - you can write Jave components that are not reusable, but that's not Java's fault... Similar on: "All BPEL systems I've looked at are application- centric -- your goal with these tools is to create an application, not to create shared, resuable services." You can use BPEL both, to create applications, or to create a "discrete service" for reuse purposes. Standard application vendors (SAP,...) use business processes to create applications; that's why it's one of the prime principles of BPEL to be able to support creating applications (out of services). So, it's a feature not a bug ;-) Frank ----- Ursprüngliche Mail ---- Von: Anne Thomas Manes <[EMAIL PROTECTED]> An: [email protected] Gesendet: Dienstag, den 16. Januar 2007, 14:53:38 Uhr Betreff: Re: [service-orientated-architecture] Re: Forrester Create a Long Acronym On 1/15/07, Hitoshi Ozawa <Ozawa_Hitoshi@ ogis-ri.co. jp> wrote: > > Is SOA about replacing the current technologies with a new one? I > thought it was about extending > the use of existing technologies while offering use of new technologies. > As the hard disk market > wasn't about larger disk capacities, lower cost, faster access time, I > don't think the SOA market > is about offering "better" technological functionalities then the > current technologies. > > H.Ozawa SOA is not about technology. SOA is about different design principles. New technologies can facilitate the adoption of SOA design principles (particularly governance, design, modeling, and code generation technologies) , and/or they can exploit the artifacts and assets produced by adopting the SOA design principles. BPEL-based technologies can exploit artifacts and assets, enabling developers to build applications from an existing portfolio of services. They can also facilitate the adoption of SOA design principles, but in most cases, I don't think they do. All BPEL systems I've looked at are application- centric -- your goal with these tools is to create an application, not to create shared, resuable services. This is another reason why I warn people away from BPEL, especially early in their adoption cycle. You really shouldn't be thinking about composing services into applications until you have a portfolio of services that can be used for composition. It's a misconception to think that just because you're using BPEL to design applications you might actually generate reusable service components in the process. The component services in a BPEL process are rarely reusable. Anne > > Sanjiva Weerawarana wrote: > > Similarly, BPEL was designed as a base with the idea that vendor groups > > would define extensions (activities, scripting languages etc.) which > > would suit such group's purposes. Have those happened yet? I think Frank > > pointed to a few starts but AFAIK things are not prime time yet. I don't > > think you should throw the baby out with the bathwater. > > > > Sanjiva. > > > > ___________________________________________________________ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
