I recently wrote some data access methods (plain old Java) that use immutable objects for both the request objects and the resulting data objects. I like the immutable objects because they prevent a good deal of confusion from appearing in the client code which I've seen in the past when people attempt to mutate and reuse objects.
Anyway, that was months ago. Now a colleague is having trouble with some web service generation stuff (attempting to expose my methods) which expects everything everywhere to be a JavaBean.
My question is: does web service stuff generation stuff always mandate use of JavaBeans? Is there another way?
Most web service frameworks provide some way for you to supply custom serializers/deserializers for types. Sounds like that is what you need here.
If it isn't clear why that's necessary, it is because the framework needs to know how to translate your Java class into XML and vice versa. Serializing and deserializing JavaBeans (classes with get and set properties) is easy if you follow the naming strategy, but you should also be able to supply your custom type serializers for classes that do not follow the bean pattern.
There are two general approaches to Web service development: top-down and bottom-up.
In the top-down approach, a Web service is based on the Web service interface and XML types, defined in WSDL and XML Schema Definition (XSD) files. The developer first designs the implementation of the Web service by creating a WSDL file. From this skeleton Java classes can be created to which the developer can add the required code. This skeleton implementation serves as an interface with the business logic. This process is also one of the J2EE standard - JAX-RPC based API for Web services which defines standard mappings between Java classes and XML types.
In the bottom-up approach, a Web service is created based on the existing business logic in Java beans or EJBs. A WSDL file is generated to describe the resulting Web service interface. Seems like your colleague is using this approach.
I would recommend a top-down rather than a bottom approach as you would have more control on the interface definitions and naming. Also your colleague could use your existing classes through the tooling generated skeleton interface.
Related
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.
Greetings,
I have a complicated scenario to handle. I have a wsdl file which uses a particular XML schema.
The XML schema is actually a handcrafted implementation of a specification. There is also a Java based implementation of the same specification. So the XSD used in WSDL and Java classes at hand are quite similar, but not exactly same.
Almost all web service stacks allow creating classes from WSDL or creating WSDL from Java class annotations.
What I want to do, is to use the WSDL and bind XSD used in the wsdl to existing java classes.
Should/can I do this by manually replacing generated Java classes with existing ones? Is it a matter of changing type names in config files and moving binding annotations to existing classes?
If you know any best practices, or java web service stacks that support this kind if flexibility in a practical way, your response would be much appreciated.
Best Regards
Seref
I suggest Spring's Web Services module, which has no code generation involved, but provides a clean separation of concerns. Different concerns are broken out nicely by allowing you to provide your WSDL and existing schema(s) on one side (contract first), your existing Java-based domain model on the other, and a way to plugin in your OXM (Object-XML Mapping) technology of choice.
Since you have hand-crafted WSDL/schema and hand-crafted Java classes, the real work will be in configuring your OXM. I prefer JiBX as it keeps the concerns separated (no XML annotation garbage mixed into your domain) with JAXB as a backup if the learning curve looks too steep. Spring Web Services supports several other OXM frameworks, and you can even use several different ones at once.
As far as best-practices, I consider hand-crafted code a best practice, though I may be in the minority. If you generate classes from XML you end up with classes that are simple data containers with no behavior (assuming you want to regenerate them whenever your WSDL/XSD changes). This is bad if you favor the object-oriented paradigm because you end up having to place your "business logic" in utilities/helpers/services etc. instead of in the domain objects where it really belongs. This is one reason I favor JiBX. I can make very nice OO objects with behavior, a nice clean schema that doesn't necessarily match the objects, and can manage changes to either side with a mapping file similar to how hibernate does it for ORM (Object-Relational Mapping). You can do the same with JAXB, but that requires embedding XML structure into your object model, and binds a single XML representation to it (whereas with JiBX you can have many).
MOXY (I'm the tech lead) was designed for instances where you have an existing XML Schema and an exsting object model. It accomplishes this through XPath based mapping and can ever handle cases where the models are not that similar:
parse google geocode with xstream
MOXy also has an external binding file:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
MOXy is a JAXB implementation with extensions (A couple of which are mentioned above). IF you go ahead with Spring, MOXy is configured as a JAXB implementation, and you need to add a jaxb.properties file in with your model classes with the following entry:
javax.xml.bind.context.factory=org.eclipse.persistence.jaxb.JAXBContextFactory
I've just finished reading about SOAP via Spring-WS in "Spring in Action", 2nd edition, by Craig Walls from Manning Publications Co. They write about Contract First, much like the Spring docs, with making a message and method XML and then transforming that to XSD and then again to WSDL, while wiring up the marshalling and service path in Spring.
I must admit, I'm not convinced. Why is this a better path than, let's say, making a service interface and generating my service based on that interface? That's quite close to defining my REST #Controllers in Spring3. Do I have options of going a path like this with making SOAP webservices with Spring?
Also: I'd like to duplicate an already existing webservice. I have its WSDL and I can have my service placed instead of it. Is this recommended at all? If so, what's the recommended approach?
Cheers
Nik
I think you must have your wires crossed.
Contract first means defining a WSDL, and then creating Java code to support this WSDL.
Contract last means creating your Java code, and generating a WSDL later.
The danger with contract last is if your WSDL is automatically generated from your Java code, and you refactor your Java code, this causes your WSDL to change.
Spring-WS only supports contract first
2.3.1. Fragility
As mentioned earlier, the
contract-last development style
results in your web service contract
(WSDL and your XSD) being generated
from your Java contract (usually an
interface). If you are using this
approach, you will have no guarantee
that the contract stays constant over
time. Each time you change your Java
contract and redeploy it, there might
be subsequent changes to the web
service contract.
Aditionally, not all SOAP stacks
generate the same web service contract
from a Java contract. This means
changing your current SOAP stack for a
different one (for whatever reason),
might also change your web service
contract.
When a web service contract changes,
users of the contract will have to be
instructed to obtain the new contract
and potentially change their code to
accommodate for any changes in the
contract.
In order for a contract to be useful,
it must remain constant for as long as
possible. If a contract changes, you
will have to contact all of the users
of your service, and instruct them to
get the new version of the contract.
Toolkit's point about Java interfaces being more brittle is correct, but I think there's more.
Just like there's an object-relational impedance mismatch, there's also an object-XML mismatch. The Spring web service docs do a fine job of explaining how collections and the rest can make generating an XML document from a Java or .NET class problematic.
If you take the Spring approach and start with a schema you'll be better off. It'll be more stable, and it'll allow "duck typing". Clients can ignore elements that they don't need, so you can change the schema by adding new elements without affecting them.
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.
I am working on an existing Java project with a typical services - dao setup for which only a webapplication was available. My job is to add webservices on top of the services layer, but the webservices have their own functional analysis and datamodel. The functional analyses ofcource focuses on what is possible in the different service methods.
As good practice demands, we used the WSDL first strategy and generated JAXB bound Java classes and a SEI for the webservices. After having implemented the webservices partially, we noticed a 70% match between the datamodel. This resulted in writing converters which take the webservice JAXB classes and map them with the service layer classes.
Customer customer = new Customer();
customer.setName(wsCustomer.getName());
customer.setFirstName(wsCustomer.getFirstName();
..
This is a very obvious example, some other mappings where little more complicated.
Can anyone give his best practices, experiences, solutions to this kind of situations?
Are any of these frameworks usefull?
http://transmorph.sourceforge.net/wiki/index.php/Main_Page
http://ezmorph.sourceforge.net/
Please don't start a discussion about WSDL first vs code first.
I am experiencing the same issue on my project. I created a factory for the generated objects and use it for creating objects.
Customer customer = factory.createCustomer(wsCustomer);
Which isolates the construction code, w/o altering the generated code.
I think the real question is... how much of the code generators do you want to use in the future, and can you get them to generate what you're doing now.
Converting everything to your current data model is a good idea, if you don't care about the code generation capabilities of your tools, or they can adapt to what you want.