We Keep Coding

Microserivce Using Spring Boot to Consume SOAP

I need to create a REST service that first consumes SOAP. What would the best way to go about this?
I would like to use Spring Boot to create a microservice, but I have a few questions for those with experience:
What other architectures or technologies should I look into using
(with spring boot)?
Is there a standard technology stack for this?
Are there pitfalls I should be aware of?

What other architectures or technologies should I look into using (with spring boot)?
My answer is if you just want to simply provide RESTful service
without Spring Cloud, then I think you can refer to following 2
tutorials on Spring official website to achieve this:
Building a RESTful Web Service
Consuming a SOAP web service
Is there a standard technology stack for this?
Currently, I will suggest you to use Spring Boot as your first choice. Because these are rich resources on the web and it does reduces much effort in development.
Are there pitfalls I should be aware of?
If you finally choose Spring Boot, please be familiar to its components, you can start from Guides to realize how it works. Or you may mix up Spring Boot with tradition Spring framework.

There are similar cases in our project and we did it with spring components. As far as i understood, you want to open a REST endpoint which most probably accepts json object and you want to make a soap web service request within that request then you want to return a response containing information from the soap response. To make a soap request, you can use spring web services - WebServiceTemplate. It will marshall your object to xml and make soap request for you. Of course you can use some other web service frameworks like apache cxf which may best fit for some special cases, but i would first try to use a framework which is from spring family while using Spring. You should set timeout values on webservicetemplate object to not wait too long if the external system is not working well or you have some problems with the network. Because it directly affects your systems performance. Also here, i suggest you to implement circuit breaker pattern to make your system more robust. You should always isolate your systems performance from other systems that you integrate and in this scenario you can do this by doing the things explained above.

As per my knowledge , you should use Spring boot application with Maven build.
In order to send a REST call to SOAP web service and get back a JSON Response ,you need to follow all of this steps in order :
Business Logic : Mapping the JSON fields such as headers, query-param , body variables to XML Request mandatory fields (either using pojo classes or object-mapper) Reason : Since the SOAP end point will only accept XML Request.
Service Broker Logic : Import "org.springframework.web.client.RestTemplate" and use
**ResponseEntity<String> responseEntity=RestTemplate.exchange(endPointURL, HttpMethod.GET/POST/PUT/DELETE, HttpEntity/headers, uriVariables)**
**endpointURL** -- SOAP End point URL ,that the REST service has to consume.
**HTTPMethod** -- Method Type such as GET ,PUT ,POST ,DELETE etc.
**HTTPEntity** -- Soap requires for mandatory sender/headers/{a}.Make sure that you set your header name and value as key-Valye pair in HTTP headers.
**uriVariables** -- (Object... urivariables) such as String.class ,Integer.class
You should also put the **connectTimeout** ,**isSSLDisabled**,**responseCached** elements while generating request to restTemplate.
responseEntity.getBody() is the XML response after un-marshalling.It can be extracted by using mapper.
XML_BaseResponse response=mapper.readValue(responseEntity.getBody(), XML_BaseResponse.class);
Business Logic : Extract necessary field from XML_BaseResponse and using setter's or getter's functions,set the mandatory fields in the response.
baseResponse.setName(xml_baseResponse.getPersonsName());
baseResponse.setAddress(xml_baseResponse.getAddress());
baseResponse.setCity(xml_baseResponse.getcityName());

Camel Processor for an endpoint

I am experimenting with Camel and finding it a convenient tool for endpoint integration. I've set up the following experimental application:
The first endpoint is a simple http-get request (using curl on the command line). This interfaces with a central switch using Jetty (this is the Camel-based app). This does some elementary tinkering and passes the request to another endpoint (a Thrift server) which handles the request. Its reponse is then routed back to the command-line client. The set up is therefore a kind of tier-3 over-engineered Hello-world architecture.
My routes typically takes this form:
from("jetty:http://localhost:8080/hello").process(new DummyProcessor()).process(new HelloProcessor());
My question is as follows:
Given that the HelloProcessor sends a Thrift message to another endpoint to process, shouldn't this rather be a Component? Is it good (acceptable) practise to use a Processor for such a task? Furthermore, what are the advantages for writing a component if it is indeed acceptable.

There are not really any benefits in writing a component if you are going to use it in one or a few routes.
If you intend to use this processor in multiple routes in the future, and you need a way to configure it by some parameters - then you typically write your own component. It also perhaps makes the route more readable. A component is also an easy artifact to share between different Camel applications and projects.
from("file:///var/files/inbox").to("http://www.example.com/");
vs
from("file:///var/files/inbox").process(sendHttpToExampleDotComProcessor); // or whatever
If it's a one time use - don't overcomplicate.

Camel - Integrating with Existing Application

I currently work on a trading application that does not use camel.
It essentially takes in trades, does some processing and sends the details to an external system.
We now have a need to integrate with 3 new systems uusing FTP for 2 systems and JMS for 1 system.
I would like to use Camel in my application for these integrations. I have read a good chunk of camel in action but I was unclear on how we could kick off our camel routes
Essentially, we dont want to modify too drastically any part of the existing application as its working well in production.
In the existing application, we generate a Trade Value Object and its from this object that that I want to kick off our camel integration.
I dont have a database table or jms queue where I can kick off the route from.
I had a quick look at the Chapter on Bean routing and remoting in the Camel in Action book but I wanted to get peoples advise first before proceeding with any steps.
What would be the best approach for this integration?
Thanks
Damien

You can use Camel's POJO Producing feature that allows you to send a message to a camel endpoint from the java bean. If you have no need in JMS or DB you can use "direct:" or "seda:" or "vm:" endpoint as <from> part of your route.

Pojo producing as Konstantin V. Salikhov stated. However, you need to be sure you have a spring application and are scanning your beans with spring or wire them.
"If a bean is defined in Spring XML or scanned using the Spring component scanning mechanism and a is used or a CamelBeanPostProcessor then we process a number of Camel annotations to do various things such as injecting resources or producing, consuming or routing messages."
If this approach will add too much changes in your application, you could use a ProducerTemplate and just invoke a direct endpoint. (Or SEDA for that matter).
The choice of protocol here might be important. The direct protocol is a safe choice, since the overhead is simply a method call. Also, exceptions will propagate well through direct endpoints, as will transactions. As SEDA endpoints is asynchronous (like JMS) but does not feature persistence, there is a slight chance of loosing in flight data in case of a crash. This might or might not be an issue. However, with high load, the SEDA protocol stages better and give your application better resistance for load peaks.

Is it possible to consume an EJB 3 Web Service form a Java client without first generating client stubs/proxies?

In most tutorials that I have seen so far people are using wsconsume or something like that to create classes that clients can use to access an EJB 3 Web Service.
Is this the only possible option? As my EJB's interface is annotated with WebMethod, WebParam, etc. isn't it possible to create a dynamic proxy or use runtime bytecode enhancement to create the proxies, etc. on the fly? E.g.:
MyWebService webService = WebServiceEnhance.getWebService(MyWebService.class);
webService.webMethod("foo");
A link to good reference material is also highly appreciated.

One way is to deal with pure XML request/response. You can trap sample request/response for the web service you want to consume using either SoapUI or Fiddler and then use these samples as templates within your client.

clarification on the concept of "web service"

Im a little confused on the varying definitions and implementations of web services available as implementations. Need some clarification please.
Ones I have used till now:
If a vendor gives me a specific format of XML that I can send populated with data to request and I make a simple HTTP POST over the internet passing in the XML String as the payload, is this a web service call ? If so, is there a specific name to it, this kind of web service ? Because obviously, it does not use anything like Axis, WSDL or SOAP to establish this connection.
A variant of this is If the vendor gives me an XSD, I use JAXB to make a java class out of it and pass in the serialized version of the object, which eventually works out to be the same as option 1.
RESTful web service: Vendor gives me a URL like http://restfulservice/products and I can make HTTP Requests to the URL and depending on what HTTP verb I use, the appropropriate action is called and the response sent over the wire.
Ones I have only read about\ have a vague idea about
SOAP. How does this work?.. Ive read the W3Schools tutorial and I undertsand that there is a very specific form of XML that is standardized according to W3C standards that we use to pass the same kind of messages as we did in option 1. But how does this work in real life? Vendor sends me what? Do I generate classes? Do I serialize some objects and http post them over to an address? Or do the generated objects themselves have connection methods that will do them for me?
What about WSDL? When does a vendor send me WSDL and what do I do with it ? I guess I can generate classes from it. If yes, then what do I do with the generated classes ?
When do I need that axis jar to generate classes from something that the vendor sends ?
As you can see, I have some clear and other mostly vague ideas about the different kinds of web services available. would help if someone ould clarify and\or point to more real-world resources. I've looked a little bit into Java Web Services on the internet and the numerous four letter acronyms that get thrown at me make me dizzy.
Thanks

If a vendor gives me a specific format
of XML that I can send populated with
data to request and I make a simple
HTTP POST over the internet passing in
the XML String as the payload, is this
a web service call ? If so, is there a
specific name to it, this kind of web
service ?
This is still a web service, yes. It doesn't have an "official" name, I usually refer to it as XML-over-HTTP, mainly because I can't think of a better name.
SOAP. How does this work?.. Ive read
the W3Schools tutorial and I
undertsand that there is a very
specific form of XML that is
standardized according to W3C
standards that we use to pass the same
kind of messages as we did in option 1
SOAP provides a standard wrapper layer around the sort of messages you were sending in (1). This wrapper provides information such as an indication as to which operation you are invoking. It can also provide security services, transaction information, and so on. It's a pretty thin layer, usually.
What about WSDL? When does a vendor
send me WSDL and what do I do with it
? I guess I can generate classes from
it. If yes, then what do I do with the
generated classes ?
Again, WSDL is a pretty thin layer, this time around an XML Schema. It defines the operations that SOAP messages will invoke at runtime, as well as the Schema types of the requests and responses. Its a way of formalising the XML document exchange interface.
Say, for example, you had an XML Schema, and have a web service as you described
Using JAXB to generate java source from the schema
Send XML documents conforming to that schema over HTTP to the web service
With WSDL and SOAP, you would extend this a bit :
Write a thin WSDL wrapper around the XML Schema, formalising which operations are available.
Use a WSDL import tool to generate client/server stubs for that WSDL/Schema. In Java, this often incorporates JAXB.
Use a SOAP client/server to invoke the web service
As you can see, it's essentially the same process. The difference is that SOAP/WSDL provides additional information and context to the tools, allowing those tools to do more of the work for you. It's not hugely different, though.

If you get a WSDL document from somewhere, all you really need to know is that it defines a service interface. You run it through your favourite language's binding generator to make some code that you can use to call the service. Typically that means you'll be talking over the wire to the service using SOAP messages over HTTP. SOAP's just a wrapper round sending pretty arbitrary XML messages.
Axis is a library for doing this stuff in Java (both client and server side). I suspect that there are better implementations in other libraries.