Interoperability comes to mind (MS/Java).
Also, with EJB you need to distribute EJB interface, with WS you got WSLD (I know there's EJB extension for WSDL, but I'm not sure it's used).
Anything else?
EJB is mostly about a programming model for how you implement callable Business Logic. You code is running in a container which looks after management, clustering, transactions and security. Your component can be called by and number of different mechansims including local Java Calls, RMI/IIOP for remote invocation and also Web Services, so yes your EJB can indeed have a WSDL and be callable fro other non-Java envrionments.
If you start instead from the point of view of having a WSDL, which probably will specify SOAP/HTTP, then you are free to implement that in many different technologies, and of cource invoke it via that specified protocol, which very many different clients can use. The big question is how easily you can deal with those quality of implementation issues - your chosen implementation environment may give a lot of help or leave a lot to you.
Summary: you're not really comparing like-with-like. Web Services is very about the interface, EJB very much about the implementation.
Related
I have read a tutorial "web-service-php-mysql-xml-json".
It seems everything is ok. But then why we should use soap for web services?
When building web services you can go two ways:
SOAP
REST
Most people choose the path of less resistance, which is REST. This means simplicity, ease of development, using HTTP the way it's meant to be used, make good use of cache proxies, more human readable results etc.
SOAP on the other end is more heavyweight than REST and is also backed up by a large set of specifications. But because it is more complex (SOAP used to be the acronym for Simple Object Access Protocol – which proved to be... NOT) SOAP is not liked by lots of people.
Both approaches work and both have advantages and disadvantages.
For example, SOAP can make use of any transport protocol not just HTTP(S), SOAP offers more options when security is concerned, SOAP offers reliable messaging etc etc. REST on the other hand permits many different types of data formats, REST allows better support for browsers because of the JSON format, REST has better performance etc etc etc.
I’m not going to go into more details since you can find a lot of comparisons SOAP vs REST on the web. The thing that I want to emphasize is the fact that in some cases one works better than the other and it is up to you to determine and choose which one to implement given your particular case.
EDIT: To answer your question:
why use SOAP or REST? we can have web service without them?
Well, the W3C defines a web service as "a software system designed to support interoperable machine-to-machine interaction over a network".
OK... that's nice for a definition. But this is not the definition for SOAP/REST, this requirement can be successfully thrown at a communication protocol to handle.
So basically you could have a web service using whatever communication protocol you want (even creating your own) as long as is supports the "interoperable machine-to-machine interaction". This also means something else than SOAP or REST (OK... REST is not a protocol, I just use it here as reference to prove my point... so bear with me).
But you create a web service because you want some clients to use your service. And your clients are out there in the wild wild west (i.e. the web :D) and people there speak SOAP/REST. An there you come and say: "We relly don't like SOAP and REST here in our shop, we like stuff like RPC, CORBA and our own unique creation the "Bone Crusher 10000" protocol. If you want to do business with us, you go learn the "Bone Crusher 10000"". And your clients will say (eyebrow raised) "Yeaaaaah righttttt.....".
(I'm assuming here that your protocol won't be something ground shacking that will totally outclass SOAP/REST :D)
So, if you don't use SOAP/REST you will limit your target audience. It's like English for example. I'm not a native English speaker, are you? Well, it does not really matter since we are able to communicate in English. Want to try this in Icelandic? . Will you wait for me while I learn Icelandic, cause that's not my native language either?
As I already said, it is up to you to determine and choose what to implement given your particular case, but if you move away from known technology stacks you throw away what comes with that: lots of experience, resources, tools and communication options.
As a closing example, there's a lot of support for the SOAP protocol today and you can generate clients very easily starting from the WSDL file. And presto... your clients can communicate with your web service. Will it go as easy as this with "Bone Crusher 10000"? If you write the tools, provide the resources, support etc... Yes! But that will cost you time and money to create something that was already invented and is in wide use today.
An important point user159088 mentions in her/his answer is "[...] you can generate clients very easily starting from the WSDL file [...]"!
I'd like to further elaborate on this:
You can use SOAP in conjunction with WSDL which is standardized what means that people who know the standard (WSDL) can learn from it what operations a webservice offers and how data is exchanged.
This knowledge can be used f.e. to create tools that generate type safe binder classes/objects out of the WSDL file. You can make use of those generated classes (to make RPCs) without manually implementing the requests and encoding/parsing of the data that is exchanged.
Whereas for REST there is no standard (like a WSDL schema) on how the exchanged data looks like. As a result you often end up parsing the data on your own.
A second point is that REST works mainly with the HTTP(s) protocol (it is based on it). It uses the CRUD verbs (CREATE/READ/UPDATE/DELETE) of the HTTP(s) protocol. SOAP does not rely on it and can thus be used with other protocols as well.
When working with web services, is it a good practice to have some sort of converter that converts the object from the web service to your domain object even if they have almost the exact properties? If it is not a good practice, why not?
I generally do this conversion in my code primarily because I prefer to completely abstract the web service and any evidence of it, essentially not wanting to use the objects exposed by the service in my domain. Tools such as AutoMapper are useful in this practice, though I often just do it manually. My preference is just to abstract the external web service behind an internal service or repository interface and have as little code actually depend on the external service as possible (even if the service is also one I wrote and is being used in the same enterprise environment).
Just think of it from the perspective of future re-factoring. If anything in the service ever changes, how much of the consuming application's code will be affected?
I consider a self-described / auto-descriptive service as a good thing in a SOA architecture, since (almost) everything you know to call the service is present in the service contract (such a WSDL).
Sample of a non self-described service for me is Facebook Query Language (FQL http://wiki.developers.facebook.com/index.php/FQL), or any web service exchanging XML flow in a one String parameter for then parsing XML and performing treatments.
Last ones seem further more technically decoupled, since technically you can switch implementations without technical impact on the caller, handling compatibility between implementations/versions at a business level. On the other side, having no strong interface (diluted into the service and its version), make the service tightly coupled to the existing implementation (more difficulty to interchange the service and to ensure perfect compatibility).
This question is related to How to Implement Loose Coupling with a SOA Architecture
So, are self-described / auto-descriptive services loosely or tightly coupled in a SOA architecture ? What are the impacts regarding ESBs ?
Any pointer will be appreciated.
The thing is that loosely coupled SOA services will tend to interact with each other using publish/subscribe semantics not supported by WSDL (which only supports request/response).
When you introduce an ESB like NServiceBus, it focuses on messages and ownership rather than the method invocations that tools generate from WSDL. Those messages can then be represented either as classes in code or in an XSD for interoperability.
The transportation of XML messages from one endpoint to another when done with standard web services does look quite silly as the contract doesn't appear in the WSDL, and that's one of the places where ESBs come in.
Hope that helps.
This question has been asked a few times on SO from what I found:
When should a web service not be used?
Web Service or DLL?
The answers helped but they were both a little pointed to a particular scenario. I wanted to get a more general thought on this.
When should a Web Service be considered over a Shared Library (DLL) and vice versa?
Library Advantages:
Native code = higher performance
Simplest thing that could possibly work
No risk of centralized service going down and impacting all consumers
Service Advantages:
Everyone gets upgrades immediately and transparently (unless versioned API offerred)
Consumers cannot decompile the code
Can scale service hardware separately
Technology agnostic. With a shared library, consumers must utilize a compatible technology.
More secure. The UI tier can call the service which sits behind a firewall instead of directly accessing the DB.
My thought on this:
A Web Service was designed for machine interop and to reach an audience
easily by using HTTP as the means of transport.
A strong point is that by publishing the service you are also opening the use of the
service to an audience that is potentially vast (over the web or at least throughout the
entire company) and/or largely outside of your control / influence / communication channel
and you don't mind or this is desired. The usage of the service is much easier as clients
simply have to have an internet connection and consume the service. Unlike a library which
may not be so easily done (but can be done). The usage of the service is largely open. You are making it available to whomever feels they could use it and however they feel to use it.
However, a web service is in general slower and is dependent on an internet connection.
It's in general harder to test than a code library.
It may be harder to maintain. Much of that depends on your maintainance and coding practices.
I would consider a web service if several of the above features are desired or at least one of them
is considered paramount and the downsides were acceptable or a necessary evil.
What about a Shared Library?
What if you are far more in "control" of your environment or want to be? You know who will be using the code
(interface isn't a problem to maintain), you don't have to worry about interop. You are in a situation where
you can easily achieve sharing without a lot of work / hoops to jump through.
Examples in my mind of when to use:
You have many applications in your control all hosted on the same server or two that will use the library.
Not so good example, you have many applications but all hosted on a dozen or so servers. Web Service may be a better choice.
You are not sure who or how your code could be used but know it is of good value to many. Web Service.
You are writing something only used by a limited set of applications, perhaps some helper functions. Library.
You are writing something highly specialized and is not suited for consumption by many. Such as an API for your Line of Business
Application that no one else will ever use. Library.
If all things being equal, it would be easier to start with a shared library and turn it into a web service but not so much vice versa.
There are many more but these are some of my thoughts on it...
Based on multiple sources...
Common Shared Library
Should provide a set of well-known operations that perform common tasks (e.g., String parsing, numerical manipulations, builders)
Should Encapsulate common reusable code
Have minimal dependencies on other libraries
Provide stable interfaces
Services
Should provide reusable application-components
Provide common business services (e.g., rate-of-return calculations, performance reports, or transaction history services)
May be used to connect existing software from disparate systems or exchange data between applications
Here are 5 options and reasons to use them.
Service
has peristent state
you need to release updates often
solves major business problem and owns data related to it
need security: user can't see your code, user can't access you storage
need agnostic intereface like REST (you can auto generate shallow REST clients for client languages esily)
need to scale separately
Library
you simply need a collection of resusaable code
needs to run on client side
can't tolerate any downtime
can't tolerate even few milliseconds of latency
simplest solution that couldd possibly work
need to ship code to data (high thoughput or map-reduce)
First provide library. Then service if need arises.
agile approach, you start with simplest solution than expand
needs might evolve and become more like "Service" cases
Library that starts local service.
many apps on the host need to connect to it and send some data to it
Neither
you can't seriously justify even the library case
business value is questionable
Ideally if I want both advantages, I'll need a portable library, with the agnostic interface glue, automatically updated, with obfuscated (hard to decompile) or secure in-house environment.
Possible using both webservice and library to turn it viable.
a. What are the things I must consider?
b. I have several Stored Procedures being execute by the current application. If I create equivalent methods to execute these procedures, what would be the risk or the challenge.
Architecturally, one thing you must consider in transforming a web app to a web service is that local access to methods and data is not the same as remote access. Remote access should be designed so that invocations are more course-grained and exchange more information at once.
Another thing you would need to think about is what your serialization protocol you will use. For example, SOAP vs a REST-based protocol.
Also, think about security - the security considerations are different between a web application and a web service.
Finally, think about how others will know about your web service (or if they will at all).
One risk is ensuring that your code remain the same.
What I mean by this is that there is a distinct possibility of code duplication in this situation, and as such means that you may inadvertently forget to modify one of the places where the Stored Procedure is used (say if you add a new variable to the stored proc call).
Then you also must consider security. For example, exposing a web service call that provides a list of users to the wild is probably not that good of an idea. you need to plan for how you're going to pass/receive authentication & authorization information.
Managing your code base as Stephen said is going to be a big challenge if you create equivlant methods. Your much better off extrapolating the methods into a new library, that both the web application and web service will use. Your web apps shouldn't have any data access code in them.
With a web service you need to consider your clients. Who is going to access your data and from where. If for example its from a .net windows client on the same network or machine a TCP binding might be best. Or if you need to support older .net framework clients or even java clients you need to be careful about what technology you use.
You will also want to choose between WCF or ASMX. Which the previous paragraph shouuld help answer.
It seems to me that the greatest challenge will be that you are obviously tempted to do this. I think you're making a mistake.
Your web application, and the web service you propose, have different requirements. By "transforming" the application into the service, you will burden the service with the requirements of the application.
Here's a "thought experiment": what if you were to write the service from scratch, ignoring the application. How similar would the service and application be? If they would wind up alike, then transformation would make sense. Otherwise, not so much.