CrossWorlds ships EJB component interfaces into its products


News: CrossWorlds ships EJB component interfaces into its products

  1. In a classic example of the benefits of EJB in action, business integration software vendor CrossWorlds has announced that developers can now execute CrossWorlds software components through a set of fully J2EE compliant Enterprise Java Bean components. This will allow integration with CrossWorlds from within any J2EE application server.

    Press Release:
    BURLINGAME, Calif.--(BUSINESS WIRE)--July 9, 2001-- CrossWorlds® Software, Inc. (Nasdaq:CWLD - news), a leading business integration software provider, today announced support of Enterprise JavaBeans (EJB) component technology. EJB component technology enables CrossWorlds' customers to leverage interoperability within application server environments to reduce time-to-market for creating critical applications and to benefit from an overall increase in developer productivity.

    Applications developers can now execute CrossWorlds supported business process components as Enterprise JavaBeans, as CrossWorlds bean components can be accessed from any EJB compliant application server regardless of operating system. EJB technology greatly reduces the complexity of developing N-tier enterprise class applications by providing application developers with the ability to process business information through standards based, re-usable and simple-to-use business process components. This in turn reduces the overall cost of development while speeding up time-to-market of new IT projects.

    ''Customers and business partners all stand to benefit from the more efficient and effective development using EJB component technology,'' said Buff Jones, senior vice president of products at CrossWorlds Software. ''CrossWorlds is meeting the needs of enterprises worldwide through the ongoing growth and support of Java technology-based components.''

    About CrossWorlds® Software

    CrossWorlds Software, Inc. provides a comprehensive suite of business integration software that unites and extends business processes. Our combination of products - business process integration modules, sophisticated, easy-to-use tools and a patented, scalable architecture - make integrating processes within the enterprise and across the internet possible.

  2. This is great stuff....and one can see that the next logical step is to also have the components available as web services so that they can be integrated into any solution, regardless of platform.

    In another thread, people were talking about web services being a me, what we're finally starting to see is that you may not have to re-invent the wheel every time you create an application. At some point, I could see that software will really come down to integrating different components to make up a powerful solution. Like having my Siebel SFA solution talk to the CrossWorlds components...

    The future is definitely going to be interesting!

  3. While this announcement adds yet another validation of the J2EE architecture, it appears that this is more of an attempt at survival for a company that established a proprietary architecture for EAI. Is there really a demand for combining what I would call a legacy EAI product with J2EE?
  4. Absolutely. Look at companies like Vitria and WebMethods for example. They built excellent suites on top of their own server infrastructure. This made sense back when this all started but things have changed recently.

    Now, customers have already invested in deploying an application server, this is usually a multi-million investment and thats without the licenses. They are developing applications with these servers.

    Lets say the customer needs a new feature and CrossWorlds have a solution. If the solution is a standalone solution then getting it in to the customer is difficult as support staff etc need to be trained to support it, you need to integrate it with the app servers etc. If this solution was a bunch of ejbs that a team can just deploy on the app server then this is a much easier sale to the customer than the standalone situation.

    In addition to the above which isn't really tech related but is none the less a crucial fact for vendors trying to sell software to customers, as J2EE gets more mature and things like JCA come along then this lowers the cost of entry to EAI for the big boys. Take Web Methods for example. Web Methods is very like a service broker. One of its main selling points was the range of connectors between it and back end systems. The JCA standard now means that very soon every J2EE app server on the block will also have the same range of adapters. BEA for example, have its B2B protocol engine (Process Collaborator), a BPM engine (Process Integrator) and now JCA lets it get rid of it's elink adapters by either using the JCA adapters supplied by the back end vendors or it can convert the elink adapters to JCA and then license them to the back end vendors or directly sell them even to customers using WebSphere for example. I think almost every commerical J2EE server will be competing with Web Methods very soon.

    So, EAI vendors need to spend their investment dollars more strategically than in the past and concentrate their effort on the value add of EAI and not the infrastructure that can be bought off the shelf and that the customers have probably already bought/deployed and won't want to repeat the expense.

    J2EE vendors have already realized that it's the integration market where their future revenue lies and that means they are coming after the EAI area. It may be easier for EAI type companies to convert to J2EE to make them-selves a more attractive acquistion for a large middleware vendor than to try to compete in a race that they will probably lose in the end anyway. The vendors are already demonstrating an appetite for buying in technology rather than developing it in house.
  5. The real question is whether the EAI vendors can offer a value-added solution over the J2EE based solutions like BEA. These are very expensive systems that were intended to make there market by forcing deployment of their services architecture to your trading partners. Now that J2EE is establishing an ever increasing market share, where will they get those big fees? Yes some companies have such a hodge-podge of systems and services that they may buy into the EAI model. But more recent studies indicate that new development is replacing these systems with the J2EE architecture.

    Are any of the EAI vendors profitable?
    Will they ever be?
  6. J2EE is hardly cheap also[ Go to top ]

    Well if you look at the prices of a J2EE suite that includes workflow, messaging, J2EE, a database and various adapters you're talking over 60K/cpu. Take a small setup, 4 boxes. 2 boxes run J2EE and its stack, 2 boxes run the database in HA. Thats 8 CPU licenses for the boxes and another 8 for the database. Thats serious money for a basic J2EE project if they want to cluster.

    On another topic, these prices will in my opinion drive smaller companies to the ASP route rather than developing their own, it's just too expensive. See my data center article for more.
  7. J2EE is hardly cheap also[ Go to top ]

    Just to clarify, I'm obviously talking about 4 processor boxes.

  8. J2EE is hardly cheap also[ Go to top ]

    You're correct. Pricing is driving many companies to the ASP model. I just happend to work for one.

    The ASP model is the future of distributed services especially where management of the underlying data may require domain knowledge that is not easily acquired. Many companies attempt to implement a solution without complete knowledge of the problem domain. Instead they try to make the problem domain fit into one they already know. You can expect the project to fail.