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: [email protected] 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 > <[EMAIL PROTECTED]> 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)
