Coexist soap 1.1 and soap 1.2 - soap

I have a web service developed with soap 1.1. Among my clients who use this web service, there is someone requires the use of soap 1.2. I thought about making required changes, but in this case I'll break the work of other customers who still using soap 1.1.
My question is: Is it possible to coexist soap 1.1 and soap 1.2 in the same application or do have to deploy two applications.

After some research I found that it is possible to deploy soap 1.1 and soap 1.2 in the same application. In fact, with jax-ws implementation simply properly configure the the sun-jaxws.xml file and the endpoints classes.
<endpoints xmlns="http://java.sun.com/xml/ns/jax-ws/ri/runtime"
version="2.0">
<endpoint name="Service11" implementation="mypackage.Service11Impl"
url-pattern="/Service/11" enable-mtom="true" wsdl="/wsdl/service.wsdl" />
<endpoint name="Service12" implementation="mypackage.Service12Impl"
url-pattern="/Service/12"
binding="http://java.sun.com/xml/ns/jaxws/2003/05/soap/bindings/HTTP/"
enable-mtom="true" wsdl="/wsdl/service.wsdl" />
#BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP11HTTP_MTOM_BINDING)
#WebService(...)
public class Service11Impl extends ParentService {
}
#BindingType(value = javax.xml.ws.soap.SOAPBinding.SOAP12HTTP_MTOM_BINDING)
#WebService(...)
public class Service112mpl extends ParentService {
}

Related

Wso2 API Manager : Soap Service | How to Default SoapAction

How to set default SoapAction value for a soap service configured on wso2 api managaer 2.1.0.
For Soap services we do not have option to edit swagger definition:
please advise how do i default the value of soap action, in our scenario it is not relevant. if there is way to remove from ui and set default value for all api call that would also work. thank you.
If it's SOAP 1.2 you can simply ignore Soap Action.
If it's SOAP 1.1, you can have a custom mediation sequence and set SOAPAction http header like this.
<sequence xmlns="http://ws.apache.org/ns/synapse" name="admin--sample">
<property name="SOAPAction" scope="transport" expression="YourSoapActionHere"/>
</sequence>
If you want to modify the UI, you'll have to tweak this file.
repository/deployment/server/jaggeryapps/store/site/themes/wso2/templates/api/swagger/swagger/swagger-ui{.min}.js

Expose RAML contract instead WADL in CXF

I am new in REST world, an in most of CXF examples that I saw there is an configuration to expose WADL in REST services when published.
Something like
Available RESTful services:
Endpoint address: http://localhost:8080/ouat-servicesImpl/api
WADL : http://localhost:8080/ouat-servicesImpl/api?_wadl
Then, when clicked
<application>
<grammars/>
<resources base="http://localhost:8080/ouat-servicesImpl/api">
<resource path="/topics">
<method name="POST">
<request>
<representation mediaType="application/json"/>
</request>
<response>
<representation mediaType="application/json"/>
</response>
</method>
</resource>
</resources>
</application>
I was learning RAML and its benefits in contract creation. Is there any way to expose RAML contract in this CXF "home" service page? Or am I mixing the concepts/ purpose of RAML and WADL? Actually I think both are ways to expose services contract, however in my opinion RAML is more complete
Assuming you package your CXF service as a WAR, here is how you can achieve your goal, based on a real project I'm working on:
Drop RAML and JSON files below the webroot folder: https://github.com/openanalytics/RPooli/tree/master/webapp/src/main/webapp/raml
Template baseUri so it can be injected at runtime: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/webapp/raml/api_v1.raml#L21
Declare .raml as if it's a JSP so injection can work: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/webapp/WEB-INF/web.xml#L70
Add the RAML mime-type: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/webapp/WEB-INF/web.xml#L76-L79
Add a filter to compute the dynamic part of the baseUri: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/java/eu/openanalytics/rpooli/web/BaseUriInjectionFilter.java
Wire it in web.xml: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/java/eu/openanalytics/rpooli/web/BaseUriInjectionFilter.java
Bonus point for:
Embedding the RAML API console: https://github.com/openanalytics/RPooli/tree/master/webapp/src/main/webapp/raml/ui
And redirecting to it from the web-app home page: https://github.com/openanalytics/RPooli/blob/master/webapp/src/main/webapp/index.html

Create a REST proxy for SOAP service in wso2 esb

We have a SOAP service that I want to proxy in WSO2 ESB. This is for POC that I am working on. I came across various documents and some explanation on forums but nothing concrete yet. I looked at API option but couldn't get anything to work. Whats the best way to do this? Can the transformation occur in esb itself or is the api the only option? Please advise.
You can better choose RESTAPI option.
Here is the documentation for that
What do you mean by couldn't get this working? This is not a big configuration, you need to define your proxy service such that you send the message (REST message) to the back end as a SOAP message. Here is a sample configuration.
<proxy name="StockQuoteProxy" transports="http https" startOnLoad="true">
<target>
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"
format="soap11"/>
</endpoint>
<outSequence>
<send/>
</outSequence>
</target>
</proxy>
You can call this proxy in REST manner and it will automatically send the message to the backend SOAP service.
you can do it with the sample axis2 client as below.
ant stockquote -Daddurl=http://localhost:8280/services/StockQuoteProxy -Drest=true

Cross domain REST/Jersey web services with CORS

I want to make Cross domain REST web services with CORS(Cross-Origin Resource Sharing). I am using Jersey Libraries for making services.
I need to know
What code/configuration changes i need to do from server side perspective?
How to invoke this services from HTML5/js.
Thanks
All the information for your server side configuration can be found at enable-cors.org.
There is no need to change any code clientside, but I would recommend checking the Browsers capability for CORS before using it. Testing code can be found, e.g., here.
I have chosen to solve this problem by providing the server CORS response at the Jersey container level. This might offer more convenience for some applications since it can apply for all responses from the container without modification to the resource handling code.
First one has to create a container response filter that will inject the appropriate header(s). For example for a container that indicates Access-Control-Allow-Origin:* for any response:
class CORSFilter implements ContainerResponseFilter {
#Override
public ContainerResponse filter(ContainerRequest request, ContainerResponse response) {
response.getHttpHeaders().add("Access-Control-Allow-Origin", "*");
return response;
}
}
Then the filter must be added be added to the Jersey response filter chain. This can be done through the resource config in use for the application.
...
DefaultResourceConfig rc = new ClasspathResourceConfig();
rc.getContainerResponseFilters().add(new CORSFilter());
// now create a simple lightweight server using this resource config.
HttpServer server = HttpServerFactory.create(uri,rc);
...
Steps which I used to enable CORS Filter in my Jersey based embedded Jetty application.
jetty-servlet version - 2.12
Added cors-filter dependency in pom
<dependency>
<groupId>com.thetransactioncompany</groupId>
<artifactId>cors-filter</artifactId>
<version>2.1.2</version>
</dependency>
Add the corsfilter to ServletContextHandler of your application.
ServletContextHandler context = new ServletContextHandler(ServletContextHandler.NO_SESSIONS);
context.addFilter(CORSFilter.class, "/*", EnumSet.of(DispatcherType.INCLUDE,DispatcherType.REQUEST));
server.setHandler(context);//set handle to your server

WCF Proxy Using Post Even Though WebGet Attribute is Specified (Only when called from another WCF service) - Causes 405 Error

I have a Restful WCF service sitting on another server configured with the WebGet attribute to respond to the HTTP Get method. I know the service works correctly because I can call the service directly through the browser and manually do a Get with Fiddler and receive a correct response.
I have an Asp.NET project on my local machine that is calling this service with the following code:
Proxy Interface 'IProductService':
using System.ServiceModel;
using System.ServiceModel.Web;
namespace Hugo.Infrastructure.Services.Products
{
[ServiceContract]
[XmlSerializerFormat]
public interface IProductService
{
[OperationContract(Name = "GetProductById")]
[WebGet(UriTemplate = "Products/Titles/{id}",
ResponseFormat = WebMessageFormat.Xml,
RequestFormat = WebMessageFormat.Xml,
BodyStyle = WebMessageBodyStyle.Bare)]
TitleDto GetTitleById(string id);
}
}
Implementation 'ProductService':
using System.ServiceModel;
namespace Hugo.Infrastructure.Services.Products
{
public class ProductService : ClientBase<IProductService>, IProductService
{
public TitleDto GetTitleById(string id)
{
return Channel.GetTitleById(id);
}
}
}
Related Web.config section:
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true">
<baseAddressPrefixFilters>
</baseAddressPrefixFilters>
</serviceHostingEnvironment>
...
<client>
<endpoint address="http://server/directory/product.svc" bindingConfiguration="ProductServiceBinding" binding="webHttpBinding" behaviorConfiguration="productService" contract="Project.Infrastructure.Services.Products.IProductService" name="ProductServiceRest" />
</client>
<behaviors>
...
<endpointBehaviors>
<behavior name="productService">
<webHttp />
</behavior>
...
</endpointBehaviors>
</behaviors>
</system.serviceModel>
This works fine when we call the method from a page within the project, however it errors out on this line return Channel.GetTitleById(id); when we call it from within a WCF service from the same project. The error we receive is an HTTP 405 'Method not allowed' error. When we look at the IIS logs on the remote server we see that the ProductService proxy is making an HTTP GET request when the method call is initiated from the page but it is making an HTTP POST request when the method is called from the WCF service. The POST method is not configured on the service, thus the 405 error.
Even when the page and the service are in the same folder and namespace we still receive the same error from the service. If we use a classic asmx soap service instead then a GET call is made and the service executes and responds correctly. If we manually do a get from the WCF service using the System.Net.WebRequest object, the service call succeeds.
Bottom line, the WCF client proxy tries to do a POST instead of a GET when used from within another WCF Rest service but works correctly when used from a page or pretty much anywhere else.
Help please!
This might work:
http://www.rgoarchitects.com/nblog/2008/09/28/AnotherWCFGotchaCallingAnotherServiceresourceWithinACall.aspx