In this forum, I believe we agreed that SOA and integration are not the same things, and even more - they are opposit things
- Michael ----- Original Message ---- From: kaburov <[EMAIL PROTECTED]> To: [email protected] Sent: Sunday, June 29, 2008 8:34:23 AM Subject: [service-orientated-architecture] Re: Legacy into SOA (was Vandersluis on a Data Abstraction Layer's Benefits) Michael IMHO integrating parts that are not designed to work together is common problem in many companies. One engineering best practice is that simplest solution is the most reliable solution so such companies take the road to simplification and consolidation of their software systems. They can share this investment with other companies that have similar style, probably subsidiaries, branches, etc --- In service-orientated- architecture@ yahoogroups. com, Michael Poulin <[EMAIL PROTECTED] .> wrote: > > Congratulation, Patric! > > Patric has demonstrated that a non-service oriented legacy system ( ERP in his example) is an obvious risk, if not a threat, to the SO based solution. What we gonna do about it? > I am confident that just wrapping legacy systems with Web Services and pushing a process via an ESB is a risky business. If one takes Sun's Composite Application model for an analysis, how reliable the entire system is? What we have to do to mitigate this risk either in services, or in the infrastructure , or in both? > > - Michael > > > ----- Original Message ---- > From: Patrick May <[EMAIL PROTECTED]> > To: service-orientated- architecture@ yahoogroups. com > Sent: Saturday, June 28, 2008 1:20:06 PM > Subject: Re: [service-orientated -architecture] Re: Vandersluis on a Data Abstraction Layer's Benefits > > > On 27 Jun 2008, at 21:50, htshozawa wrote: > > --- In service-orientated- architecture@ yahoogroups. com, Patrick May > > <pjm@> wrote: > >> > >> OpenSpaces uses the Spring > >> dependency injection capabilities to allow business logic to run in > > a > >> Space Based Architecture without coupling the implementation of that > >> logic to a particular vendor. > >> > > Interesting, but you're cutting out the major portion of the business > > market because most commercial software from major software companies > > are proprietary and do not use Spring. > > An ESB based on Spring can bridge this gap by offering adapters to > > proprietary systems (packaged and custom) while offering POJOs to > > software based on open communities. > > This is exactly what GigaSpaces does, in terms of its Spring support. > > You're absolutely right about the number of COTS products that aren't > really designed for integration. I've built a few systems that use a > grid (both data and compute) infrastructure to mediate the workflow > among such components. One big advantage of the grid in these > environments is that it combines the advantages of queue-based and > publish/subscribe messaging without their disadvantages. Messages > remain for as long as necessary and can be delivered reliably in > either one-to-one or broadcast mode. This makes recovery from failure > much easier than with traditional ESBs because components can come up > in any order. It also makes scalability easier because the grid acts > both as a distributed, in-memory shared state for stateless services > and as a deployment mechanism for those services. > > This architecture allows the development of highly resilient > distributed systems on top of unreliable hardware and software > components. Because the workflow is mediated by the highly reliable > grid, the failure of individual agents (some of which use existing ESB > transformation tools) and backend systems does not stop the end-to- end > processing. One example of this is an order management system I built > for a U.K. telco. None of their backend systems (CRM, Billing, > Provisioning, etc.) were designed for integration. They had (and > probably still have) a very flakey ERP system that once went down for > over half a day during peak season, bringing their old OMS to its > knees and costing the company over £2 million. > > One day a few weeks after the new system was in place, the head of > Web sales came running down to complain that "The OMS is broken! We > haven't received any orders from the Web in 18 hours!" I looked in > the grid and found a large number of orders waiting to be processed by > the, you guessed it, ERP system. Once quick phone call to ask ops to > reboot the ERP app and we were back in business without losing a > single order. > > That's the kind of capability that businesses will pay for. > > 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) >
