News: Encoding Service Engine and JBI Mock Framework available

  1. The Encoding Service Engine is a JBI component providing plug-n-play compression capabilities to ESBs to improve performance between web services by decreasing bandwidth consumption. The compression mechanism itself is configurable and independent from the transport. For example, one configuration might use GZIP compression over HTTP and another might use FastInfoset over SIP. The JBI Mock Framework is a set of classes that allow developers to test JBI Components at a unit level, mocking out the Normalized Message Router (NMR). These projects have been open-sourced under the Open JBI Components incubator project on java.net. The goal of this project is to foster community-based development of JBI components that conform to the Java Business Integration specification (JSR 208). We are actively developing these components and are looking for both developers and users. Encoding Service Engine Features:
    • Compliant JBI Service Engine
    • Supports GZIP and Fast Infoset compression
    • Best suited for low bandwidth environments (Tested between two JBI containers with a 56k connection)
    • Transport independent
    • Tested in Apache ServiceMix and OpenESB
    JBI Mock Framework Features:
    • Provides Mock interfaces and Basic implementations for the majority of JBI interfaces
    • Mock classes to write unit tests for Binding Components and Service Engines
    • Examples showing how to use the Spring Framework and JUnit to create a unit test
    Learn More For more information, please visit the Open JBI Components project on java.net.
  2. Re: Reusable JBI components[ Go to top ]

    This is highly impressive, all due credit observed here. Part of the value proposition of re-usability has always been the promise of a compatible, third-party supplied marketplace of components that adhere to JCP standards, such as EJB and JBI. I purposefully start the verbal exchange on whether this is a viable model simply because it is important to discuss, air differences, and get to some resolution on what is the best model for doing this, so that the developers worldwide thinking about creating re-usable components will be empowered to do so. It might be that the best model is on java.net as the Open JBI Components initiative is demonstrating. When I was at Sun, alongside some of the JavaSoft guys, we tried to create an EJB marketplace that was (probably) before its time. I still believe in that model, and am greatly encouraged by the efforts of the JBI sub-community to pursue a similiar development methodology. nice job, all involved...
  3. . The Project Open JBI Components is an excellent idea. I'am sure that the described components are a great incentive for many other developers/communities/manufacturer, to provide also such powerful technical or business-driven components - based on the standard of Java Business Integration (JBI). Maybe its also an impulse for some additional ESB Manufacturer to provide some closer support for JBI in the near future. It would be initiate a technical revolution, when the customer some day could use and deploy their technical and business-driven components without great changes and problems on: - Sun OpenESB - Apache ServiceMix - SAP XI - IBM WebSphere ESB - Bea AquaLogic Service Bus - Iona Artix - Celtix Enterprise - JBoss ESB - Sonic ESB - Mule ESB - ... and many other powerful Integration-Solutions ... BTW: Nice introduction to JBI and associated informations : http://www.glassfishwiki.org/jbiwiki/Wiki.jsp?page=LearnJBI Roland http://www.soa-competence-network.de