We Keep Coding

Using a SOAP artifact in Java

I've been searching all over and I can't find a simple example for this. I need to call a Web service from my Java application using SOAP. I've run the utility to create all the Java artifacts from the WSDL. Let's say one is called "Customer", and these are the first few lines:
#XmlAccessorType(XmlAccessType.FIELD)
#XmlType(name = "Customer", propOrder = { "id" })
public class Customer {
I assume that I start by creating a new Customer object and setting all the attributes I need. What I need to know is how to take that object and pass it to the service as a SOAP envelope(?). I also have artifacts for submit, like "SubmitCustomer", but again I'm not sure how to take my Customer object and keep going with it.
I'm sure this is a basic question, but all I've been able to find in my searches are examples of creating your own XML, or basic "how to get started with SOAP", or how to generate artifacts, but that's all. If someone can point me to a good resource, that would be great.

Among generated classes must be one extends javax.xml.ws.Service.
Look through this class to find a method annotated with #WebEndpoint.
Open file with definition of return type of this method.
There you will find methods correspond to WSDL operations.

Architecture for building XML requests?

I'm writing a client tool that uses soap xml webservices (using CXF to autogenerate the classes from provided wsdl). I wonder which design is best to construct the xml requests I want to sent to the webservices. My problem is that the request to be send has to be formed of many different parts/objects. I'm looking for a clean way of how to structure the creation of these parts, that finally form the full request.
The request might be growing to 200-500 XML lines, so it is probably a bad idea to create these all in a single class.
To illustrate my goal, let's assume a request requires a Person object, and some params have to be set on that object like name, birthday, address etc. I could think of the following designs:
1) static utility that returns the constructed xml part
class XMLUtil {
public static PersonType createPerson(String name, String birthday, Address Address) {
//the xml person to send within the request
PersonType p = new PersonType();
p.setName(name);
p.setBirthday(birthday);
p.setAddress(address);
//assume some more params, but the concept is clear I hope
return p;
}
}
2) static utility that adds the constructed xml part to the xml request
class XMLUtil {
public static void addPerson(WebserviceReq req, String name, String birthday, Address Address) {
//create person as above
req.addPerson(p);
}
}
3) non static service
class XMLService {
private WebserviceReq req;
public XMLService(WebserviceReq req) {
this.req = req;
}
public void createPerson(String name, String birthday, Address Address) {
//create person as above
req.addPerson(p);
}
public WebserviceReq getWebserviceReq() {
return req;
}
}
usage:
1)
WebserviceReq req = new WebserviceReq();
req.addPerson(XMLUtil.createPerson("test", "2014-01-01", address));
req.send();
2)
WebserviceReq req = new WebserviceReq();
XMLUtil.addPerson(req, "test", "2014-01-01", address);
req.send();
3)
WebserviceReq req = new WebserviceReq();
XMLService service = new XMLService(req);
service.createPerson("test", "2014-01-01", address);
service.getWebserviceReq();
req.send();
Which approach would you prefer if there is not only a person object to be constructed for the xml request, but lots of more parts that you are trying to encapsulate somehow, so that not a single class is blowing up?

What I have done and used many times to great effect is the following...
Create a set of classes for each of the element types in XML - this to include the following...
Node - Base class for all elements. Supports setting and getting of attributes.
Leaf - base class for any element containing a value (simple elements)
Branch - a collection of Leaf elements. Children are accessed by index.
Entity - A Branch that allows keyed access to its children.
As opposed to how you are doing it now, where you have a bean named Person which has private variables and requires code to set and get each value, you would use an Entity instance and add leaf instances to it, for example...
Entity person = new Entity("Person");
person.add(new Leaf<String>("FirstName", "Rodney"));
person.add(new Leaf<String>("LastName", "Barbati"));
The power here comes from adding the ability of the base classes to write themselves out as XML. This gives you the ability to quickly create new types and not have to write code to convert them to XML.
You can also make this completely transparent by deriving the person class from Entity and adding the child elements in its constructor. I would also advise you to add a validation method that checks for the existence and correct formatting of each required child.
There are classes provided in Java for dealing with XML elements but they are somewhat cumbersome and not easily used. You could consider either wrapping them or deriving from them to make them more easily used.
The above gives you the ability to output XML easily without requiring boilerplate code - if you marry it with a custom SAX parser that can construct a given class for a given element, you have a complete basis for high speed, streaming XML services that can support new data types almost instantly with very little lines of code - often none at all.
If you find yourself writing custom code to output any XML structure, understand that you don't have to - there is a better solution.
BTW: The above classes would lend themselves quite nicely to defining the data structures in Spring.
Good Luck,
Rodney Barbati

#XmlIDREF not seeing hierarchy when marshalling to XML

I'm very new at XML and I'm having a problem I'm not able to solve and after looking around for hours I've decided to post my problem.
I'm using #XmlIDREF to just have the XmlID of some java classes on the XML doc.
All works fine, but when JAXB looks for the ID depeen on the tree hierarchy it seems that it couldn't find it and marhsalls the whole object again.
I'll show you the (simplified) model, it's all about optical routers, java classes represent the router and some components:
#XmlRootElement
#XmlAccessorType(XmlAccessType.FIELD)
public class OpticalRouter {
// #XmlID inherited from upper class
private List<FiberConnection> fiberConnections = new ArrayList<FiberConnection>();
}
That's a fiber connection:
#XmlRootElement
#XmlAccessorType(XmlAccessType.FIELD)
public class FiberConnection {
#XmlID
private String instanceID;
#XmlIDREF
Card card;
#XmlIDREF
Port port;
#XmlIDREF
Channel channel;
}
And finally:
#XmlAccessorType(XmlAccessType.FIELD)
#XmlSeeAlso({
DropCard.class,
AddCard.class
})
public class Card{
// #XmlID inherited from supper class
}
All works fine when I marshall ports and channels due they don't have subclasses.... but when it's time to marshall the cards if it's an AddCard or a DropCard it marshalls it another time instead of using the IDREF.
It seems that JAXB doesn't find them on the hierarchy...
If I change the original "Card card;" of FiberConnection for an "AddCard" for example it works too (JAXB finds the IdREF and doesn't marshall it again).
Hope I have explained that clearly.
Ask if not, I'll be glad to answer :)
Thanks in advance!
EDITED
Ok, I've come back with new info and results to explain myself better.
Due it's a huge class model and I don't want to make the post to much difficult to read I have created a kind of UML class diagram to make it much easier to read with some important info that should help (XML annotations and parameters). I have also included #XmlElement tags as Blaise advised me (thanks again).
Here you can find the yEd UML archive: yEd file
And there an UML jpg if you don't have/want to download graph
editor: jpg file
I also include (to finish) a part of the XML to better see what's happening.
Here I have a fiberConnection as the above mentioned.
I have a scCard and a fiberChannelPlan that have already been marshalled before on the XML doc (checked) but they are being marshalled again...
In exchange, srcPort, srcChannel and fiberChannels, also marshalled before, have only their ID's.
<OpticalRouter>
<fiberConnections>
<instanceID>FiberConnection#29e83b01</instanceID>
<srcCard xsi:type="DropCard" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<instanceID>DropCard#6b02b23d</instanceID>
<type>11</type>
<subtype>1</subtype>
<chasis>0</chasis>
<fiberChannelPlan xsi:type="ChannelPlan">
<instanceID>ChannelPlan#7e246b6d</instanceID>
<firstChannel>0</firstChannel>
<lastChannel>0</lastChannel>
<maxFreq>196.1</maxFreq>
<minFreq>191.6</minFreq>
<fiberChannels>Channel/360</fiberChannels>
<fiberChannels>Channel/368</fiberChannels>
<fiberChannels>Channel/376</fiberChannels>
<fiberChannels>Channel/384</fiberChannels>
</fiberChannelPlan>
<cardExpressPort>Port#4f781d1d</cardExpressPort>
<carCommonPort>Port#56bf83ad</carCommonPort>
</srcCard>
<srcPort>Port#56bf83ad</srcPort>
<srcChannel>Channel/184</srcChannel>
</fiberConnections>
</OpticalRouter>
I think that the problem is something related to that post I found (even if I'm using linux and java 1.6) or other posts I have seen here on StarckOverflow:
java.net/jira/browse/JAXB-870
Thanks in advance!
P.S: all code I'm using is opensource and can be downloaded from the main source at a git repository if someone thinks it should be easier for him.

You need to make sure that each object in your graph is referenced through a containment/nesting relationship (such as #XmlElement), this forms the XML. I don't see where this requirement is met in your model. Then you can use #XmlID/#XmlIDREF to have key based relationships within the tree to turn it into a graph.
For More Information
http://blog.bdoughan.com/2010/10/jaxb-and-shared-references-xmlid-and.html

Patterns: Populate instance from Parameters and export it to XML

I'm building a simple RESTFul Service; and for achieve that I need two tasks:
Get an instance of my resource (i.e Book) from request parameters, so I can get that instance to be persisted
Build an XML document from that instance to send the representation to the clients
Right now, I'm doing both things in my POJO class:
public class Book implements Serializable {
private Long id;
public Book(Form form) {
//Initializing attributes
id = Long.parseLong(form.getFirstValue(Book.CODE_ELEMENT));
}
public Element toXml(Document document) {
// Getting an XML Representation of the Book
Element bookElement = document.createElement(BOOK_ELEMENT);
}
I've remembered an OO principle that said that behavior should be where the data is, but now my POJO depends from Request and XML API's and that doesn't feels right (also, that class has persistence anotations)
Is there any standard approach/pattern to solve that issue?
EDIT:
The libraries i'm using are Restlets and Objectify.

I agree with you when you say that the behavior should be where the data is. But at the same time, as you say I just don't feel confortable polluting a POJO interface with specific methods used for serialization means (which can grow considerably depending on the way you want to do it - JSON, XML, etc.).
1) Build an XML document from that instance to send the representation to the clients
In order to decouple the object from serialization logic, I would adopt the Strategy Pattern:
interface BookSerializerStrategy {
String serialize(Book book);
}
public class XmlBookSerializerStrategy implements BookSerializerStrategy {
public String serialize(Book book) {
// Do something to serialize your book.
}
}
public class JsonBookSerializerStrategy implements BookSerializerStrategy {
public String serialize(Book book) {
// Do something to serialize your book.
}
}
You POJO interface would become:
public class Book implements Serializable {
private Long id;
private BookSerializerStrategy serializer
public String serialize() {
return serializer.serialize(this);
}
public void setSerializer(BookSerializerStrategy serializer) {
this.serializer = serializer;
}
}
Using this approach you will be able to isolate the serialization logic in just one place and wouldn't pollute your POJO with that. Additionally, returning a String I won't need to couple you POJO with classes Document and Element.
2) Get an instance of my resource (i.e Book) from request parameters, so I can get that instance to be persisted
To find a pattern to handle the deserialization is more complex in my opinion. I really don't see a better way than to create a Factory with static methods in order to remove this logic from your POJO.
Another approach to answer your two questions would be something like JAXB uses: two different objects, an Unmarshaller in charge of deserialization and a Marshaller for serialization. Since Java 1.6, JAXB comes by default with JDK.
Finally, those are just suggestions. I've become really interested in your question actually and curious about other possible solutions.

Are you using Spring, or any other framework, in your project? If you used Spring, it would take care of serialization for you, as well as assigning request params to method params (parsing as needed).

How to create an ontology in Java?

I've some data triplets that I want to write in some sort of basic OWL ontology. I've triplets like:
Delhi is part of India
or
India is an Asian country
Note that I've relations like "is-a", "part-of", or "related-to". What's the simplest way to build an ontology? Any working example or a reference to an example website will be great help!

There are a lot of different things mixed up in your question, I strongly suggest you take a bit of time (away from the keyboard!) to think through what you're trying to achieve here.
Firstly, geographic ontologies can get quite complex, and a lot of work has already been done in this area. Probably the obvious starting point is the GeoNames ontology, which gives names to geographic features, including cities like Dehli and countries like India. At the very least you should re-use those names for the places in your application, as that will maximise the chances that your data can be successfully joined with other available linked-data sources.
However, you probably don't want the whole of GeoNames in your application (I'm guessing), so you also need to be clear why you need an ontology at all. A good way to approach this is from the outside of your application: rather than worry about which kind of Jena model to use, start by thinking through ways to complete the sentence "using the ontology, a user of my application will be able to ...". That should then lead you on to establishing some competency questions (see, for example, section 3 of this guide) for your ontology. Once you know what kinds of information you want to represent, and what kinds of queries you need to apply to it, your technology choices will be much clearer. I realise that these applications are typically developed iteratively, and you'll want to try some code out fairly early on, but I still advocate getting your destination more clearly in mind before you start your coding journey.
You imply that you want to use Jena to drive a web site. There are many choices here. Don't be mislead by the term semantic web - this actually means bringing web-like qualities to interlined data sets, rather than putting semantics into human readable web pages per se. While you can do so, and many people do, you'll need some additional layers in your architecture. We typically use one of two approaches: using Jena with a templating engine, such as Velocity, in a servlets container, or using a Ruby web framework and driving Jena via JRuby. There are many other ways to solve this particular problem: Jena doesn't address web publishing directly, but it can be used within any Java-based web framework.
Finally, regarding namespaces, you should really re-use existing vocabularies, and hence namespaces, where possible. Don't make up new names for things which already have representations on the web of data somewhere. Use GeoNames, or DbPedia, or any of the many other published vocabularies where they fit. If they don't fit, then you should create a new name rather than use an existing name in a non-compatible way. In this case, you should use the web domain of your application (e.g. your company or university) as the basis for the namespace. Ideally, you should publish your ontology at the base URL of the namespace, but this can sometimes be hard to arrange depending on local web policies.

I suggest OWL API from Manchester University. In this way you can start to create your ontology "on the fly" in Java, and with a single method invocation you can serialize it in your preferred format (RDF, Manchester Syntax etc) if you need, or directly working on the in-memory representation. In this way you can rapidly prototype and experiment your ontology in the context of your program.
For an overview of the library and its main componenets I suggest the tutorial (code tutorial) provided by the creator of the library, it covers 90% of the basic needs.
PS: Protégé is based on OWL Api, you can also try it as suggested, but expecially in the beginning I preferred to rapidly play with ontologies and switch to some engineering environment like Protege when my mind was clear enough. In addition, with an external ontology you would need to learn how to navigate it, that IMHO it is really not worth in the very beginning.

Have a look at Stanford's Protege. It's an ontology editor.

You'd just declare a triplet class consisting of a subject, object, and predicate. "has-a" is a predicate, so your ontology elements would look like:
"Dehli", "is-in", "India"
"India", "is-in", "Asia"
"India", "is-a", "country"
This doesn't address queries, of course, but given a decent data store (even a database would do) you could start to build a flexible ontology with a decent query mechanism.
JENA is far, far more capable than what this would create, of course; it does provide the semantic query stuff, as well as far better resource definition and resolution. However, it's a lot more involved than a simple triplet structure; it all depends on what you need.

/**
- This is maven dependencies for owl-api
<dependency>
<groupId>net.sourceforge.owlapi</groupId>
<artifactId>owlapi-api</artifactId>
</dependency>
<dependency>
<groupId>net.sourceforge.owlapi</groupId>
<artifactId>owlapi-apibinding</artifactId>
</dependency>
* First of all you need to initialize ontology:
**/
private OWLDataFactory factory;
private PrefixManager pm;
private OWLOntology ontology;
private String pmString = "#";
private OWLOntologyManager manager;
private OWLReasoner reasoner;
private ShortFormEntityChecker entityChecker;
private BidirectionalShortFormProviderAdapter bidirectionalShortFormProviderAdapter;
private void initializeOntology(String fileContent)
throws OWLOntologyCreationException {
InputStream bstream = new ByteArrayInputStream(fileContent.getBytes());
this.manager = OWLManager.createOWLOntologyManager();
this.ontology = this.manager.loadOntologyFromOntologyDocument(bstream);
IRI ontologyIRI = this.ontology.getOntologyID().getOntologyIRI();
this.pm = new DefaultPrefixManager(ontologyIRI.toString()
+ this.pmString);
this.factory = this.manager.getOWLDataFactory();
ReasonerFactory factory = new ReasonerFactory();
this.reasoner = factory.createReasoner(this.ontology);
Set<OWLOntology> onts = new HashSet<>();
onts.add(this.ontology);
DefaultPrefixManager defaultPrefixManager = new DefaultPrefixManager(
this.pm);
ShortFormProvider shortFormProvider = new ManchesterOWLSyntaxPrefixNameShortFormProvider(
defaultPrefixManager);
this.bidirectionalShortFormProviderAdapter = new BidirectionalShortFormProviderAdapter(
this.manager, onts, shortFormProvider);
this.entityChecker = new ShortFormEntityChecker(
this.bidirectionalShortFormProviderAdapter);
}
/*
After that you need to define your classes and the relations of the classes. These relations calls as object properties in ontology. Instance of each ontology class calls as individual and the attributies of the classes (for person name, age , adress) calls as data-property.
*/
// To create a new individual of an ontology class :
public OWLClass getClass(String className) {
return this.factory.getOWLClass(":" + className, this.pm);
}
public OWLNamedIndividual createInvidual(String cls, String invname) {
OWLNamedIndividual res = this.factory.getOWLNamedIndividual(":"
+ invname, this.pm);
this.manager.addAxiom(this.ontology,
this.factory.getOWLDeclarationAxiom(res));
OWLClassAssertionAxiom axiom = this.factory.getOWLClassAssertionAxiom(
getClass(cls), res);
this.manager.addAxiom(this.ontology, axiom);
return res;
}
// To create an object property :
// This method will create an object property named prop if it is not exist.
public OWLObjectProperty getObjectProperty(String prop) {
return this.factory.getOWLObjectProperty(":" + prop, this.pm);
}
public void addObjectProperty(String propname, OWLNamedIndividual prop,
OWLNamedIndividual obj) {
OWLObjectPropertyAssertionAxiom axiom = this.factory
.getOWLObjectPropertyAssertionAxiom(
getObjectProperty(propname), obj, prop);
this.manager.addAxiom(this.ontology, axiom);
}
// And finally , to add a data-property to individuals :
public OWLDataProperty getDataProperty(String prop) {
return this.factory.getOWLDataProperty(":" + prop, this.pm);
}
public void addDataProperty(String propname, boolean propvalue,
OWLNamedIndividual inv) {
OWLAxiom axiom = this.factory.getOWLDataPropertyAssertionAxiom(
getDataProperty(propname), inv, propvalue);
this.manager.addAxiom(this.ontology, axiom);
}