Sambuca Embedded HTTP Framework / News: Recent posts

May 29, 2008 - Sambuca version 1.0.6 has been released. It includes support for boolean and boolean arrays in the Sambuca Simple Web Services framework. We also started integrating RogueLogic's new JBeanDescriber utility, which will enable the Sambuca project to support basic Java Beans as parameters and return types for methods in Simple Web Service Facades. The utility has been included in the com.roguelogic.util package.

With release of Sambuca version 1.0.5, the project now includes the Sambuca Simple Web Services Auto Mounter framework. This framework allows you to automatically turn any java class that exposes public methods into a Web Service via an implementation of the Sambuca HTTP Server called the WebServiceAutoMounter.

The Auto Mounter will use java reflection to scan a provided Java class for public methods and automatically generate an XML descriptor (non-SOAP) and allows for Remote Execution of the methods it "mounts" on the HTTP server via web service calls.... read more

Sambuca Version 1.0.2 includes an improved Socket Wrapper implementation and exposes reuse address and socket lingering overriding to the user. It is a minor release, but definitely improves the stability and customization of the framework.

Sambuca is an Open Source, Java HTTP Server framework that allows developers to embed a HTTP server directly in their applications with custom HTTP Request Handlers, so that their application can directly process incoming HTTP Requests and easily send back HTTP formatted responses to the requesting client. Applications can host standalone HTTP Services such as Web Service without having to deploy and integrate with a full application server such as Tomcat, JBoss, or WebLogic.... read more

Sambuca Version 1.0 has been released! Sambuca is a HTTP Server and Request Handling framework that allows Java developers to embed a HTTP Server directly within their applications. It allows developers to create custom HTTP Request Handlers which can be plugged directly into the HTTP Server itself, this allows applications which may not be designed to be hosted within an application server such as Tomcat, JBoss, or WebLogic to become HTTP aware. For example, an application can deploy their own built-in Web Services so that other applications can make XML-RPC requests directly into the application across the network. Clients of these XML-RPC enabled application need not be Java-base so long as they can make HTTP requests. Most modern languages such as Java, C#, Perl, and others have libraries included with the language distribution which allows programmers to open HTTP URLs and read and write on those connections without having to deal with the low level socket calls. Although these languages solve the needs for HTTP Client, they are poor in allowing developers to easily start and received requests the opposite direction. Meaning these languages do not include libraries which allow developers to "listen" for incoming HTTP requests they only allow applications to send HTTP requests. The Sambuca framework solves this problem for Java based applications, by allowing developers to easily start an HTTP Server which is fully contained and self managed and allows them to easily plug in to the Request handling flow, so that their applications can listen for and receive incoming HTTP Requests. Traditionally applications require separate deployments to Web Application Servers such as Tomcat and others to host objects such as Servlets and JSP pages which may through some very complex process such as writing to a database or communicating directly via sockets or RMI to some process running externally from the Web Application Server. This creates "Rube Goldberg Machines" or overly complex application with so many round about processing modules to accomplish what on paper should be a very straight forward solution. This problem is extremely command in large Enterprise such as Wall Street Investment Banks, where a lot of custom software is written. People tend to refrain from writing socket based applications directly due to the complexity and difficult in maintaining these applications across large organizations. Plus custom application level protocols makes it difficult for inter-process communications since everyone needing to interface with the application either needs to understand the protocol or obtain a client library from the team maintaining the server. This places limits on the languages and systems which may communicate with the process. Since HTTP is an extremely common protocol and again built-in language support for becoming an HTTP client, HTTP is the natural choice for inter-process communications across a network.