Develop Reference

Wrapped service

I've been reaching wrapped services examples for java and spring and I cannot find anything useful. There are plenty of tutorials for java and spring web services but nothing on wrapped ones
Basically if given 2 wsdls, how can I create a wrapped service? I am hoping there are working examples or even a nice start to finish tutorial to help me out.

i think what you're looking for is like a 'federated service' or a 'business delegate' pattern. that is, one WSDL showing all the methods for the other two WSDL's combined.
one way of doing this is using Spring Integration. with Spring Integration you could expose your 'consolidated' WSDL and then route the various methods to the specific correct actual endpoints. have a look at this in the Spring Integration documents about exposing a webservice and then subsequently routing and invoking others.

interface-based Java/Groovy web services

In my experience, most distributed object technologies (RMI, CORBA, etc.) work something like this:
define a service interface
write an implementation of the interface
use a tool (rmic, IDL compiler, etc.) that generates code which enables a client to get a reference to an implementation of the interface given some endpoint (URL).
The important point is that the service interface is a shared contract that both the client and service must adhere to. I've had a look at metro, and it doesn't seem to follow this pattern.
I'm looking for alternative suggestions that do support this kind of interface-based web service development. Unfortunately, I'm required to use SOAP, so libraries that only support RESTful services are no good to me.
Ideally, I would like to follow a code-first, rather than a contract-first appeoach, i.e. I define the (Java) service interface and the WSDL is generated from that, rather than the other way around.
Solutions that support defining or implementing the service using Groovy (instead of Java) are particularly welcome.

Metro allows you to annotate a given method, put a hint or two about the endpoints in the servlet container configuration files, and then have the WSDL generated automatically on request.
This is very nice, and save you all the trouble of having to create a full WSDL for just exposing a method or two.

Metro is good (+1), but Apache CXF's Simple Frontend goes one step further: you don't have to annotate anything. It generates WSDLs, clients and servers from plain Java interfaces.

Spring MVC without HTTP requests

I need to create a system oriented around Methods where providers can register for the Methods they handle and consumers can do two things (for now) - either get Metadata for a method or execute it. I'm considering creating a REST style architecture where methods are resources with unique URIs and an interface consisting of two methods - getMetadata and Execute.
I'll need to have an equivalent of #RequestMapping so that the provider that handles specific methods can be located by the central dispatcher. As a result the provider will return either Model or Metadata object.
This looks pretty similar to Spring MVC but I don't want to expose and consume my resources(methods) over the web and use http as this will incur unnecessary overhead. Instead I want to use it like a standard java API where java methods are called and java objects are transferred.
I can do that by writing my own equivalent of #RequestMapping and Dispatcher logic but I was wondering if there's a better way to do this with Spring. Any suggestions?
Thanks!
Kostadin

You are saying you want to do using REST and everything will have a unique URI but not over HTTP?? Sounds like you are looking for RMI or something similar... Chech Burlap or Hessian both of them has excellent support from spring.

There's software out there called NetKernel that might interest you. Its literature says that it is an implementation of Resource-Oriented Computing. It looks like it rigorously separates its logical computing model from the physical details. It's RESTful, defining a resource model, a limited set of verbs, and a naming scheme. Implemented in Java. Comes with HTTP and other transports built in.
It doesn't have a Java in-process transport, but you could probably write one for it pretty easily.
Hmm...if you never need to process requests from out-of-process sources, it's probably overkill for you, but maybe it will show you some useful patterns.

can java consume .NET object returned by ASP.NET web service?

i have an ASP.NET web service that returning a custom entity object (Staff):
[WebMethod]
public Staff GetStaffByLoginID(string loginID){}
how would i consume this in Java?
thanks!

ASP.NET automatically generates a WSDL that contains the interface definitions for your web methods and the types they consume/return.
Apache Axis provides a tool called WSDL2Java that will generated the all of the code you need to consume the webservice. Simply point it to:
http://yoursite.com/YourWebService.asmx?WSDL
If you browse directly to the .ASMX file, you'll get a nice test harness that you can use to explore the various methods you can call.
Once Axis reads your WSDL, it will generate some proxy classes, one of them will be based on the interface of Staff.
However, I would not use this class as your actual business object, and instead would wrap access to the web service through a service layer. This service layer would use the proxy Staff class to populate your real business object.
This protects your consuming code from any interface changes that may happen to the web service in the future, keeping the actual area of code that would be modified as small as possible.
I do this for a living, interopping between Java and .NET on many platforms using SOAP.
EDIT: Why the is this downvoted? It's the only correct answer here.

Just use Standard WSDL as mentioned by flyswat if you are using traditional asmx web services.
other solutions if not using standard ASP.NET Web Services:
Use REST
http://www.infoq.com/articles/REST-INTEROP
http://www.codeproject.com/KB/XML/WSfromJava.aspx
Make sure the objects are serializable and as long as the you can cast it to a similar class on the Java side, you are good. Else, you might have to write some custom class mappers in Java.

You may be able to do this by running Java on IKVM.

Simpler-than-JBoss way to have POJO RPC in Java with container session management

Currently, I only know a way of doing RPC for POJOs in Java, and is with the very complex EJB/JBoss solution.
Is there any better way of providing a similar functionality with a thiner layer (within or without a Java EE container), using RMI or something that can serialize and send full blown objects over the wire?
I'm not currently interested in HTTP/JSON serialization BTW.
EDIT: For clarification: I'm trying to replace an old EJB 2.1/JBoss 4 solution with something more easy to manage at the container level. I need to have entire control over the database(planning to use iBATIS which would allow me to use fairly complex SQL very easily), but the only things I want to keep over the wire are:
Invocation of lookup/data modification methods (automagic serialization goes here).
Transparent session control (authentication/authorization). I still have to see how to accomplish this.
Both items have to work as a whole, of course. No access should be granted to users without credentials.
Because I'm not very fond of writing webapps, I plan to build a GUI (Swing or SWT) that would only manage POJOs, do some reporting and invoke methods from the container. I want the serialization to be as easy as possible.

As is nearly always the case, Spring comes to the rescue. From the reference documentation, you will want to read Chapter 17. Remoting and web services using Spring.
There are several methods to choose from. The beauty of Spring is that all your interfaces and implementations are vanilla POJOs. The wiring into RMI or whatever is handled by Spring. You can:
Export services using RMI:
probably the simplest approach;
Use HTTP invoker: if remote access is an issue, this might be better for firewalls, etc than pure RMI; or
Use Web Services, in which case I would favour JAX-WS over JAX-RPC.
Spring has the additional benefit in that it can do the wiring for both the server and the client, easily and transparently.
Personally I would choose either (2) or (3). HTTP is network friendly. It's easy to deploy in a Web container. Jetty's long-lived connections give you the option over server push (effectively) over HTTP.
All of these methods allow complex objects to be sent across the wire but they are subtly different in this regard. You need to consider if your server and client are going to be distributed separately and whether it's an issue if you change the interface that you need to redistribute the class files. Or you can use a customized serialization solution (even XML) to avoid this. But that has issues as well.
Using a Web container will allow you to easily plug-in Spring Security, which can be a bit daunting at first just because there are so many options. Also, HttpSession can be used to provide state information between requests.

Simple RPC is exactly what RMI was built for. If you make a serializable interface, you can call methods on one app from another app.

If you only need value objects then just ensure the POJOs implement Serializable and write the objects across sockets (using ObjectOutputStream). On the receiving end read the objects using ObjectInputStream. The receiving end has to have a compatible version of the POJO (see serialVersionUID).
Hessian/Burlap 'protocol-ize this: http://hessian.caucho.com/ and http://www.caucho.com/resin-3.0/protocols/burlap.xtp

You could try XStream (http://x-stream.github.io/) over REST. Easy to apply on e pre-existing set of pojos.
Can you give some further information as to what you're trying to achieve, since you're not interested in rest/json ?