Right now TCP inbound endpoints are implemented as TCP servers that listen for data coming from different clients. In Mule ESB 2.2.6 we are adding a new feature to inverse the control: TCP inbounds can now poll data from remote servers.
It is really easy to switch to this strategy. Let’s take a look of how a mule configuration looks like:
(more…)
Recently, there was an interesting article on ReadWriteWeb questioning the long term effect of the proliferation of public APIs, versus merely offering crawlable data. On one hand – the article argued – APIs offer a great deal of control to the publisher and they are great for access to real-time information. On the other hand, if data is only accessible through an API then it is not available for spiders and crawlers and thus won’t show up in search results. In effect, the public loses out, since less data can be searched for.
However, I think this takes a somewhat limited view on what an API can be. In fact, if the API is designed properly then the API itself can be discovered via a crawler, along with all the information the API provider chooses to make public. This is particularly true for RESTful APIs where ‘discoverability’ is a fundamental design concept. For example, in the open source RESTx project – a fast and simple way to create RESTful web services – a RESTful, documented and fully discoverable API is created automatically. (more…)
Ever now and then you find a new piece of software or feature, which ends up changing the way you work, saving you time and just overall making things easier for you and your organization. We think that the RESTx project with its new 0.9.2 release gains such a feature. We call it “specialized components”. What is that, why is it useful and how will it make things easier for you? In a moment I will use an example for illustration, but let me first provide a little background on RESTx. If you are already familiar with RESTx, you can skip over the next chapter.
RESTx: A quick introduction
RESTx – we believe – is the fastest way to create RESTful web services. RESTx is a fully RESTful, small, stand-alone server. A RESTx server houses components – code that implements some functionality for data access, integration or processing, written in either Java or Python. (more…)
Today we are happy to announce the release of version 0.9.2 of RESTx – the fastest and simplest way to create RESTful web services.
Besides the usual, numerous small improvements and fixes there are also a number of exciting major new features and capabilities:
(more…)
We have put up a screencast that shows you how to get started with RESTx, our platform for the rapid, easy creation of RESTful web services.
RESTx allows developers to contribute data access, integration and processing components in Java or Python, using a very simple API. Then, with nothing more than a browser and a simple HTML form, users provide parameters for those components, which the RESTx server uses to create new RESTful web services, resulting in easy to use, safe URIs that give users access to the data they need. For example, a developer may contribute a component for access to the API of a legacy application, but the users now provide different sets of query parameters, resulting in resources such as ‘customer list’, ‘order queue’, etc. (more…)
Our RESTx project – a platform for the rapid and easy creation of RESTful web services and resources – is largely written in Python. Python is a dynamic, duck-typed programming language, which puts very little obstacles between your idea and working code.
At least that’s the feeling I had when I started to work with Python several years ago: Never before was I able to be so productive, so quickly with so few lines of code. I was hooked. No wonder some people describe it as ‘executable pseudo code’: Just write down what you want and for the most part, it will actually work.
Now there’s a price to pay for this increased developer productivity, where the interpreter somehow figures out at run time what it is that you actually want to do and how to let your code deal with all sorts of different types: Python is interpreted, it’s dynamic and this means that for the most part it’s slower than compiled languages.
In this article here, I will talk about an interesting optimization technique for Python, which will come as a surprise to many Python developers.
(more…)
For those of you who develop in Eclipse, and are also running Tomcat as a stand-alone JVM process (the way Tomcat is usually run), it is fairly easy to debug your web applications using the Eclipse debugger. For that matter, you could also debug Tomcat’s code this way as well, if you want to inspect what Tomcat is doing with a request.
(more…)
Once in a while I get questions about whether Apache Tomcat implements a way to include other files in server.xml, Tomcat’s main configuration file. The answer is that there is a way to do it, and that Tomcat didn’t have to implement a new feature for it to work. The way to do it is: XML entity includes.
(more…)
At TSSJS last week I had a conversation with a Mule user that was having a problem invoking more than one method on a service component (just a POJO object). His scenario was that he had a service with multiple inbound endpoints and a service component with multiple methods, some with matching parameter types. Existing Mule users will be aware that Mule will match methods against the parameters received in the current message. Thus is two methods have the same parameters Mule cannot match the method to invoke.
(more…)
