In service oriented architecture, multiple components are connected through the standard interface define in system, and they hides impelemention details. and client consumes the service so i confused about clients, are they directly request from web browser or called from presentation layer in web ?
ex:- what i think about SOA
Database --- > Service ---->(interface like REST, SOAP or Thrift) Consumer
so here consumer can be direct web client ?
1.
Database (mysql) --> Service (Java Restful) ---> Webserver(.php)-----> Browser
2.
Database (mysql) --> Service (JavaRestful) --> Browser(api call though ajax)
so which is answer ?
if first is the answer then will not it be slow, mean we are adding 1 layer more that mean more remote calls mean slow, right ?
SOA is not about specifying how things should be done, SOA is just a core set of principles The four tenets of SOA which when followed should in theory help the integration of multiple services in middleware architecture.
One thing to note that, you should never expose your services directly, you should hide them behind a web interface (gateway), but in fairness, your example isn't really a SOA architecture, it seems to me that is is just some Web Interface which exposes some web endpoints.
That said, both your approaches are valid.
Related
I am trying to learn rest web service and every where i found written that rest works on HTTP protocol. I just want to know what other protocol can be used for building rest service. Link for an example will be great help
REST is 'bound' to HTTP, since the use of the HTTP methods GET, POST, PUT, DELETE is quite central to REST.
First of all, REST is is a software architecture style for building scalable web services.
You are talking about REST when applied to webservices.
Web service APIs that adhere to the REST architectural constraints are
called RESTful APIs.
To answer your question
what other protocol can be used for building rest service
I first need to clarify some things:
You are asking about underlying web service protocols.
Now a web service is "a software system designed to support interoperable machine-to-machine interaction over a network". The network you are interested in is also the best know i.e TCP/IP aka the internet.
Now you are interested in particular about web services which adhere to the REST architectural constraints.
A REST-compliant Web service would be one who's primary purpose of the service is to manipulate representations of Web resources using a uniform set of stateless operations.
The protocol that is used for a RESTful web service
First you need to understand that you are addressing the application layer of the OSI model. HTTP is an application layer protocol of the OSI model.
Theoretically protocols from this list(application layer protocols) which :
can be used to build web services
conform to the REST architectural constraints (stateless,layered system)
could be used for a REST-ful service.
I am proxing huge amount of web services using JBOSS FUSE ESB.
using content based router for deciding the real web services. But, If there is a new services deployed in backend. I am forced to change the proxy details (WSDL) and expose the interface.
which leads to client regenerate the client code again.
Is there any other solution which will allow me to optimize this problem in design level.
Some general thoughts on this but I would need more detail to give some solid advise.
You are proxing the services thus you are not abstracting the services away. You are exposing the services rather directly to the outside via the service on FuseESB.
Typically you would use a ESB to abstract provider and consumers away from each other. This means that you wont expose/proxy the service directly. For example you would create generic operations and data structures. This will allow you to then map the generic interface to the web service implementation that you are providing.
Another approach would be to version the different WSDL's and thus have different versions of the services out there. This will allow you to have client consume the older WSDL's and then migrate them over bit by bit.
What does a Web service really mean ? I am not looking for a theoretical explanation, I am looking for something practical.
I was thinking that anything I can call from an external client is a Web service, so a basic PHP which returns JSON data could be a Web service.
But then I started reading about Web services in W3Schools.org and I got confused. If the PHP URL which returns JSON data is a web service, why would I need to do SOAP, WDSL etc ... to create a Web service. Isn't it extra work?
Also, if SOAP is the way data is sent back and forth, what about other transport types?
What differentiates a RESTful Web service from a SOAP based web service?
When you are talking about a webservice people generally misunderstand what it means, a webservice is simply a way to interact between a and b that abstracts the use of local technology standards. A WSDL defines the way in which the SOAP message is being sent over the channel. REST uses JSON over HTTP, WSDL uses SOAP over HTTP.
The advantage of a webservice is, say you develop one piece of code in .net and you wish to use JAVA to consume this code. You can interact directly with the abstracted layer and are unaware of what technology was used to develop the code.
SOA is a set of design paradigms and standards that tell you how to develop your services, in SOA each service is meant to comply with the principles listed below. WSDL is generally linked with but not essential for a SOA solution. If you wish to learn about SOA google "Thomas Erl SOA".
Priciples of SOA
Standardized service contract
Service loose coupling
Service abstraction
Service reusability
Service autonomy
Service statelessness
Service discoverability
Service composability
This Q&A Restful vs Other Web Services brings a lot of light to what is a webserver, and differences from SOAP and REST. Id recommend to read all the answers (many of them are very good).
There are 2 types of web-services as I know. First one is custom xml formatted messages and the second one SOAP standard xml messages. What are the differences between them? Which one is better, what are pros and cons of each of that two approaches?
By "ordinary" I assume you mean RESTful services. This discussion would be a long one, so I'll try to give you some key points:
RESTful services are the most used flavor of Web Services. They are closely linked to the functionality and principles of HTTP and can be accessed as simple as a GET request (other operations are POST, DELETE and PUT). The core concept is the "resource" which is identified by an URI. Common formats for REST are XML and JSON. It's a pretty straightforward and easy to use technology, which is what makes it so widely available.
SOAP web services are based on XML, most of them adhering to the RPC-style of app design (calling remote methods on a server and getting a response), and use 3 main pillars:
WSDL - Web Service Description Language - used to describe a service in terms of available operations, parameters, etc.
SOAP - Simple Object Access Protocol - used to construct interaction messages between the entities involved (client, server).
UDDI - Universal Description, Discovery and Integration - used to classify and publish available web services to a repository and enable discovery by potential users.
SOAP Web Services tend to have high overhead and generally have very verbose messages, but may be good if you need to implement more complex functionality and interaction in your application.
Strictly speaking only the Soap services are webservices. They are based on the WS-* Specs standardisized by W3C and Oasis. Sometimes a also reffered as Webservice are so called POX-Endpoint (Plain old XML) or REST Endpoint, which allows you to simply get a raw XML via HTTP GET.
SOAP Services carry their schema in form of a wsdl endpoint (usualy append ?wsdl to the service endpoint), so there a lots of tools to create proxy objects and hide the complexity of the webservice call. With POX Services you need to know which schema to use from e.g. the documentation.
SOAP Services carry the payload inside the SOAP Envelope (an XML Schema with header and body with the payload in the body). Having a header independent from the payload allows to reroute the content, sign and encrypt, authenticate etc. without knowing the content. But you pay by additional overhead in the message itself.
POX on the other hand leaves all that to the webserver and relies usualy on HTTP for authentification and compression. Encription and signing had to be done by your system. It is low overhead but also low discoverability.
Whats works best for you depends a lot on your scenario. If you work in a .Net or Java World, you often find it simplest to create a proxy and use that to work with the webservices as remote objects. You get a well build infrastructure and a comfortable programming experience. If youre environment does not support the proxy generation or if it had to be called from anything, POX might the very much more lightweight way to go.
"Web Service" refers to a more abstract and general concept. We can say that anything that can be served on web is a Web Service. SOAP Web Services or RESTful services are special kind of Web Services which has wide acceptance and has their own standards. While SOAP services are built on a new XML based standard, RESTful approach makes use of existing HTTP methods, hence more widely accepted (to my experience).
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs