I have a concern regarding handling big xml's over SOAP.
In Axis it is written that,
Axis is essentially Apache SOAP 3.0. It is a from-scratch rewrite, designed around a streaming model (using SAX internally rather than DOM). The intention is to create a more modular, more flexible, and higher-performing SOAP implementation (relative to Apache SOAP 2.0).
http://axis.apache.org/axis/faq.html
Can you tell me how cxf handles SOAPMessages internally. Does it use SAX rather than DOM. If not I think for BI XML's AXIS will be a better choice then..?
Secondly, I see that javax.xml.soap.SOAPPart implements Document, Node. Does it mean no matter what for a SOAP implementation DOM will always be created.
Thanks
At this point, there is almost nothing that Axis2 can do that CXF cannot do just as well or better. CXF also uses StAX internally for processing the incoming messages.
That said, you mention SOAPPart. Those are SAAJ things. If you drop town to using SAAJ model for processing, then streaming is broken as the SAAJ model requires the entire thing to be pulled into memory. For the most part CXF, tries hard to avoid SAAJ unless it's required (JAX-WS handlers require it, WS-Security currently requires it).
Related
I really can't get the difference between REST and POX web services. I mean, couldn't POX be considered as a REST web service with XML message definitions?
It depends on what your "Plain Old XML" contains.
The thing is, POX used to be compared with SOAP. SOAP is a very specific way to do XML over (mostly) HTTP and people were already doing "plain old XML" over HTTP. SOAP got a lot of criticism because it complicated the things people were already doing with POX. But I won't go into that, what I'm trying to say is that people used POX to do RPC.
REST isn't RPC. In REST, the XML is a representation of a resource, not a message definition as in RPC. There is also a very important REST constraint that people seem to forget or ignore that imposes constraints on the returned XML: the hypermedia constraint or HATEOAS.
If you want to find out more about how POX fits in REST, I recommend reading this article: Richardson Maturity Model, steps toward the glory of REST.
while going through the differences between SOAP and REST there was onepoint that
SOAP is a XML-based message protocol, while REST is an architectural style
what I am not able to understand is that what does it mean by REST is an architectural style???
Please help on this.
THanks,
Vineet
This is actually quite a common issue, one that I had to face my self as well.
There are two Web Services architecture structures: Representational state transfer (REST) and Remote Procedure Call (RPC). The wikipedia definition of archtecure structure is:
"The term software architecture intuitively denotes the high level structures of a software system. It can be defined as the set of structures needed to reason about the software system, which comprise the software elements, the relations between them, and the properties of both elements and relations."
Its hard to further define what it means. You either get it or you don't.
The basic difference between them is that REST uses already available technologies that the web is built on, while RPC adds additional layer of abstraction to define communication. In general REST are simple, lightweight WS but without formal communication specification, while RPC is heavy, bit more complex but with formal communication specification.
Now, for examples of implementations (which are basically communication protocols) of those architectures:
RESTful - obviously uses REST architecture
SOAP - uses RPC architecture
Because it is based on two architectural styles
1. Layered, code-on-demand, client-cached-stateless server (itself a composition)
2. Uniform interface
The term software architecture denotes the set of practices used to select, define or design
In REST there is much more flexibility in choosing the mode of data transfer and also the way we implement it unlike SOAP where the data has to be sent in XML format only.
If we are using RESTful the mode of transfer of data can be JSON, XML, Simple Text etc.
okay this might be a pretty lame and basic question but its stuck in my head since i never had chance to work on web-services.
We can get the same "text bases" response(xml, json etc) from our server by very basic/simple implementations (lets say servlet) then why do someone has to develop a web-service.
What is the exception thing a web-service gives over simple http response?
At a basic level, you are quite correct, from a low level point of view, it's just text (XML) on a socket.
For simple web services, a servlet is adequate (I'm writing one of these as we speak).
When talking about something like SOAP and WSS-* web services, however, there is a lot of boiler plate processing and features available from the standards that web service toolkits expose as higher level transactions.
A simple example is data marshaling. If you treat it purely as XML, then your service basically gets to process the XML by hand -- parse it, evaluate it, populate your internal models, etc.
Contrast this to something like this from Java EE:
#WebService
public Person getPerson(String personId) {
Person p;
...
return p;
}
The web service stack will convert your Person object in to a SOAP compliant XML blob. It will also produce a WSDL that you can use to create client code (on many platforms: .NET, PHP, etc.) to make the web service code.
In the end, your client and server have only a few lines of code, while the frameworks do all of the grunt work parsing, marshaling, and publishing for you.
So, the value of the WS stack is that it handles much of the bureaucracy of writing WSS compliant web services.
It's no panacea, but for many modern implementations, SOAP <-> SOAP remote processing can be a, mostly, cross platform, drag and drop affair.
It depends. If your web service needs to answer a simple yes/no question like "does this username exist?", then return yes, no, 0, 1, etc may be enough. If you have one that returns all the faculty attributes, XML or JSON may be appropriate because of the structured nature. It's a little less prone to parsing errors than trying to parse plain text.
I have been playing around with Apache CXF, in particular the various data bindings it supports: JAXB (the default), MTOM, Aegis and XMLBeans. Since all of these are supported, I suppose each has its merits. I came up with these:
Obviously, MTOM is to be preferred where large attachments are involved.
JAXB depends on annotations, so it is less suited when modification of classes is restricted.
Aegis has no wsdl2java tool, so it is less suited for "contract-first" development, i.e. start with a WSDL and generate your Java code from that.
It appears that Aegis provides slightly more control over the mapping between Java classes and XML through its declarative syntax in Class.aegis.xml files. On the other hand, I couldn't devise of any scenarios where JAXB did not do the trick.
I found this question juxtaposing JAXB and XMLBeans, but it doesn't give a comprehensive overview:
JAXB vs Apache XMLBeans
Besides these naive, a priori considerations, do you have any blood-and-guts experiences that would support the use of any other binding besides JAXB? I'm asking from a CXF point of view, but if any other options come to mind (e.g. Castor) please don't hesitate to elaborate.
If starting from scratch to create a WSDL first web service, then I definitely would recommend sticking with JAXB 95% of the time (maybe even higher). It's definitely the best tested databinding in CXF and performs quite well.
Where the other databindings come in are usually for one of two cases:
1) Java first use cases where you have something already written in Java that you want to expose as a web service with little to no modifications to the code. Aegis has it's strengths here as it's designed to be able to handle a wider range of things than JAXB. However, if you CAN modify the code, adding JAXB annotations usually isn't that hard. If you have mostly normal "beans", it's not a big deal.
2) Existing applications that use a particular mapping. If you have exising applications that are expecting XMLBeans beans (or SDO beans if using 2.3-SNAPSHOT of CXF, or JiBX beans if following the GSoC project), then using the other databindings could help by removing any needed mappings from JAXB to those object models.
Hope that helps a little.
Remember that JAXB is a specification so there are multiple implementations: Metro (Reference Implementation, MOXy (I'm the tech lead), etc.
JAXB can be used starting from Java classes or XML schema. If you have classes that cannot be modified individual JAXB implmentations offer extensions to handle that. See MOXy's externalizable metadata:
http://wiki.eclipse.org/EclipseLink/Examples/MOXy/EclipseLink-OXM.XML
JAXB was designed to work with MTOM attachments see the attachment marshaller/unmarshaller.
MOXy has XPath based mappings which offers full control of your object-to-XML binding see:
http://bdoughan.blogspot.com/2010/07/xpath-based-mapping.html
parse google geocode with xstream
I have a basic asp.net webservice that returns a simple response.
To make it ucore compliant I need to apply an XSLT.
Is there a way to apply an XSLT to my response?
I'm aware the receiver can apply it on their end, but in this scenario I need to apply it on my end.
Thanks!
See Custom Message Formatters.
Ignore ASMX web services. They have very little extensibility and are now considered to be "legacy technology" by Microsoft.
Whether you're talking about legacy ASMX or the current WCF web services, you're talking about controlling the serialized XML on output. Both the ASMX and WCF handlers by default will fire the serialization routines for the underlying objects used in their respective web service methods.
You could do it if you want to work outside the construct of serialized XML. Your method could return a string which is nothing more than the output of your method. You would need to:
Go through the logic of building your resultant object
Serialize the object to XML -- as a string
Run an XSL transformation on the XML to an output stream
Return the output stream's contents from your method
This is an extremely lousy hack, though.
EDIT: per John's reference, focus on solving this through control of the output XML. If you're using legacy ASMX, this is basic XML serialization. If you're using WCF, there are greater formatting options available.