How can I access a local java class or a soap representation of it at run time with out using any stubs. Assuming I have the interface of the class and the domain objects for it.

Need you help. What is a good approach for accessing java interfaces remotely and in a transparent fashion?

What is a good approach for accessing java interfaces remotely? The answer seems too obvious. Use EJB session beans, or web services or RMI. is that the best way? Could I not use dynamic proxies and not use any client side or serverside skeletons and stubs? Can I not do this by not generating any thing? Would some one recommend WSIF to do this? What else is out there?

Phrased differently, if I have a jar file that contains an interface and the domain objects that support that interface, can I access one of its implementations that is sitting on a remote machine using a dynamic proxy. The protocol can be SOAP or EJB or just a plain homegrown over http for that matter.

Stated differently, if I were to implement a service layer using plain java interfaces and implementations, can I break that layer apart at deployment time with out involving any compile time changes. Such an option will give me the ability to multi-tier an application with very little fan fare. Programmers need even not know about SOAP or EJB etc.

For instance WSIF (web services invocation framework) seem to advertise a functionality that is similar in intent. But someone expereienced with WSIT comment on whether all you need is interfaces and domain objects? Also WSDL seem to be necessary for WSIF to work. Can it work with out any xml artifacts and assume a certain SOAP implementation and provide a dynamic proxy for it.

I am hoping someone out there looked into this before and I would like to hear from them. Either you can post the answer here or if you don't have an account, could you email me your opinion? My email is "satya at activeintellect.com".

Thanks in advance for considering this.

satya - Friday, January 12, 2007 10:28:29 PM

Introduction to web services in the websphere platform

Introduction to web services in the websphere platform

satya - Friday, January 12, 2007 10:31:52 PM

summary

5.0 and before used apache soap. 5.1 supported jaxrpc 1.0. 6.0 supported jaxrpc 1.1. You need rad 6 for this.

satya - Saturday, January 13, 2007 4:18:28 PM

web services red book in websphere 5.1

html distribution

satya - Saturday, January 13, 2007 4:20:01 PM

pdf version

pdf version

satya - Saturday, January 13, 2007 5:10:47 PM

A general discussion on dynamic invocations for soap

Web service invocation sans SOAP

SOAP has become almost synonymous with Web services, even though it is just one of many possible bindings for accessing Web services. This means that applications that make use of Web services usually do so through APIs tied to a specific implementation of SOAP. This series of articles will describe a more generic, SOAP-independent approach to invoking Web services called the Web Service Invocation Framework (WSIF). It was specifically designed to invoke Web services described using the Web Services Description Language (WSDL) directly, hiding the complexity of underlying access protocols such as SOAP.

satya - Saturday, January 13, 2007 5:14:17 PM

wsif home page

wsif home page

satya - Saturday, January 13, 2007 5:15:17 PM

what is wsif then

The Web Services Invocation Framework (WSIF) is a simple Java API for invoking Web services, no matter how or where the services are provided. Please refer to the release notes before you proceed with using WSIF.

WSIF enables developers to interact with abstract representations of Web services through their WSDL descriptions instead of working directly with the Simple Object Access Protocol (SOAP) APIs, which is the usual programming model. With WSIF, developers can work with the same programming model regardless of how the Web service is implemented and accessed.

WSIF allows stubless or completely dynamic invocation of a Web service, based upon examination of the meta-data about the service at runtime. It also allows updated implementations of a binding to be plugged into WSIF at runtime, and it allows the calling service to defer choosing a binding until runtime.

Finally, WSIF is closely based upon WSDL, so it can invoke any service that can be described in WSDL.

satya - Saturday, January 13, 2007 5:33:11 PM

Another article on wsif

Bridging islands of enterprise software

Every enterprise software system must tie together numerous existing software systems and codebases. Such systems might need to access existing Enterprise JavaBeans (EJB) components, legacy code in Java, or Web services over SOAP. Such dependencies make enterprise software systems brittle. They tend to break when external systems change location or when implementation technologies change. Basing all your components and solutions on SOAP is not always the answer because a SOAP-based implementation has penalties. Web Services Invocation Framework (WSIF) is the answer. It provides your Java codebase total freedom for such platform and location vagaries.

satya - Monday, January 15, 2007 1:21:36 PM

axis user user guide

axis user user guide

satya - Monday, January 15, 2007 3:05:12 PM

what is xfire?

what is xfire?

satya - Monday, January 15, 2007 3:06:43 PM

An article on XFire: The easy and simple way to develop Web services

An article on xfire XFire: The easy and simple way to develop Web services

satya - Monday, January 15, 2007 4:05:28 PM

Apache's recommendation on web services

home page of apache web services

satya - Monday, January 15, 2007 4:10:39 PM

What should I use in Java for web services if all I have is Tomcat?

What should I use in Java for web services if all I have is Tomcat?

axis 1.x
axis 2.x (requires jdk 1.5)
jax-rpc (part of jwsdp)
jax-ws (part of glassfish)

satya - Monday, January 15, 2007 4:13:48 PM

Problem with jwsdp and glassfish

These are heavy weights. All I want is a minimal set of jar files for web services. Even axis 2 seem to have lot of dependencies on other jar files.

satya - Monday, January 15, 2007 4:14:06 PM

axis 2 is probably more suited for jdk 1.5

axis 2 is probably more suited for jdk 1.5

satya - Monday, January 15, 2007 4:14:23 PM

axis 1.x seem to be a good candidate for experimentation with tomcat

axis 1.x seem to be a good candidate for experimentation with tomcat

satya - Monday, January 15, 2007 4:25:43 PM

xml-rpc.com

http://www.xmlrpc.com/spec