I'm trying to implement integration using JMS as a transport and SOAP WebServices being interfaces for my applications to be integrated.
Is it required that the WSDL itself defines transport as JMS?
Can I leave it to be HTTP and move the configuration of the JMS queues elsewhere?
I'm considering Apache Camel as an alternative.
The JMS parts in the WSDL are only hints how to invoke the service. There might be somewhat tricky without the hints if you rely on some import tool generating skeleton code, without the hints though.
I have even used WSDLs with both HTTP and JMS transports defined in them, so that is also possible.
How you configure your queues is another matter, because it depends on which framework you use.
I can't see how Apache Camel should be an alternative to SOAP over JMS. Camel is an integration engine (actually able to do SOAP over JMS) but not a transport standard itself. As a small sidenote, I really recommend Camel to do integration tasks.
You might want to carefully think about your requirements for your integration needs. SOAP over JMS can be quite powerful, but also a bit complex to design with, since people tend to think about SOAP as a synchronous service definition and JMS is designed mostly for asynchronous communication, even though there is somewhat support for synchronous calls as well.
Related
I have an architectural question. I want a Java client to communicate with a Java EE server (Glassfish). I don't want to use remote EJB invocations and use GlassFish Application Client Container, I need something more lightweight. So I consider calls over HTTP.
RESTful seems to me the easiest way from the technical point of view. But I'm confused about architectural style. I mean, I'm NOT creating a system that is defined in terms of 'resources', but in terms of 'methods'. So JAX-WS may be appropriate, but I would prefer to transfer not only XML, but just raw data in HTTP message body.
Should I consider servlets or something else? What is the best practices for client-server communication?
raw data in http message body
What kind of raw data, like bytes encoded in base64? That doesn't really sound like the typical job for HTTP. Somewhere in between EJB and Webservices there are other solutions that may fit better and can be faster. For example messaging/serialization frameworks like Apache Thrift or Protocol Buffers.
Anyways, if you go the HTTP way:
Sometimes it's possible to model method-like endpoints as resources, but doesn't always work. If there are no resources, just call it a "Web API" and only keep RESTful concepts and best practices that make sense for you. Caching, nice URLs and leveraging HTTP status codes and header for example.
JAX-WS isn't limited to transferring XML. It it's based on WSDLs though, which you might not need. REST API are easier to handle and more flexible.
JAX-RS is a good choice to build any kind of non-WSDL Web APIs. It provides a clean API and a lot useful features, even if you only use it for simple GET/POST operations.
In my project I am using a wsdl provided by TIBCO to generate web service client classes. These clients are responsible to to consume TIBCO web services over SOAP/JMS.
I see that the designer has made a comment in design doc like this:
TIBCO jms bindings are proprietary, so standard tools liek JAX-WS , JAX-RPC cannot be used to generate clients. Hence Spring Web Services will be used to generate the clients.
What does this mean? The designed is no logner with the team. I have no way of asking him
Standard SOAP binding to JMS defines a set of JMS properties that can be then used by the toolkits like JAX-WS or JAX-RPC to send the SOAP over JMS. E.g. SOAPJMS_requestURI, SOAPJMS_soapAction, SOAPJMS_contentType, etc.
The developer has probably not followed all the requirements stated in the standard and e.g. already existing endpoint that produces the SOAP requests might not set all the required JMS properties when sending a JMS message, or it might require different set of JMS properties to be set for messages that it consumes.
Spring-WS is probably more flexible when it comes to such customizations and not so picky when processing received messages thus it was recommended by the developer.
At the time the TIBCO code was written, there was no standard for SOAP over JMS (A W3 recommendation for SOAP over JMS was released just over a year ago) and all SOAP over JMS bindings were proprietary.
All this really means is that some tools will not understand the bindings and you will need to configure them yourself manually. Other tools will understand the bindings and will automatically configure the bindings in the client. Try it with different frameworks and see how you go.
I'm learning how to develop with OSGi in recent days, but facing a lot of problems.
I don't know how to design my client-server system based OSGi with Equinox as framework. Should I use socket connections to implement this or use a distributed model?
I'm also confused whether I need to import some third party packages to support my programming on socket, jdbc, swing, etc, or there're existing packages offered by Equinox or other OSGi open source projects?
First time to ask questions here, can anybody help me?
just take a look at OSGi Remote services implementations (more details in OSGi spec):
Web services (Apache CXF: distributed OSGi) - http://cxf.apache.org/distributed-osgi.html
Eclipse Communication Framework - http://www.eclipse.org/ecf/
Cheers,
Dmytro
The HTTP model is probably the simplest to implement, as opposed to protocols based on low-level socket handling and binary protocols.
The first question I'd ask is what kind of information your clients and server need to exchange. If you can live with HTTP (and in many cases you can), you can just use servlets on the server-side, http client libraries on the client side and a RESTful communications model.
Servlets are easy to implement in OSGi using the HttpService, see for example http://www.osgilook.com/2009/09/08/osgi-http-service-registering-servlets-on-the-fly/
Working with sockets is not more or less complicated in OSGi than it is in 'plain' Java. You design your application in much the same way as you would normally, but gain the benefits of modularity and services by using OSGi.
You could, for instance, decouple connection acceptance and request handling by introducing something like a WorkerFactory, or maybe reuse services on both the client and the server; those are the things that OSGi is good at.
OSGi as a 'technology' (as far as that notion holds water) does not mandate any specific interaction method. The compendium specification mentions Remote Services (a.k.a. Distributed OSGi), but it also contains an HTTP service specification is Servlets are your thing.
In short, just pick the interaction solution that best matches your scenario, and let OSGi help you with the services and modularity.
I have a question around SOA.
Are SOAP and REST both considered approaches for implementing a service-oriented architecture?
I know that REST is a style, thus this leads me to this question.
Yes, they both can be considered approaches for implementing a SOA. I suppose you could say REST is a style, but then you'd have to say SOAP is one too. I would simply consider them different techniques to accomplish the same end. SOAP mimics a Remote Procedure Call and REST is inline with how the web (http) was designed.
When creating/adapting services to work in a SOA architecture the interfaces exposed can be whatever you desire as long as the consumers have the ability to process the response.
For the sake of giving a more concise answer, I will interpret REST as being a HTTP interface which can perform the CRUD operations, perhaps responding to requests with an XML or JSON object.
SOAP tends to lend itself to more complex operations on the service side, the libraries and involved XML's of SOAP introduces complexity to the system.
If all you require is the representation of resources which can be accessed through simple CRUD operations it is worth considering implementing a REST interface to reduce complexity, even if the service will run along side services with SOAP interfaces. All that would be required is the consumer of the service is able to deal with the RESTful style responses as well as acting as a SOAP client.
There would be arguments for consistency across the service to improve maintainability and ease of development, but this isn't a necessity and should only be included in the decision process.
When including a messaging bus into the design, heterogeneous services can be dealt with even more effectively by inserting standard transforms (XSLT, custom) into the process which can translate the response from services into a standard format understood by the system as a whole.
If you simply ask whether both of them can be implemented using Service Oriented Architecture - yes they do. They can even be used both at once in a single SOA-based project.
If you are asking whether SOAP or REST should be used - there is no answer unless you provided project specifications.
SOAP and REST are ways of building services.
SOAP is XML based and, in theory, supports more than just HTTP, and has standards for interface definition (WSDL), and things like security (WS_Security).
REST is a style for doing web services in a resource-oriented manner using a defined set of web operations (GET, POST, etc), but defines very little else.
However, SOA is about much more than just a bunch of services. Choosing REST or SOAP is the easy part.
What are the disadvantages of using SOAP services?
Quotes from this wikipedia article: SOAP
Because of the verbose XML format, SOAP can be considerably slower than competing middleware technologies such as CORBA. This may not be an issue when only small messages are sent.[7] To improve performance for the special case of XML with embedded binary objects, the Message Transmission Optimization Mechanism was introduced.
When relying on HTTP as a transport protocol and not using WS-Addressing or an ESB, the roles of the interacting parties are fixed. Only one party (the client) can use the services of the other. Developers must use polling instead of notification in these common cases.