--- In [email protected], Patrick May <[EMAIL PROTECTED]> wrote: > > On 27 Jun 2008, at 21:50, htshozawa wrote: > > --- In [email protected], 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.
This recalls observations I have made in the distant past that rather than expose Jini/JavaSpaces in the raw to unimaginative programmers, it would have been more fruitful to dress the technology up in a form with whose interfaces they were more philosophically familiar. Mind you, that was before middleware had sematically transmogrified into that vague all-embracing entity known as an ESB... Gervas > > 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) >
