What's the best practices for implementing business logic in a web-application that uses a Websocket connection? specifically, how to use a Java websocket endpoint effectively to implement services and functionalities of the system?
Does the websocket endpoint replace Java web-services (JAX-RS) functionality entirely?
WebSocket is not a replacement for JAX-RS.
Both technologies have their usecases; if I were you, I would do my research before asking questions like this one.
The first question is about the business logic - and that always depends. You can adapt in some way MVC patter when dealing with JAX-RS, since there is a tight connection between Http Request and Response and you can even use some templating engine to process your output (Jersey - JAX-RS RI - contains pre-built support for this scenario). WebSocket is very different in terms of data processing, there is one "persistent" TCP connection which you can use to transmit messages from/to either side, which usually requires different programming model and typical usecase would include sending/receiving short status update messages to some interactive front-end (javascript) application.
Related
I know RESTful WS is an architecture all together, which is a new way of implementing Web Services over old fashioned JAX-RPC's.
In RESTful, we use #GET, #POST, etc to manage calls/develop resources. Same can be achieved using HTTP programming (both are stateless too).
But what are other core main uses or need for bringing/implementing RESTful? As everything we do in it, can be done using HTTP programming (in which we use same methods)?
The question is comparing different things. HTTP is a protocol, while REST is an architectural style. This is like asking what a house does that a brick doesn't. It doesn't make sense. HTTP can be a building block of a REST application.
REST is not about HTTP or any particular protocol. REST is about applying the successful design decisions of the Web itself to software development. The problem is terminology. 99.9% of the so called REST applications around the internet aren't really RESTful, because REST became a buzzword to refer to any HTTP API that isn't SOAP. Some REST advocates gave up on fighting for the proper usage of the term and now refer to REST applications as Hypermedia.
Like the Web, REST is intended for software development in the scale of decades. REST makes it easier to evolve your application without breaking clients. Think about how today you can still access websites that were created decades ago, and almost everything still works fine. If you're creating software that has long-term objectives in the scale of several years, then maybe REST is adequate for you. If that's not what you really need, then getting REST right is not important. Just use whatever works for you, and at this point I think nobody cares anymore if you call it REST.
The question is not "REST versus HTTP-Programing". REST is a higher concept on how to to create distributed web applications. HTTP is a concrete technology . REST defines some constraints which are considered as good practice.
HTTP is just a technology which is well suited to implement REST-Style services:
Addressability => in HTTP every resource can be addressed through a unique identifier (URI)
multiple Representations => every resource can have multiple representations (JSON, XML) - a HTTP-Request for instance can 'ask' for the right representation (via headers)
Common Interface => Instead of creating an application specific interface (Methodnames in SOAP) HTTP already provides an Interface: GET, PUT, POST, DELETE ...)
Stateless => HTTP-Requests are stateless by design
Hypermedia => The application state (client) is driven by examining the links contained in the representations
HTTP is a transfer protocol.
RESTful is a group of principles.
Basically a RESTful web service is a particular HTTP application that follow the following principles:
client server
stateless
cacheable
layered
I am planning to design such an architecture for my website as shown in picture above. I am building a core platform in Java that do the communication with DB and other high processing tasks and modules can hook up with the core by means of defined interfaces.
Modules could be anything like, front-end website, email box, admin consoles etc. and could be built on any technology like PHP, Java, ruby on rails etc.
Now tell me which communication protocol should I use for communication between modules and core. Protocol must be something that majority of languages understand and can be process easily in both way communication.
And if somebody find any flaws with such an architecture then kindly suggest a better one that provide great extensibility and flexibility.
I would use HTTP, exposing a REST API on the Core, such as Thilo suggested.
The complexity lies on the trade-offs between RPC (procedural model) of traditional webservices, and the Resource Model, which fits better when using http requests (verbs GET, POST, PUT and DELETE on URI's, complemented with some headers and a body).
Yet, this makes a soft, easy to maitain and portable ditribution. Every single client module may be built on a whole different technology, which allows you to use "the best tool for the job".
Not to mention HTTP advantages for caching, rewriting, load-balancing, ssl, etc.
So basically this is a SOA-like architekture. JavaEE and EJB (3+) or the Spring frameworks come to mind immediately.
The components (your "modules") are usually coupled via SOAP services with an optional Enterprise Service Bus (ESB) between frontend, backend and the composite services.
Whether this is a good match for your case or simply oversized... noone but you can say...
Does the webservice adaptor's function is let different webservice(eg,http/jms) can call each other?Does it like a proxy such as transform soap/http webservice to soap/jms webservice?
enter link description here
In the picture there exist three webservice,webservice-1 and webservice-1 are published by third part,adaptor-A and adaptor-B are used to call them,webservice-3 is published by adaptor-c.first,when someone call webservice-3,the adaptor-c intercept the soap request and send it to esb ,the esb have a broadcast router and the router send it to adaptor-A & adaptor-B,adaptor-A & adaptor-B then analyse the message and call webservice-1&webservice-2.after that adaptor-A & adaptor-B send webservice response to esb,esb also have a aggregator in it,then aggregator assemble these two response and send it to adaptor-c,At last,adaptor-c send the final result to webservice-3 user!
I want to if this flow is feasible?if feasible,how to design the adaptor-A and adaptor-B and adaptor-c?
yes, this is well suited scenario for an ESB. When your adapters don't implement a special business logic and are only responsible for "speaking" the protocol expected by the Web service, you can probably connect the services directly to the ESB. This kind of "protocol virtualization" is basically provided by all kinds of ESBs, even plain Web service stacks like Axis2 or CXF can deal with a large set of transport protocols.
Regarding the business logic there are different possibilities. For simple scenarios you can consider using a EIP-aware framework like Apache Camel and chain Enterprise Integration Patters (EIP) [Hohpe et al] to achieve the desired integration. For more complex scenarios you can consider using BPEL (Business Process Execution Language). BPEL is descriptive parallel programming language with focus on orchestrating Web services in a transactional, long-running fashion. BPEL can be executed e.g. by Apache ODE.
What is the best way to provide an asynchronous service interface to multi-platform (primarily java and .net) clients? The backend service is implemented in java.
We are looking at asynchronous web service and message queues, but apparently cross platform asynchronous web service* is not supported yet in java (as far as I know) and for message queues, I was not sure which codec/protocol would be best.
*:Cross platform asynchronous web services can be described in WSDL 2.0, but not in WSDL 1.1 (As far as I understand). Now, JAX-WS 2.x does support asynchronous web service, but not WSDL 2.x. So I'm assuming that JAX-WS asynchronous web service's clients have to be JAX-WS clients, and that we can not use.
Thanks in advance!
EDIT: The difficulty here is that the service is asynchronous, and we prefer a callback based interface for efficiency (so we don't want to use 2 calls on a synchronous WS interface, etc.)
If its messaging, than use a Messagequeue system. like ZeroMQ. they are all cross platform.
otherwise we do it with .net WCF, and use JaxWS from java to test, that the interface is compatible.
Don't know, what's best, but SOAP is a good choice for a Java backend. The messages are xml based (e.g. not restricted to Java platforms) and it is widely used so you get a lot of support, tools and libraries on the net.
Another idea that might fit your needs: XMPP.
It is definitly asynchronous, client sending a service request (wrapped in a xmpp message) is the callback and doesn't wait for an immediate answer. I've used in a scenario where I send 'service request' from a xmpp client to a server and received the answers, immediately or a bit later, depending on the complexity of the calculation. This was a human-machine interaction but machine-machine should be even easier.
This question already has answers here:
SOAP vs REST (differences)
(13 answers)
Closed 5 years ago.
For now I have a slight idea about the differences between SOAP and RESTful services.
My question is when I should use SOAP, and when I should use RESTful; which one is "better" when it comes to performance/speed or request handling?
I'm implementing it for the first time in RESTful (Java) and I want know more about it; I've dealt with SOAP before.
This is a follow-up question to this post.
REST is almost always going to be faster. The main advantage of SOAP is that it provides a mechanism for services to describe themselves to clients, and to advertise their existence.
REST is much more lightweight and can be implemented using almost any tool, leading to lower bandwidth and shorter learning curve. However, the clients have to know what to send and what to expect.
In general, When you're publishing an API to the outside world that is either complex or likely to change, SOAP will be more useful. Other than that, REST is usually the better option.
REST vs. SOAP Web Services
I am seeing a lot of new web services are implemented using a REST
style architecture these days rather than a SOAP one. Lets step back a
second and explain what REST is.
What is a REST web service?
The acronym REST stands for representational state transfer, and this
basically means that each unique URL is a representation of some
object. You can get the contents of that object using an HTTP GET, to
delete it, you then might use a POST, PUT, or DELETE to modify the
object (in practice most of the services use a POST for this).
Who's using REST?
All of Yahoo's web services use REST, including Flickr and Delicious.
APIs use it, pubsub, bloglines, Technorati, and both eBay, and Amazon
have web services for both REST and SOAP.
Who's using SOAP?
Google seams to be consistent in implementing their web services to
use SOAP, with the exception of Blogger, which uses XML-RPC. You will
find SOAP web services in lots of enterprise software as well.
REST vs. SOAP
As you may have noticed the companies I mentioned that are using REST
APIs haven't been around for very long, and their APIs came out this
year mostly. So REST is definitely the trendy way to create a web
service, if creating web services could ever be trendy (lets face it
you use soap to wash, and you rest when your tired). The main
advantages of REST web services are:
Lightweight - not a lot of extra XML markup Human Readable Results
Easy to build - no toolkits required. SOAP also has some advantages:
Easy to consume - sometimes Rigid - type checking, adheres to a
contract Development tools For consuming web services, its sometimes a
toss up between which is easier. For instance Google's AdWords web
service is really hard to consume (in ColdFusion anyway), it uses SOAP
headers, and a number of other things that make it kind of difficult.
On the converse, Amazon's REST web service can sometimes be tricky to
parse because it can be highly nested, and the result schema can vary
quite a bit based on what you search for.
Whichever architecture you choose make sure its easy for developers
to access it, and well documented.
Freitag, P. (2005). "REST vs SOAP Web Services". Retrieved from http://www.petefreitag.com/item/431.cfm on June 13, 2010
SOAP
Simple Object Access Protocol (SOAP) is a standard, an XML language, defining a message architecture and message formats. It is used by Web services. It contains a description of the operations.
WSDL is an XML-based language for describing Web services and how to access them. It will run on SMTP, HTTP, FTP, etc. It requires middleware support and well-defined mechanism to define services like WSDL+XSD and WS-Policy.
SOAP will return XML based data
REST
Representational State Transfer (RESTful) web services. They are second-generation Web services.
RESTful web services communicate via HTTP rather than SOAP-based services and do not require XML messages or WSDL service-API definitions. For REST middleware is not required, only HTTP support is needed. It is a WADL standard, REST can return XML, plain text, JSON, HTML, etc.
REST is an architecture.
REST will give human-readable results.
REST is stateless.
REST services are easily cacheable.
SOAP is a protocol. It can run on top of JMS, FTP, and HTTP.
REST has no WSDL (Web Description Language) interface definition.
REST is over HTTP, but SOAP can be over any transport protocols such as HTTP, FTP, SMTP, JMS, etc.
REST stands for representational state transfer whereas SOAP stands for Simple Object Access Protocol.
SOAP defines its own security where as REST inherits security from the underlying transport.
SOAP does not support error handling, but REST has built-in error handling.
REST is lightweight and does not require XML parsing. REST can be consumed by any client, even a web browser with Ajax and JavaScript. REST consumes less bandwidth, it does not require a SOAP header for every message.
REST is useful over any protocol which provide a URI. Ignore point 5 for REST as mentioned below in the picture.
REST vs. SOAP
SOAP:
► SOAP is simple object access protocol that run on TCP/UDP/SMTP.
► SOAP read and write request response messages in XML format.
► SOAP uses interface in order to define the services.
► SOAP is more secure as it has its own security and well defined standards.
► SOAP follows RPC and Document style to define web services.
► SOAP uses SOAP-UI as client tools for testing.
REST
► REST is representational state transfer that uses underlying HTTP protocols.
► REST is stateless.
► REST is an architectural style that is used to describe and define web services.
► REST can read and write request response messages in JSON/XML/Plain HTML.
► REST uses URI for each resource that is used in web service.A resource can be image text method etc.
► REST uses set of verbs, like HTTP's GET, POST, PUT, DELETE.
► REST is easy to develop and easy to manage as compared to SOAP UI.
► REST has light-weight client tools or plugins that can easily be integrated inside a browser.
► REST services are cacheable.
Difference between REST and SOAP:
SOAP Web services:
If your application needs a guaranteed level of reliability and security then SOAP offers additional standards to ensure this type of operation.
If both sides (service provider and service consumer) have to agree on the exchange format then SOAP gives the rigid specifications for this type of interaction.
RestWeb services:
Totally stateless operations: for stateless CRUD (Create, Read, Update, and Delete) operations.
Caching situations: If the information needs to be cached.
SOAP web service always make a POST operation whereas using REST you can choose specific HTTP methods like GET, POST, PUT, and DELETE.
Example: to get an item using SOAP you should create a request XML, but in the case of REST you can just specify the item id in the URL itself.
REST is easier to use for the most part and is more flexible. Unlike SOAP, REST doesn’t have to use XML to provide the response. We can find REST-based Web services that output the data in the Command Separated Value (CSV), JavaScript Object Notation (JSON) and Really Simple Syndication (RSS) formats.
We can obtain the output we need in a form that’s easy to parse within the language we need for our application.REST is more efficient (use smaller message formats), fast and closer to other Web technologies in design philosophy.