I have a simple question about deploying web services. Currently I have two endPoints, see below:
Endpoint.publish("http://localhost:8000/eCalcWS/eCalc", new eCalc());
Endpoint.publish("http://localhost:8001/eCalcWS/eCalc_service", new eCalc_service());
Is it possible to have two web services on the same address? How would I do that?
Unfortunately you can not the way you want.
The design is that each endpoint is associated with web service implementor.
From spec:
The Endpoint class can be used to create and publish Web service
endpoints. An endpoint consists of an object that acts as the Web
service implementation (called here implementor) plus some
configuration information, e.g. a Binding
and on publish (my emphasis):
publish(String address, Object implementor)
Creates and publishes an Endpoint for the given implementor. The binding is chosen by
default based on the URL scheme of the provided address (which must be
a URL). If a suitable binding if found, the endpoint is created then
published as if the Endpoint.publish(String address) method had been
called. The created Endpoint is then returned as the value of the
method.
I remember I also encounter this problem quite a while back which is really bad as I needed to associate 2-3 different implementations with different URLs and it was impossible (got address already bind error).
The way I got around this if I recall was to create my own dispatcher.
I published an endpoint that accepted web service requests for multiple endpoints and dispatched the request to the corresponding implementation. I worked directly on the SOAP message.
But it was possible for me since the xml messages were really simple and quite few.
For you I would recommend to publish in different endpoints if your web service implementations are non-trivial and have complicated messages and expect a lot of clients as the endpoint really just deploys a simple http server under the hood.
Related
On most of the resources on google, I see one of the major advantage of graphql is said to be its ability to be as aggregator service but I did not find any concrete example how it is different from other http endpoints(or Rest endpoints) ?
My understanding is that in case of GraphQL, there will be single http endpoint for everything. Then graphql server will determine which particular
data fetcher will be called. That is provided in very configurable way.
But in case of other MVC based architecture or rest based architecture, end points are separate for each request and then the flow start.
So in a way graphql provides the single entry point(or we can say address) for each request then graphql take care of further branching, but in other above
mentioned architecture there are separate addresses(or endpoints) for resources/request. Is it because of this reason we say graphql can work as aggregator service or is it something else ?
The GraphQL's main advantage is to provide to the client ability to query everything (objects) it needed and display it to user without discussing/creating specification for every request/response in the application. And in some cases clients need different responses for the same request (eg views might look differently for web and mobile clients).
I believe you can create multiple GraphQL endpoint in your application based on context of your domain, but it might be misleading in most cases.
I'm starting to choose a way to create my webservice, so i found 2 ways to do it:
1) Using the package javax.jws, with annotation #WebService:
#WebService(...)
public class MyServiceImpl {
2) The other way is using javax.ws, with annotation #Path:
#Path("/MyService")
public class MyServiceImpl
In my understand using the second solution is more simple, because when i need to create the Client i just need make a HTTP call (GET/POST). Using the first solution i need create a WSDL client, more complex solution.
So, I would like to know which is the advantage in use FIRST SOLUTION.
The SOAP/WSDL style is useful when a formal contract must be established to describe the interface that the web service offers.The Web Services Description Language (WSDL) describes the details such as messages, operations, bindings, and location of the web service.
Also the SOAP/WSDL style is useful when the application architecture needs to handle asynchronous processing and invocation (e.g. using JAX-WS the assynchronous clients can be created).
The disadvantages of SOAP/WSDL style are
its complexity: tools are required to create a client
heavier on Bandwidth : SOAP requires a heavy XML wrapper arround each request or response
complicated security rules
The advantages of REST style are
simplicity: REST client can be accessed from any browser (however, this is only true for GET method. Data creation request requires also the XML wrapper).
lighter on Bandwidth : data on the wire are usually bare xml elements (not wrapped within the <Envelope><Body> tags).
REST application security rules can be setup using the http standards: the administrator (or firewall) can discern the intent of each message by analyzing the HTTP command used in the request.
For example, a GET request can always be considered safe because it can't, by definition, modify any data.
The disadvantage of REST style is that it still doesn't cover all business requirements
There is no common standard accepted yet for the formal REST service description
REST requests (especially GET method) are not suitable for large amount of data
REST doesn't cover all web services standards, like Transactions, Security, Addressing, Trust, Coordination,
In my company we are starting to use web services. My plan is to provide access to services via 2 protocols, http and jms. Any external access (clients outside company network) to services will be typically via http and json through a restful URL, but internally if the service needs to invoke another service, it will do it via jms, mainly to decouple the service from each other.
My question is following
Can camel provide abstraction so that i can write my service code without http, json and jms dependencies? I would like camel to handle http to java, json to java and jms to java conversion through some mediation and invocation of my service should be simply through a java method with accepts a java object as a request. Keep in mind that although http is synchronous model, jms would have to simulate request-response. If yes, can you please point me towards an example which demonstrates this setting.
Likewisely, i would like camel to convert the response from my service, which would be a java object, into json and return the response back to the client.
Lastly, how can i scale in this model. For JMS, it is easy to startup multiple instances and have them listen to a queue. How can i leverage same instances to loadbalance across http interfaces? I would like services to have location transparency, hence, they should not have to care about invoking "jms" specific cluster vs "http" specific cluster?
I think you can achieve all of this with Camel.
Marshalling between different object representations is handled through data formats. You can call POJOs from within Camel routes that can encapsulate your services.
See data formats.
Camel comes with clustering and load-balancing support. But if you only have HTTP type endpoints to load balance, then my personal opinion is that you should use a more http-centric approach, like using httpd as a reverse proxy/load balancer.
I have a scenario where i am hosting different java Rest Services on different Tomcat instances (different machines). These projects running on the tomcats do not have any UI. For simplicity's sake, lets assume that the user will directly enter some URL in the browser (or curl) to avail these services. Now I need this service to be able to talk to (call functions) the services available in the other tomcat instance.
For eg. If TomcatInstance1 gets the call, and all this does is act as a 'router' to the different services, i want it to be able to place the Rest call for the other 'service' available on, say, TomcatInstance2. Is this possible?. If so, how to achieve that? (Tried searching for similar questions on SO, couldnt find any). Are there any online reference for the same?
PS: Hosting the services in the same Tomcat Instance is against the requirement that I'm having.
That is completely possible. You can use (for example) Jersey-client (http://jersey.java.net/) to make the queries to the other RESTful web services in the other Tomcat instances. Only need to define the correct URIs of the end points and query them according the the API exposed and call it (like you were a client from a browser, or curl).
See here a nice example of using Jersey-client to do that: http://www.mkyong.com/webservices/jax-rs/restful-java-client-with-jersey-client/
I would suggest Spring Restful api ( http://static.springsource.org/spring/docs/3.0.0.M3/reference/html/ch18s02.html , http://www.mkyong.com/spring-mvc/spring-3-rest-hello-world-example/ ).
As #emgsilva mentioned the only thing you need to do is to point correct uris between each other.
The beauty of spring restful api is it is simple to use and you don't deal with any serialization - deserialization.
I have a web service that I've been working on and it's wokrring fine so far by creating a port in the client and then calling a method on the port. However, I've just been told that a couple of the clients who will be using the web service plan on sending it raw xml based based off of the schemas used by the web service and I was wondering if this was possible. I think I may need to use the provider interface to make the web service capable of handling this type of request but I'm not sure.
I've done a search of the questions here but none of them seemed to answer my question and what I find on the net after googling says that it's possible but they then proceed with examples that work the exact same way as what I already have.
Thanks in advance for any help you can provide.
plan on sending it raw xml based based off of the schemas used by the web service
So you mean they plan on sending you XML messages based on the schema published in your web service's WSDL?
This is exactly what SOAP is and how SOAP/XML web services work.
Assuming the clients are sending your properly formed messages, these client's requests are identical to requests from any other client and you shouldn't have to do anything special for them.
I think you want to send and receive XMLs across
here is 1 way
http://java.dzone.com/articles/implementing-jax-ws-web