![]() ![]() Object result = client.execute("", paras) Invoking a remote procedure call Vector paras = new Vector() ![]() The word unconventional here means that I like to avoid conventions expressed in terms of strings scattered throughout the code that could also be defined via a programmatic API. Having said this, I must immediately assure you that I am no iconoclast and do not reject good programming habits quite the contrary. Occasionally, I prefer unconventional programming. This article focuses on the framework's precise inner workings, but does not make use of the protocol's details. You do not need to know XML-RPC, nor do you need to understand the Apache XML-RPC framework, even though a basic understanding will help you appreciate what follows. In this article, we use the Apache implementation of XML-RPC (Apache XML-RPC) to set up our framework. Roy Miller's " XML-RPC in Java Programming" ( developerWorks, January 2004) explains a useful example. A simple RPC engine can be used where a SOAP engine is clearly not feasible, such as with small applications that are not exposed via a Web server and where other forms of middleware are unavailable. This may help you understand the inner workings of similar but vastly more complex engines for other protocols or how to apply reflection to solve different problems. This article's main purpose is educational: I wish to show how reflection is employed to build a simple XML-RPC engine on top of existing XML-RPC frameworks. And by extension, the simple framework I discuss here must be regarded as a simplistic version of a SOAP engine, such as Axis. XML-RPC can be viewed as an oversimplification of RPC via SOAP. For simplicity, I discuss only concurrent remote procedure calls and leave the asynchronous case to the zealous reader. The framework presented here does not intend to hide the complexity of distributed computing, but it promises to reduce the pains involved in calling a remote procedure. in " A Note on Distributed Computing" (Sun Microsystems, November 1994). With respect to distributed computing, this point has been famously made by Jim Waldo et al. Needless to say, not all complexity can and should be hidden. Hiding complexity is good practice in itself. This article also shows that when given Java interfaces describing the remote procedures and datastructures conforming to the JavaBeans specification, you can use the power of Java reflection as incorporated into the Reflection and JavaBeans packages to invoke remote methods transparently and convert between the data types of XML-RPC and Java with surprising ease. In this article, I show how Java provides all you need to define remote interfaces and access remote methods: procedures and their signatures can be defined via Java interfaces, and remote procedure calls with XML-RPC can be wrapped such that both sides of a communication channel see only interfaces and suitable data objects. ![]() Yet, if your application grows and the number of remote interfaces increases, you might find that the necessary conventions-remote methods and data objects-must be somehow fixed. If your application is small or uses a limited number of remote procedures, you might prefer not to formally define the names of remote procedures and their signatures, but instead use XML-RPC in a straightforward way. It is straightforward to use, and easily available implementations such as Apache XML-RPC facilitate the protocol's use. XML-based Remote Procedure Call (XML-RPC) receives occasional attention as a simple protocol for remote procedure calls. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |