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.
Related
I'm developing a SOAP WebService (designed to be Document Literal Wrapped). Sinking in web, I'm seeing some methods that have as response the following structure: complex type named [function_name + "Response"] followed by complex type [function_name + "Result"]
Is there any reason (standard reason or good practice) why is done in that way? (Specially the "Result" complex type).
It is a good practice. Since soap is of XML type, how will you differentiate between request xml and response xml?
It helps the developer to write the code based on request/response.
Example: marshaling and unmarshaling.
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).
I have a requirement in my project where I will have to built a webservice. This webservice will do the following things:
Accept XML format data
Return XML format data
The XML input data will have an element will have login information and another element data which needs processing.
Now I am looking for a design pattern where in I can make the webservice code look nice neat and clean. Because the webservice has to do plenty of things like.
First Parse the xml
Authenticate the request by checking username and password
Create objects from the data and then save the data to database
Prepare and xml which will be returned to the client.
So I have around 4 major steps which will definately make the code look ugly if I write whole thing in .asmx.cs file.
If anyone can suggest any design pattern to suit this so that the code is easy to maintain in near future.
As this module is to be integrated in my existing project hence there are some restrictions, like I cant use some 3rd party module or dll.
So I was looking for something like Single Responsibilty principle, Chain of Responsibility or Command or Decorator Patterns or anyother oop concept that fits.
I have searched but havent understood which way to start.
Thanks.
M.
I wouldn't write any of that from scratch. Use ServiceStack or MS MVC 4 for the webservice host. Rely upon them to do the conversion from XML to/from your objects. Both of those frameworks include authentication features. Start by reading their tutorials. It sounds to me like you have no experience with ORMs or micro ORMs or the various database options. I'd read a lot of tutorials on those as well.
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.
There are four "styles" of service in Axis.
RPC services use the SOAP RPC conventions, and also the SOAP "section 5" encoding.
Document services do not use any encoding (so in particular, you won't see multiref object serialization or SOAP-style arrays on the wire) but DO still do XML<->Java databinding.
Wrapped services are just like document services, except that rather than binding the entire SOAP body into one big structure, they "unwrap" it into individual parameters.
Message services receive and return arbitrary XML in the SOAP Envelope without any type mapping / data binding. If you want to work with the raw XML of the incoming and outgoing SOAP Envelopes, write a message service.
So, if I use anything else except the first option(SOAP RPC Section 5), how does this impact interoperability? If someone says they want a SOAP service (including WSDL), does this mean that SOAP RPC conventions are expected? Can the other three styles still be used when the other end is not implemented with Axis?
I found an interesting article that compares five different styles of WSDL.
It seems that the first two Axis styles (RPC and document) are "officially" supported by WSDL, and the third one (wrapped) could be the "a pattern which is commonly called the document/literal wrapped pattern", which also seems to work.