Well, we want not only "the behavior of the existing applications" but the behavior in SO manner.
For example, let us take an old Lotus Domino 5 applications server and a Java application deployed on it. The application performs very important to us functionality. Now, we TAKE it as a FUNCTIONALITY, i.e. behavior, wrap it with a Web Service and ... fail. Why? It is the right behavior, we need it! The reason is a very small thing not visible at the level of Functionality - Java on Lotus Domino 5 is single-threaded. That is, the legacy application simply cannot work in SOA. Period. The example may mislead you toward threading issues. However, my point is that useful behavior of legacy applications is not enough to reuse it as-in in SOA. This is why I dislike Sun Microsystem's promotion of their Composite Application which promises 'resurrect' legacy apps' functionality by connecting legacy apps to the bus. - Michael ----- Original Message ---- From: Patrick May <[EMAIL PROTECTED]> To: [email protected] Sent: Monday, June 30, 2008 4:18:03 AM Subject: Re: [service-orientated-architecture] Re: Goodson & Jason on Building a Data Services Layer On 29 Jun 2008, at 16:03, Rob Eamon wrote: >> <<Best Practices for SOA: Building a Data Services Layer >> >> If businesses are to have any hope of building flexible services that >> offer the performance and agility needed to succeed with SOA, those >> businesses must solve the technical challenge of accessing >> information – that is, data – across application platforms and their >> organization as a whole. > > I disagree. The challenge in an SO approach is *not* to gain access to > data within legacy applications. (That would be a data oriented > approach--and, as it happens, a typical old-school integration > approach). An SO approach would strive to extract and leverage > *services* from legacy applications. Or at least capabilities that > would be an implementation component of a service implementation. Exactly. We want the behavior of the existing applications. How they implement that behavior is of little to no interest. Regards, Patrick ---- [EMAIL PROTECTED] S P Engineering, Inc. Large scale, mission-critical, distributed OO systems design and implementation. (C++, Java, Common Lisp, Jini, middleware, SOA) ------------------------------------ Yahoo! Groups Links
