I am building websites in spring MVC. as there are many spring projects , i wanted know what will be scenario when spring web Services is used for.
i mean what can be done with that. Do i really need it for ecommerce site
Your question is really about "web services". For a layman's explanation of what it is all about, read this Wikipedia article.
There are a number of related acronyms that get bandied about:
SOAP (Simple Object Access Protocol) is a protocol for sending requests to a service and getting back a response. The messages are encoded in XML, and send over HTTP.
WSDL (Web Services Description Language) is a service description language for SOAP-based services. It does things like specify what is in the messages, and how the messages are bound to services.
SOA (Service Oriented Architecture) is essentially a system architecture in which the system consists of lots of SOAP services (and others) described using WSDL.
(The proponents of SOA talk about "design principles", but in my cynical view is that this is just a repackaging / recasting of stuff that people have been doing for 20+ years under other names.)
Do i really need it for ecommerce site
Ask your customers. Ask the people whose systems your system will be interfacing with. Ask the vendors whose components you intend to embed in your system.
If you have to use WS then what extra facility it will give
If you have to use WS (e.g. because your site needs to talk to other services that require WS), then you have to. That is sufficient justification.
If you don't have to use WS, then you need to balance the advantages of using WSDL + SOAP against the advantages of some other approach to implementing your web APIs. An SOA expert will probably say use SOA; an AJAX expert will probably say otherwise. And there are other remote procedure call technologies around ... if you really need that kind of thing.
WSDL + SOAP certainly does have some advantages; e.g.
machine readable specifications for your web APIs,
possibility of validation of messages against XML schemas,
an ecosystem of existing WSDL services,
adoption in some sectors of IT.
But it has downsides also; e.g.
WSDL + SOAP have a significant learning curve compared to some alternatives,
XML is a heavy-weight encoding scheme - relatively expensive to parse,
SOAP only pretends to be type-safe (compared with say CORBA / IIOP),
SOAP is not usually used* in browser-based clients; JSON or plain XML are commonly used for AJAX apps,
many people think SOA is over-hyped and steer clear.
* However, it can be used; read these IBM DeveloperWorks Articles.
My advice (FWIW) if your system is primarily a website, doesn't need to talk to SOAP services, and doesn't need to provide a SOAP service API for others .... don't bother. You can always add SOAP service APIs later if you need to.
Spring Web Services is a product of the Spring community focused on creating document-driven Web services. Spring Web Services aims to facilitate contract-first SOAP service development, allowing for the creation of flexible web services using one of the many ways to manipulate XML payloads.
More here : Spring Web Services
How to use Spring Web Service : Spring WS
If you don't know what Web Services are, you probably don't need them. Web Services are a way (speaking generally here) for one web application to talk to another. You can formulate a request as an xml document and send that xml to a web service, which is listening on a specific URL and port. The Web Service can then perform some action based on this document, and respond back with an XML document. It's commonly used as a means for integration between applications.
If you're building a simple e-commerce site, which does not integrate with other live web products, then likely you don't need Web Services. Spring Web Services is simply an API/library to make reading/writing web services easy.
Related
We are evaluating one design for educational activity. We would like to create complete backend (which handles business logic) in form of RESTful web services.
These services can be used by various apps. Is it good idea to call these web services from Struts 2 framework? I read couple of docs, and people discourage it.
We would love to go with Struts 2 as team is quite strong on it. But if its bad approach, we may consider for other options.
If you want to leverage development on presentation layer between client-side and server-side (this is where Struts2) then you can utilize web services using a web services client API. At this point these web services can be used as data resources.
If you want to stay only on client-side then you don't need any server-side framework for the frontend development.
Note that The introduction to Struts2 and RESTful applications you have posted in comment introduces an alternative way instead of web services for creating backend in a form of RESTful API using Struts2 framework.
Using Struts2 for the REST instead of web services could be a solution for RAD (Rapid Application Development). Because web services are very complicated technology that used in upper high level architectures and using some alternative resource APIs might be cost effective.
One problem that continuously comes up at my workplace is creating clients for Java rest services that we create. We have 4 different programming languages to support and it is costly to create clients for each programming language. Often this means our web services aren't available in a cross platform manner since we rarely have time to build all of the clients.
SOAP provides this type of discovery and machine created client mechanism based off of tools that consume WSDL but our architectural direction is to write REST based services in Java instead of SOAP services.
We would also prefer not to write WSDL documents by hand that expose these REST web services. In a .NET environment, WCF and ASMX web services automatically create the WSDL for consumption in other applications, but this is not a direction my team is allowed to pursue.
Can this be done in some fashion for a Java based REST service?
How can this be done without having to invest a lot of manual labor?
We're currently using spring controllers but might be able to argue for a different Java framework if it provides better velocity.
Jersey (JAX-RS implementation) has support for WADL. You can use Jersey to automatically generate a WADL and there is also some support for generating Java clients from the WADL.
That's for Java, and I don't know if it's more than basic support, but I doubt you can pull it off for 4 different programming languages.
You might want to read these first though (tl;dr: REST is more than a CRUD style Web API and is different than SOAP):
Do we need WADL?
Why the slow WADL uptake?
You may want to check third party tools like swagger (http://swagger.io/) and mashery. I know swagger has support for client generation.
I am a Java SE programmer and exploring implementing JAX-WS web services for the purpose of integrating with our web server. To this date, I have not had experience with web-services thus would like to get everyone’s expert opinion.
The background is that my company has a POS system developed and hosted in-house using Java SE. We are planning for e-commerce capabilities, which will be implemented in HTML/PHP, via external web development company and hosted externally.
Thus we are exploring implementing JAX-WS web services on our endpoint for the purpose of integrating with our e-commerce server running PHP endpoint.
I’ve done some research and my understanding is that:
it is possible to implement JAX-WS without Java EE containers
JAX-WS Web Services Without Java EE Containers
it is possible to mix end-point technologies, and specifically in my case JAX-WS as our endpoint and PHP SoapClient on our e-commerece end-point
PHP SOAP Client to consume JAX-WS with Basic Http Authentication
Using PHP SoapClient with Java JAX-WS RI (Webservice)
I am now wondering what’s is the proper approach when discussing implementation with the external web development company that is building our e-commerce platform. Most web sites and forums’ examples assumes Java on both endpoints and that both endpoints are implemented by the same developer/team.
Based on my limited understudying, I gather the process would be:
Me/my company creating the web service (coding the web services methods in Java)
Me/my company creating the server program
The wsdl generated from the URI (http://:/md5WebService?wsdl )of my server program is then used as the interface contract between our internal POS system and the external e-commerce platform
The web development company that is implementing the e-commerce platform then uses the wsdl to implement the PHP SoapClient endpoint on their side.
And in the case where our internal POS system need to consume a web services created by the external web development company, they will pass me the wsdl and I use that to make the call to them.
Is this the correct way to do proceed?
Many thanks.
Cheers,
Arthur
In Java you have actually two ways to start your design of your web service. You can either create the WSDL (Web Service Description Language) contract first (contract first approach) and then let Java or some framework tools create Java skeleton classes for you which you can use to implement the logic of each operation or you can start by code first approach and implement each web method and its logic and then let Java or some external framework tools generate the WSDL contract for you.
Either way you start, the result should be very similar and platform independent. The standard message format used for WSDL based web services is SOAP (Simple Object Access Protocol) which is based on XML (eXtensible Markup Language) which is by definition platform and programming language neutral.
So, after implementing your service and starting a server for the WS endpoint adding ?wsdl to the end of the endpoint URL should return the WSDL contract to the invoker, which can be used to create client side stubs for the required programming language which furthermore simplify the sending and receiving of messages from and to the web service. Note however that creating stub files might not be needed as all the information may be parsed from the WSDL contract directly. As of lack of knowledge concerning PHP I can't give details on how to call a WS from PHP directly or if stub file creation is required/recommended.
In order to call an other WS from your service you need to create a WS client within one of your web methods and invoke one or more of the operations offered by the remote WS and process the response within your web method.
As I am not sure if you are using any (Java) frameworks like f.e. Apache CXF I am not giving any code examples here. For integrating external web services within your service you might also have a look at Apache Camel which offers integration support for numerous Java based frameworks including CXF. Here your web service is treated as a Consumer while other external services you need to invoke are handled as Producers. The interaction between your internal and the external services is modeled here within a route where you can apply various Enterprise Integration Patterns (EIP) like splitting multiple elements contained within a response into distinct objects which you furthermore can process in parallel.
In general your enumeration of steps involved does look right if you follow the code first approach but as mentioned earlier you can also start by defining your contract first. Depending on your knowledge of the WSDL/XSD syntax (the less you know the exact syntax the more you should use code first approach), crating the contract first might enable PHP side integration sooner while you still develop the internal logic of your implementation.
it is possible to mix end-point technologies, and specifically in my case JAX-WS as our endpoint and PHP SoapClient on our e-commerece end-point PHP SOAP Client to consume JAX-WS with Basic Http Authentication Using PHP SoapClient with Java JAX-WS RI (Webservice)
This is the exact purpose of introducing webservice concept. You don't have to worry about on which platform or language your client and server is implemented. Client and server will simply exchange xml messages (platform independent) as agreed upon within wsdl.
Go ahead with your understanding.
I have developed two java web services; one is SOAP based and the second one REST. Now I have to ask some clients (they can be either java/non java clients) to use my web services. Now what information do I need to pass to the clients to use my web service?
If SOAP, what should I share to clients to use my web service?
If REST, what should I share to clients to use my web service?
With SOAP, you should share the WSDL document that describes the service. This should be enough, but often isn't; the most common missing things are what type of security is required and what interaction patterns (i.e., how to string the methods together) should be used. Theoretically, WSDL can describe these things. Practically, you never see them in the wild. In fact, you're probably better off doing the interaction patterns by just documenting them properly in a human-readable document.
With REST, the ideal is often regarded as being just sharing the URL to the root page of the service, as the service should be self-describing to an extent whereby clients can find out what to do by just following links. This is the core of the HATEOAS principle. In practice, it is much more complex than that. Many JAX-RS implementations can publish service descriptions via a WADL document, which can help. The typical security models used with REST are more discoverable than with SOAP, but are still rather opaque even so, and interaction patterns remain problematic (prodding random stuff at a service in the hope that it works sucks, whether you're doing SOAP or REST or whatever).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
A web service is a function that can be accessed by other programs over the web (Http). To clarify a bit, when you create a website in PHP that outputs HTML its target is the browser and by extension the human being reading the page in the browser. A web service is not targeted at humans but rather at other programs.
SOAP and REST are two ways of creating WebServices. Correct me if i
am wrong?
What are other ways i can create a WebService?
What does it mean fully RESTful web Application?
Correct
The W3C defines a "Web service" as "a software system designed to support interoperable machine-to-machine interaction over a network".
A fully RESTful service is one that adheres to all or the architectural constraints as layed out in Roy Fielding's thesis, Architectural Styles and the Design of Network-based Software Architectures. It's a long read and there are many interpretations. A good start would be to familiarise yourself with the Richardson Maturity Model. NOTE: Most Web Services that claim to be RESTful are only at level 2 in that model.
I think that to understand what is a fully RESTful service you have to understand the difference between RESTful services and standard Web Services. It's quite good exaplained in JEE6 Tutorial by Oracle:
NonRESTful WebServices (In Java as JAX-WS): Big web services use XML messages that
follow the Simple Object Access Protocol (SOAP) standard, an XML language defining a
message architecture and message formats. Such systems often contain a machine-readable
description of the operations offered by the service, written in the Web Services Description
Language (WSDL), an XML language for defining interfaces syntactically.
The SOAP message format and the WSDL interface definition language have gained
widespread adoption. Many development tools, such as NetBeans IDE, can reduce the
complexity of developing web service applications.
A SOAP-based design must include the following elements.
■ A formal contract must be established to describe the interface that the web service offers.
WSDL can be used to describe the details of the contract, which may include messages,
operations, bindings, and the location of the web service. You may also process SOAP
messages in a JAX-WS service without publishing a WSDL.
■ The architecture must address complex nonfunctional requirements. Many web service
specifications address such requirements and establish a common vocabulary for them.
Examples include transactions, security, addressing, trust, coordination, and so on.
■ The architecture needs to handle asynchronous processing and invocation. In such cases,
the infrastructure provided by standards, such as Web Services Reliable Messaging
(WSRM), and APIs, such as JAX-WS, with their client-side asynchronous invocation
support, can be leveraged out of the box.
RESTful Web Services (In Java as JAX-RS)
In Java EE 6, JAX-RS provides the functionality for Representational State Transfer (RESTful)
web services. REST is well suited for basic, ad hoc integration scenarios. RESTful web services,
often better integrated with HTTP than SOAP-based services are, do not require XML messages
or WSDL service–API definitions.
Project Jersey is the production-ready reference implementation for the JAX-RS specification.
Jersey implements support for the annotations defined in the JAX-RS specification, making it
easy for developers to build RESTful web services with Java and the Java Virtual Machine
(JVM).
Types of Web Services
Because RESTful web services use existing well-known W3C and Internet Engineering Task
Force (IETF) standards (HTTP, XML, URI, MIME) and have a lightweight infrastructure that
allows services to be built with minimal tooling, developing RESTful web services is inexpensive
and thus has a very low barrier for adoption. You can use a development tool such as NetBeans
IDE to further reduce the complexity of developing RESTful web services.
A RESTful design may be appropriate when the following conditions are met.
■ The web services are completely stateless. A good test is to consider whether the interaction
can survive a restart of the server.
■ A caching infrastructure can be leveraged for performance. If the data that the web service
returns is not dynamically generated and can be cached, the caching infrastructure that web
servers and other intermediaries inherently provide can be leveraged to improve
performance. However, the developer must take care because such caches are limited to the
HTTP GET method for most servers.
■ The service producer and service consumer have a mutual understanding of the context and
content being passed along. Because there is no formal way to describe the web services
interface, both parties must agree out of band on the schemas that describe the data being
exchanged and on ways to process it meaningfully. In the real world, most commercial
applications that expose services as RESTful implementations also distribute so-called
value-added toolkits that describe the interfaces to developers in popular programming
languages.
■ Bandwidth is particularly important and needs to be limited. REST is particularly useful for
limited-profile devices, such as PDAs and mobile phones, for which the overhead of headers
and additional layers of SOAP elements on the XML payload must be restricted.
■ Web service delivery or aggregation into existing web sites can be enabled easily with a
RESTful style. Developers can use such technologies as JAX-RS and Asynchronous
JavaScript with XML (AJAX) and such toolkits as Direct Web Remoting (DWR) to consume
the services in their web applications. Rather than starting from scratch, services can be
exposed with XML and consumed by HTML pages without significantly refactoring the
existing web site architecture. Existing developers will be more productive because they are
adding to something they are already familiar with rather than having to start from scratch
with new technology.
Deciding Which Type of Web Service to Use
Basically, you would want to use RESTful web services for integration over the web and use big
web services in enterprise application integration scenarios that have advanced quality of
service (QoS) requirements.
■ WebServices: addresses advanced QoS requirements commonly occurring in enterprise
computing. [..]
■ RESTfull: makes it easier to write web applications that apply some or all of the constraints of the REST style to induce desirable properties in the application, such as loose coupling
(evolving the server is easier without breaking existing clients), scalability (start small and
grow), and architectural simplicity (use off-the-shelf components, such as proxies or HTTP
routers). You would choose to use JAX-RS for your web application because it is easier for
many types of clients to consume RESTful web services while enabling the server side to
evolve and scale. Clients can choose to consume some or all aspects of the service and mash
it up with other web-based services.