I have studied many books from "Apache Axis2 in Action" to "SOA Using Java Web Services". And the panorama is incredible complex. I created a universal web service that works fine; it is a simple servlet:
Of course, I can avoid reflection by using directly a method in an object. The point is, if we can create web services so simply why are we drowning in such complexity. I must be missing something; please illuminate my ignorance.
Your help will be greatly appreciated,
First off, I'll grant you that SOAP WS are quite complex, especially once all the available add-ons are considered (WSDL, UDDI, WS-Security, BPEL, ...). That's why SOAP has taken a severe beating over the last few years, and these days RESTful WS -which are simpler, but also less full-featured- are much more fashionable.
On the other hand, what you have implemented is only a tiny part of what a full-blown SOAP stack does. For example, how would I find out which services are available and which parameters they take so that I can build a client (the job of WSDL)? How can I secure it -username/password, digital signature, encryption- (the job of WS-Security)? What if I want to deploy/undeploy/redeploy services at runtime? What if you want service methods that do not take two integer parameters? What if you do not want all methods in a class to be available as service methods? Etc. etc. Once you start considering how to offer those features in a generalized way you can appreciate why SOAP stacks are such complex beasts (not that SOAP is generally necessary, see the first paragraph).
Thank you for your contribution Wolf. You raise some interesting points, but I think I can cover them.
how would I find out which services are available and which parameters they take so that I can build a client (the job of WSDL)?
You can always create a WSDL with the tags to use the web service (including the parameters).
How can I secure it -username/password, digital signature, encryption- (the job of WS-Security)?
You can pass authentication information as arguments.
What if I want to deploy/undeploy/redeploy services at runtime?
I am not sure I understand this. I think you can create servlets at run time and you can enable or disable them in web.xml.
What if you want service methods that do not take two integer parameters?
You can use any type of parameters that you can represent in JSON.
What if you do not want all methods in a class to be available as service methods?
You can use private methods.
What I am claiming is that all you can do to perform computations in a remote machine communicating through the Internet is to pass data between client and server as strings as long as any programming language can handle the encoding of the strings. Anything that you can do in SOAP other than passing strings is executed in code in the server and therefore it can be accomplished in a servlet. I am still ignorant and there may be some subtle reasons for the complexity of the JSRs. On the complexity of JSRs, what is the point of using EJBs if I can access the same functionality with a servlet?
Your help will be greatly appreciated,
The purpose of web services are to allow applications to communicate. It is an "integration" techology. It is not an "implementation" technology.
The Java servlet code above is technology dependent, e.g. Java objects, so it cannot considered "universal."
Keep in mind that "services" in a SOA and "web services" are different concepts, i.e. they are not the same.
Web Service Example For example, if you wanted to expose data to many applications in an enterprise and also prevent any application from directly connecting to the database management system, you could create a "web service" for this. Here you would still have an application that actually connects to the database and retrieves the data. The web service would simply sit in the middle. Client applications would use the web service to get the data. Firewalls and all types of security measures would protect the database management system (DBMS). No client applications would know the location of the DBMS. Only the internal application would know.
Service Example Your organization sends consultants on many speaking engagements and you want to centralize the processes for making these reservations. You could create a "service" that will handle all reservations from checking calendars, contacting and paying third-parties, getting all required approvals and sending notifications, and whatever else. This "service" is an example of what an SOA is all about. How exactly this "service" is implemented and if it uses other services and "possibly" one or more "web services" are implementation details. The "service" is a method of encapsulating and exposing a business process efficiently. SOA is a strategic business methodology mostly and requires significant stakeholders to be implemented correctly...if they have the right resources
While I could take issue with every single one of your points, it wasn't really my intention to elicit specific responses. They were just meant as examples of what SOAP engines do that your code didn't even begin to address; there are more such points. Yes - you could implement all that yourself -just like it's possible to rewrite something like Axis2 from scratch- but why would you, given that SOAP and REST engines exist?
I don't understand what EJBs have to do with this, but I don't think it's germane to the original question anyway.