Thanks for your feedback Michael! legacy app wrapped and/or some of its features exposed via webservices pattern although a good one, does not apply in this case. The legacy web app(written 98% with oracle's plsql webtoolkit) has to be thrown away entirely since it is not allowed in the data center using apache+mod_plsql. So, basically, we have to re-arch the application from the ground up with newer technology and would like to keep most of its current features. So, I thought, lets transform it into a collection of web services. what do you think?
rgds Miguel --- In [email protected], Michael Poulin <[EMAIL PROTECTED]> wrote: > > Miguel, > the problem is not in what platform you use (Java or .NET) but in how you use services in their interactions and for the legacy app. > > I always consider such 're-architecting' as a quite risky exercise: the legacy app, its functions and operations were designed w/o consideration of advanced presentation layer on the top and w/o consideration of the service nature. Even if you expose app's functions via Web Services, the app will still dictate when it works (down time) and how it works ( number of concurrent users, throughput and alike ) while service customers do not expect/want to honor such constraints. > > The classic approach here is creation of the service layer on the top of the legacy app. The layer should provide real service behavior ( Service Contracts, execution contexts, consumer-centric SLA, not legacy-centric ones ) and delegate function execution to the legacy app. It is more than app's functions exposed via WS: it is not only the service interoperability, it is service choreography, business negative results (which might simply not observed in the legacy app), concurrency, state management ( stateful/less), security (which was never a case for legacy app as a monolithic entity), etc. > > And, the fist step to the service layer is service governance policies - run-time and development. For example, if you choose RPC/encoding style, you can easily expose app's functions but you will create totally coupled structure, no flexibility whatsoever to meet changing business requirements; if you choose document/literal style, you have to take care of XML Schemas and XML transformation in to the objects and back. > > Watch for all of this. > - Michael > > m_maq0 <[EMAIL PROTECTED]> wrote: Hello all, > > I might have the possibility of re-architecting an old app and so, I > am thinking of using web services :-). > > Now my questions is the following: > Would there a be a problem if I convert all the individual app > features/services each into individual web services to work together > as a single app? In other words..in a typical 3-tier app, the middle > tier would be a collection of web services that can be consumed by any > tier above or below it? > > I would like to expose those webservices via asp.net pages and > ClickOnce gui clients. > > In the model above I have more experience with .net, but would > consider using java (Xfire or Axis2) as well. Any pros/cons? > > thanks > Miguel > > > > > > > --------------------------------- > Moody friends. Drama queens. Your life? Nope! - their life, your story. > Play Sims Stories at Yahoo! Games. >
