Mark Baker wrote: > Well, it tells us that HTTP is a higher level "thing" than RMI, IIOP, > or how SOAP is commonly used, because it provides the operations being > invoked while the others do not. Considering how the entire Web > services architecture is premised on it being a lower level thing, I > think that's significant.
Here's what I see based on what we've gone on about so far... http://my.host/my/service.get( List<String>hdrs ); http://my.host/my/service2.get( List<String>hdrs ); http://my.host/my/service3.get( List<String>hdrs ); http://some.host/another/service.post( InputStream content, List<String>hdrs ); vs public interface MyService { public InputStream myService( ... ); public InputStream myService2( ... ); public InputStream myService3( ... ); } public interface Another { public InputStream service( ... ); } In the http case, the protocol only provides the ability to send String data in the GET URL to qualify the GET operation. In the POST case, you can send a "document" instead of using the URL for parameterization. The other HTTP operations have similar issues. In the Java interface/RMI case, InputStream and String parameterization are not a value added feature in an interface definition in many cases. My previous post about streaming logging records and other such things are places where an InputStream is helpful. In general, the applications API definition will have specific types for parameters and return data. So, in Java, we define the interfaces with tighter typing because that actually reduces the opportunity that the service will accept data, or return data that doesn't meet the API contracts. Does it generate more work, or create binding which seem prohibitive? It might, it depends on what the real purpose of the service is. As an aside, the java.net.URLConnection object, has mechanisms to interpret the mime-type information to create some appropriate Object types for the programmer to minimize work needed in using HTTP. The setContentHandlerFactory() method makes it possible for the developer to provide additional mappings so that URLConnection.getContent() can be made to return known object types instead of a byte[] or InputStream that the application is burdened to deal with. With this SPI, a deployment can include such content mapping as a drop in module. My point is that all of these things when put together provide no differentiating factors that make HTTP any more attractive than native RMI programming in the Java environment. The important point is what the services' deployed endpoint protocols are. If the service only provides and HTTP or FTP transfer, then you have to use that. A mediating service in Java, can use mobile code to hide this from the developer though a smart proxy such as the following: public class DocumentSmartProxy implements Document, Serializable { private transient Document doc; public String url; public DocumentSmartProxy( String url ) { this.url = url; } private void readObject( ObjectInputStream is ) throws IOException, ClassNotFoundException { URL u = new URL( url ); URLConnection conn = u.openConnection(); conn.setContentHandlerFactory( new DocumentContentFactory() ); // Transfer the document via whatever protocol the url specified doc = (Document)conn.getContent(); } ... Document interface method implementations ... } The whole point is that there is never a binding to a particular application protocol in the APIs. The interesting point is that this independence can occur at multiple levels in the architecture. Java's pluggable protocol handler mechanism allows me to create my own protocols as well. I have one, in particular, that opens a progress dialog to show downloads, and it does caching as well. So, large things that don't change often can be cached locally, and when they are updated, the user knows what is taking so long. Another point is that the application is not programming this capability all over the place. Mobile code and late bindings are very powerful as the AJAX crowd and scripting language users are rediscovering lately. Java just has some additional features that others are slowing recognizing and recreating. Gregg Wonderly ------------------------ Yahoo! Groups Sponsor --------------------~--> See what's inside the new Yahoo! Groups email. http://us.click.yahoo.com/2pRQfA/bOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
