One of the best Podcasts I have come across, on Web Services concepts...
Lecture 11: Web Services, SOAP 1.2, and WSDL 1.1
Harvard Extension School\'s Computer Science E-259: XML with J2EE
Web Services,SOA,everywhere.Well,it certainly has so much positive impact on current IT community and proving its worth being adopted by leading industry players such as IBM, HP, Oracle, Microsoft, Novell, and Sun for different Web Services products.Yes Iam talking about SOA-Web Services which are here to stay and look set to dominate the deployment of major enterprise applications in the coming years.
IBM’s definition of Web Services states that “Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the World Wide Web.” In one of my previous articles,Web Services Patterns we looked at the advantages provided by SOA applications.
When the definition refers to Web Services being invoked over the World Wide Web, it means that they use HTTP as the transport layer and an XML-based message layer. However, Web Services do not actually require HTTP—XML-formatted data can be sent over other transport protocols (message queuing, for example), which may be more suited to mission-critical transactions.
Web Services generally uses the HTTP and SSL ports (TCP ports 80 and 443, respectively) in order to pass through firewalls. In the early days of “Web Services,” vendors would say that their products were “firewall compliant.” This meant that firewalls would not block the Web Services traffic, whereas CORBA traffic attempting to use CORBA-specific ports may be blocked. Web Services make it easier to deploy distributed computing without having to open firewall ports, or having to “punch a hole in the firewall” as network administrators like to say. This “under the radar” deployment has serious security implications. Most firewalls are unable to distinguish Web Services traffic, traveling over HTTP and SSL ports, from Web browser traffic.
The word “Services” in Web Services refers to a Service-Oriented Architecture (SOA). SOA is a recent development in distributed computing, in which applications call functionality from other applications over a network. In an SOA, functionality is “published” on a network where two important capabilities are provided— “discovery,” the ability to find the functionality, and “binding,” the ability to connect to the functionality. In the Web Services architecture, these activities correspond to three roles: Web Service provider, Web Service requester, and Web Service broker, which correspond to the “publish,” “find,” and “bind” aspects of a Service-Oriented Architecture.
Web Services security focuses on the application layer, although security at the lower layers remains important. The implementation technologies on which we focus are HTTP and SOAP, although we will keep SMTP security in mind also since SOAP can be bound to SMTP as well as HTTP.It may not seem immediately obvious why security for SOAP presents such a challenge. After all, SOAP is generally bound to HTTP, which already has SSL for authentication and confidentiality. In addition, many Web authorization tools already exist. It is a reasonable question to ask why these aren’t enough, and the answer is made up of a number of reasons.The first reason is that, although frequently bound to HTTP, SOAP is independent of the underlying communications layers. Many different communications technologies can be used in the context of one multi-hop SOAP message; for example, using HTTP for the first leg, then SMTP for the next leg, and so forth. End-to-end security cannot therefore rely on a security technology that presupposes one particular communications technology. Even in the case of a single SOAP message targeted at a Web Service, transport-level security only deals with the originator of the SOAP request. SOAP requests are generated by machines, not by people. If the Web Service wishes to perform security based on the end user, it must have access to authentication and/or authorization information about the end user on whose behalf the SOAP request is being sent. This is the second reason for Web Services security.
SOAP is a technology used to enable software to talk to other software much easier than was previously possible. End users (that is, humans) do not make SOAP messages themselves. However, if access to the Web Service is to be decided based on the information about the end user, the Web Service must have access to the information that allows it to make this authorization decision. This information does not have to include the end user’s actual identity.How can this information about the end user be conveyed to the Web Service? Session layer or transport layer security between the application server and the Web Service doesn’t convey information about the identity of the end user of the Web Service. It merely conveys information about the application server that is sending the SOAP message. It may be the case that many of the requests to the Web Service originate from that application server.This challenge is addressed by including security information about the end user in the SOAP message itself. This information may concern the end user’s identity, attributes of the end user, or simply an indication that this user has already been authenticated and/or authorized by the Web server. This information allows the Web Service to make an informed authorization decision.This scenario is likely to be widespread where many Web Services are used to implement functionality “behind the scenes.” It shouldn’t be the case that the end user has to reauthenticate each time a SOAP request must be sent on their behalf. The challenge of providing this functionality is sometimes called “single sign-on” or “federated trust.”
WS-Routing provides a means for SOAP messages to route between multiple Web Services. WS-Routing defines how to insert routing information into the header of a SOAP message. This routing information can be thought of as equivalent to routing tables that operate at lower layers of the OSI stack for routing IP packets.WS-Routing means that one SOAP message may traverse multiple SOAP “hops” between the originator and the endpoint. The systems that implement these hops may have nothing in common apart from the ability to parse and route a SOAP message.When routing between Web Services, the requirement for confidentiality can apply from the originator through to the final SOAP endpoint. It may be a requirement that information be kept secret from SOAP intermediaries. There may be a chance that intermediaries may disclose the information either deliberately or through leaving “gaps” between one transport-level security session and the next. While the data is decrypted, it is vulnerable. This is the same problem that plagued the first release of the Wireless Access Protocol (WAP), in which data was decrypted in between the wireless encryption session and encryption on the fixed wire. This so-called “WAP gap” caused a loss of confidence in WAP security and was addressed in later releases of the WAP specification. Implementing encryption only at the transport level makes a “SOAP gap.”It is often noted that most security breaches happen not while data is in transit, but while data is in storage. This is the principle of least resistance—attempting to decrypt eavesdropped encrypted data from an SSL session is much more difficult than simply testing if a Web site maintainer has remembered to block direct access to the database where the credit card numbers are stored. If decrypted data is stolen from a database, the consequences are no less dramatic. Once data has reached its final destination, it must be stored in a secure state. Confidentiality for a SOAP transaction should not involve simply chaining instances of confidentiality together, since “SOAP gaps” of unencrypted data are available between each decryption and encryption.
Web Services Security Specifications
Confidential information in a SOAP message should remain confidential over the course of a number of SOAP hops.A number of industry specifications have been developed for this purpose. These specifications can be organized into two distinct categories:A standardized framework to include XML-formatted security data into SOAP messages.Standards for expressing security data in XML format. This security information should be used for the high-level principles of security: confidentiality, authentication, authorization, integrity, and so forth.
WS-Security
WS-Security has emerged as the de facto method of inserting security data into SOAP messages. Work on WS-Security began in 2001, was published by Microsoft, VeriSign, and IBM in April 2002, and was then submitted in June 2002 to the OASIS standards body in order to be made into an industry standard. WS-Security defines placeholders in the SOAP header in order to insert security data. It defines how to add encryption and digital signatures to SOAP messages, and then a general mechanism for inserting arbitrary security tokens. WS-Security is “tight” enough to present the definitive means of including security data into SOAP messages, but is “loose” enough to not place limits on what that security data can be.
XML Encryption
XML Encryption is a specification from the W3C. It provides not only a way of encrypting portions of XML documents, but also a means of encrypting any data and rendering the encrypted data in XML format. XML Encryption makes encryption functionality easier to deploy.XML Encryption is not a replacement for SSL. SSL is still the de facto choice for confidentiality between two entities that are communicating using HTTP. However, if the security context extends beyond this individual HTTP connection, XML Encryption is ideal for confidentiality. The capability to encrypt XML is nothing new, because XML is just text after all. However, the ability to selectively encrypt XML data is what makes XML Encryption so useful for Web Services. Encrypting an entire SOAP message is counterproductive, because the SOAP message must include enough information to be useful—routing information, for example. Selectively encrypting data in the SOAP message is useful, however. Certain information may be hidden from SOAP intermediaries as it travels from the originator to the destination Web Service.XML Encryption does not introduce any new cryptography algorithms or techniques. Triple-DES or RSA encryption may still be used for the actual encryption. XML Encryption provides a way to format the meta-information about which algorithm was used, and when the encryption occurred. This aids the Web Service in decrypting the data, provided the decryption key is available to it. This is important, because prior to XML Encryption the only standardization of encryption data was for e-mail messages (that is, S/MIME). If an organization wished to send encrypted data to another organization, both organizations would have to agree on the format of the encrypted data, how and which algorithms to use, and possibly also how to send an encrypted key. Now that information can be contained in an XML Encryption block.
XML Signature
XML Signature is a specification produced jointly by the W3C and the Internet Engineering Task Force (IETF). Like XML Encryption, it does not only apply to XML. As well as explaining how to digitally sign portions of an XML document, XML Signature also explains how to express the digital signature of any data as XML. As such, it is an “XML-aware digital signature.” PKCS#7 is a means of rendering encrypted data, and signed data, which predates XML Signature and XML Encryption. Rather than using XML, it uses Abstract Syntax Notation number 1 (ASN.1). ASN.1 is a binary format, renowned for its complexity. Producing or verifying a PKCS#7 signature requires not just cryptography software, but also an ASN.1 interpreter. XML Signature also requires cryptography software, of course, but an XML DOM replaces the ASN.1 interpreter.
The power of XML Signature for Web Services is the ability to selectively sign XML data. For example, a single SOAP parameter passed to a method of a Web Service may be signed. If the SOAP request passes through intermediaries en route to the destination Web Service, XML Signature ensures end-to-end integrity.WS-Security describes how to include XML Signature data in a SOAP message. An important feature of XML Signature is that it can be very selective about what data in an XML instance is signed. This feature is particularly useful for Web Services. For example, if a single SOAP parameter needs to be signed but the SOAP message’s header needs to be changed during routing, an XML Signature can be used that only signs the parameter in question and excludes other parts of the SOAP message. Doing so ensures end-to-end integrity for the SOAP parameter while permitting changes to the SOAP’s header information.
Security Assertions Markup Language (SAML) provides a means of expressing information about authentication and authorization, as well as attributes of an end user (for example, a credit limit) in XML format. SAML data may be inserted into a SOAP message using the WS-Security framework. SAML is used to express information about an act of authentication or authorization that has occurred in the past. It does not provide authentication, but can express information about an authentication event that has occurred in the past; for example, "User X authenticated using a password at time Y.” If an entity is authorized based on the fact that they were previously authorized by another system, this is called “portable trust.” SAML is important to address the challenge of multihop SOAP messages also, because separate authentication to each Web Service is often out of the question. By authenticating once, being authorized, and effectively reusing that authorization for subsequent Web Services, single sign-on for Web Services can be achieved.Note that this information in a SAML assertion may not indicate the end user’s identity. The user may have authenticated using a username and password, and the administrator of the Web site may have no idea of the user’s actual identity. It may simply be an indication that the user presented credentials and was authenticated and authorized. SAML allows information to be placed into a SOAP message to say “this person was authorized according to a certain security policy at a certain time." If the recipient of this SOAP message trusts the issuer of the SAML data, the end user can also be authorized for the Web Service. This SAML data is known as an “assertion” because the issuer is asserting information about the end user. The concept of security assertions has existed before SAML, and is already widely used in existing software.
XML Access Control Markup Language (XACML) is designed to express access control rules in XML format. Although the two technologies are not explicitly linked, XACML may be used in conjunction with SAML. An authorization decision expressed in a SAML assertion may have been based on rules expressed in XACML.
Microsoft’s Passport technology takes a different approach to single sign-on. The user authenticates to the passport infrastructure, either directly through www.passport .com or through an affiliate site that makes use of functionality provided by passport.com. Once the user is authenticated and authorized by Passport, their authentication status is also available to other Web Services that use Passport. Like SAML, this provides single sign-on. However, the model is different, relying on a central point of authentication rather than SAML’s architecture where authentication happens at an individual Web Service. By being implemented at the site of the Web Service itself, SAML authentication and authorization information may be based on role-based security. Role-based security means that access to resources is based on the user’s organizational role; for example, in a medical setting doctors may have access to certain information while nurses have access to different information.
In this article(from Web Services Security),I tried to just give an overview on the different specifications that can be used to achieve Web Services security,for a detailed understanding,I suggest get a good book like this one,"Web Services Security",to whom I owe these excerpts,and get a clear understanding as to implementing and using specifications for securing the web services you develop.And thanks to ,Mark O'Neil,for his inputs and allowing me to use some stuff from his book.
Recommended books :
Suggested Reading
Web Services provide an important building block for integrating disparate computing platforms and, indirectly, provide a mechanism to integrate their global value chains. You can build Web Services after the system was originally deployed, making them similar in many ways to today's EAI software, but you can also build them along with new software as the open Application Programming Interface (API) to the application.
Advantages of using Web Services
Using Web Services , you can build an API which islanguage- neutral and platform-neutral format, programmers can access data from one system and quickly move it to the other through the Web Service. There are several strengths to this approach:
Programmers can write the data-transfer programs in any language or platform with which they are comfortable.
The source and target systems can control the requests and updates of data in such a way that they do not interfere with a running system.
Suggested Reading
SOA is such a buzzword since late 2006 ,that it made me sit up and realize its virtue & importance in Enterprise application development.And having been involved with SOA for a while now,like implementing couple of applications,somewhere down the line I was thinking about how best I can test my SOA application put together in enterprise integration.And as expected by Gartner that by mid 2009 ,nearly 80% of the enterprises development and integration budgets & effort will be devoted to SOA applications alone,that doubled my efforts to get to know about some products and tools for effectively(both unit & integration) testing my SOA applications suite,be it the front end,services layer ,message exchange(ESB layer) and database ,thats when I came across "LISA",the product I would like to share with everyone and give a brief overview.
iTKO LISA,The LISA 4 Complete SOA Test Platform is a comprehensive testing solution that reduces the effort and cost of SOA test creation and maintenance, while allowing your team to drastically improve quality levels over time through test reuse.LISA will carry developers, QA teams and business analysts from unit testing, to regressions, functional testing, end-to-end integration, load testing, and monitoring after deployment.LISA is a complete no-code software testing solution that supports the entire team's development lifecycle for dynamic web apps, web services, ESB messaging layers, enterprise Java, .NET, data and legacy objects, and more.
Why you need LISA?
To deliver quality SOA applications, enterprises need to achieve Complete, Collaborative, and Continuous TM SOA testing (The "Three C's"):
Hello world with Apache Axis2
This is a step by step guide to hosting a simple Web service with Axis2 and interacting with that service using a client based on generated code.
We will be starting with a simple Java class which will be turned into a service with the necessary packaging. Then a client will be created using the code generated by the WSDL2Java code which will be used to invoke the service we created.
You will have to download Apache Axis2-1.0 Standard Binary Distribution to try this out and the source code of both client and service are available here.
Step 1: A simple Java class
First we need a Web Service and an operation in that service for a client to invoke. Lets develop a Web service with an operation which will echo a string value. The simplest way to do this is with a Java class as shown below:
----------------------------------------------------------------------------------------------------------------------
/**
* The service implementation class
*/
public class SimpleService {
/**
* The echo method which will be exposed as the
* echo operation of the web service
*/
public String echo(String value) {
return value;
}
}
----------------------------------------------------------------------------------------------------------------------
save as - SimpleService.java
----------------------------------------------------------------------------------------------------------------------
Step 2: The service descriptor
Each Axis2 service must have a services.xml file which will inform Axis2 about the service. Following is the services.xml file contents for the SimpleService web service.
the "service" element encapsulates the information about a single service. Within the "service" element there should be a parameter specifying the service implementation Java class. The parameter is specified as a "parameter" element as shown below.
The second child element of the "service" element "operation" element describes the operation and the message receiver that is to be used for that operation. For this service we set the "name" attribute of the "operation" element to the name of the method that we wish to expose as a Web service operation. Hence we set it to "echo":
Axis2 provides a MessageReceiver based on Java reflection and the "messageReceiver" element declaring that org.apache.axis2.rpc.receivers.RPCMessageReceiver should be used.
Step 3: Packaging the service
Axis2 expects services to be packaged according to a certain format. The package must be a .jar file with the compiled Java classes and a META-INF directory which will hold the services.xml file. The jar file can be name .aar to distinguish it as an Axis2 service archive. Its important to note that the part of the file name before ".aar" is the service name.
Create a temp directory in the same location where the SimpleService.java file exists
[Linux]
mkdir temp
[Windows]
md temp
Now compile the SimpleService.java class and move the SimpleService.class file to the temp directory.
javac SimpleService.java -d temp/
Create a META-INF directory within the "temp" directory and copy the service.xml file into the META-INF directory.
Change directory to the "temp" directory and use the "jar" command as follows to create the service archive named SimpleService.aar.
jar cvf SimpleService.aar .
Step 4: Hosting the service
There are a number of ways to host the service that was created in the previous step. The two main methods are
* Using the SimpleHTTPServer that is available in the Axis2 distribution
* Using Axis2 with Tomcat
This tutorial will use the org.apache.axis2.transport.http.SimpleHTTPServer to host the SimpleService.aar
Axis2 service archives are placed in a directory named "services" in a repository directory. The structure of an example repository directory is shown below.
Now create the my-axis2-repo directory structure and copy the SimpleService.aar file into the "services" directory. This example does not require the axis2.xml to be available in the "conf" directory.
Now we have to start the SimpleHTTPserver using the above my-axis2-repo directory as the repository directory. The axis2-std-1.0-RC1-bin distribution comes with a "bin" directory which contains a Linux shell script and a Windows batch file to start the SimpleHTTPServer: http-server.sh and http-server.bat
Start the server pointing to my-axis2-repo directory:
[Linux]
sh http-server.sh /path/to/my-axis2-repo
[Windows]
http-server.bat drive:\path\to\my-axis2-repo
The following output will be shown in the console:
[SimpleHTTPServer] Starting
[SimpleHTTPServer] Using the Axis2 Repository /home/ruchith/Desktop/ibm-workshop/axis2-repo
[SimpleHTTPServer] Listening on port 8080
[JAM] Warning: You are running under a pre-1.5 JDK. JSR175-style source annotations will not be available
[SimpleHTTPServer] Started
Now when we point a browser to http://localhost:8080/ the SimpleHTTPServer will respond with a list of available services and the SimpleService will be listed there.
Step 5: Accessing the service with a generated client
Now lets use the WSDL2Java tool generate the client side stubs to interact with the service.
[Linux]
$ sh WSDL2Java.sh -uri http://localhost:8080/axis2/services/SimpleService?wsdl -o /path/to/my/client/code/
[Windows]
WSDL2Java.bat -uri http://localhost:8080/axis2/services/SimpleService?wsdl -o /path/to/my/client/code/
This generates two .java files and we will be using the org.apache.axis2.SimpleServiceStub to invoke the "echo" operation of the service.
Now lets create a new Client.java class which uses the org.apache.axis2.SimpleServiceStub. For simplicity lets create the Client.java file in the same package as the generated code (i.e. org.apache.axis) and save it along with the other generated code.
----------------------------------------------------------------------------------------------------------------------
package org.apache.axis2;
import org.apache.axis2.SimpleServiceStub.EchoRequest;
import org.apache.axis2.SimpleServiceStub.EchoResponse;
public class Client {
public static void main(String[] args) throws Exception {
SimpleServiceStub stub = new SimpleServiceStub();
//Create the request
EchoRequest request = new SimpleServiceStub.EchoRequest();
request.setParam0("Hello world");
//Invoke the service
EchoResponse response = stub.echo(request);
System.out.println(response.get_return());
}
}
----------------------------------------------------------------------------------------------------------------------
save as - Client.java
----------------------------------------------------------------------------------------------------------------------
Now to we can compile and run the client code. Its is important to note that the classpath must have all the jars in the "lib" directory of the axis2-std-1.0-RC1-bin distribution when compiling and running the client.
The following command will compile the client's source to a "temp" directory
$ javac -extdirs /path/to/axis2-RC1-std-bin/lib/ org/apache/axis2/*.java -d temp/
We can run the client program as shown below from the "temp" directory:
$ java -Djava.ext.dirs=/path/to/axis2-RC1-std-bin/lib/ org.apache.axis2.Client
The output will be :
Response : Hello world
Step 6: Monitoring the messages
To view the request and response SOAP messages we can use the tcpmon tool.
We can start the SimpleHTTPServer on port 9090 and make the tcpmon listen on port 8080 and forward the requests to port 9090.
Using "-p9090" as an additional argument in starting the SimpleHTTPServer we can start it on port 9090.
Example:
sh http-server.sh /path/to/my-axis2-repo -p9090
Now when we run the client once again we can view the messages.
Conclusion
This example is the most simple example one can use to start using axis2. I hope this will be a starting point for you to explore more and more about Apache Axis2. If you have any questions please feel free to mail the axis-user mailing list, with [Axis2] as the subject prefix.
Source :http://people.apache.org/~ruchithf/hw-axis2/
Axis and XFire are competing Java web service frameworks; Axis is an Apache project and XFire is a Codehaus project.
It is difficult to compare the Axis and XFire web services frameworks for the purpose of deciding which one to adopt. Both web services frameworks have some significant challenges associated with using them, and there are good reasons to choose either one or the other. It all depends on where the emphasis is being placed when comparing them: stability, performance, or ease of use.
2 Branches Of Axis
Before comparing Axis to anything else, however, it is important to make note of the fact that there are two separate Axis frameworks: Axis 1 and Axis2. The Axis development team has shifted to Axis2 and has made it clear that while Axis1 bugs may be fixed, all enhancement and feature work is going to take place on Axis2, which is a ground-up reimplementation of the framework using a very different model.
Axis1 is a stable platform—stable to the point of ossification. It does have outstanding bugs, but there seems to be little effort on the part of the developers to correct them, or even evaluate patches contributed by non-Axis developers. Recent months have seen a drop-off even in responses to Axis1 question on the axis-users mailing list.
For this reason, it is reasonable to continue to use Axis1 for legacy applications that are already working and do not require major changes, as its very stability is an advantage there. However, in developing new applications it is probably advisable to look to Axis2, since it is under active development and it has a large, active community associated with it. Therefore it makes more sense to compare Axis2 and XFire for purposes of selecting a platform for new applications, or porting an existing legacy application to one of the current frameworks.
Comparing Axis2 and XFire
With this in mind, then, what differentiates Axis2 and XFire? Perhaps before highlighting differences we should look at the ways in which they are the same:
* Both have active user and developer communities
* As of February 12, 2007, both have an almost identical number of open bugs
* As of February 12, 2007, both have an almost identical quantity and distribution of Blocker, Critical, Major, Minor and Trivial bugs in their JIRAs (Axis2 JIRA, XFire JIRA)
So from this we can conclude that in terms of the number of reported bugs the two projects are pretty similar. How are they different?
Axis2:
* Has more active committers
* Has both Java and C/C++ implementations
* Has a sponsoring company (WSO2)
* Is perhaps more widely known
* Has completed a major codebase change and is moving towards stability (but is not as stable as Axis1 yet)
* Performance is comparable to XFire
XFire:
* Is thought to be easier to use
* Has more clearly-written documentation
* Is currently fairly stable
* Performance is much better than Axis1 and equivalent to Axis2 in most cases
However, there is one major issue that makes Axis2 preferable over XFire at this time: On July 22, 2006, the XFire team announced that in XFire 2 they would be merging codebases with the Celtix framework and joining the Apache Software Foundation as CeltiXfire. One of the stated non-goals for this migration stated by the team is backwards compatibility with the current XFire code base—meaning that developers who write new applications using the XFire 1.x framework are going to be facing a situation similar to the one faced by Axis developers when that team dropped Axis1 and began Axis2. Since Axis2 has already completed this transition it makes sense not to adopt XFire for new projects at this time.
NOTE from XFire author: XFire services will be deployable inside CXF with little/no modification for most people. Your XML deployment descriptors and/or your usage of the XFire APIs wlil need to change though. Hoewver, the APIs in CXF are very similar to the XFire APIs. It is not a major departure for the most part!
Once the CeltiXfire migration is complete, however, and the new version of the software has had the chance to mature, this comparison needs to be revisited.
See also
* JAX WS
External Links
* codehaus xfire soap stack comparison
Also see sample implementation of Axis 2 and Xfire in the following articles.....
Axis 2- http://wso2.org/library/95
XFire-http://www.javaworld.com/javaworld/jw-05-2006/jw-0501-xfire.html
You develop a WebLogic Web Service, by using standard J2EE components, such as stateless session EJBs, and Java classes. Because WebLogic Web Services are based on the J2EE platform, they automatically inherit all the standard J2EE benefits, such as a simple and familiar component-based development model, scalability, support for transactions, life-cycle management, easy access to existing enterprise systems through the use of J2EE APIs (such as JDBC and JTA), and a simple and unified security model.
A single WebLogic Web Service consists of one or more operations; you can implement each operation using different back-end components and SOAP message handlers. For example, an operation might be implemented with a single method of a stateless session EJB or with a combination of SOAP message handlers and a method of a stateless session EJB.
Here is what happens when a client application invokes this type of WebLogic Web Service operation:
1. The client application sends a SOAP message request to WebLogic Server over HTTP. Based on the URI in the request, WebLogic Server identifies the Web Service being invoked.
2. The Web Service reads the SOAP message request and identifies the operation that it needs to run. The operation corresponds to a method of a stateless session EJB or a Java class, to be invoked in a later step.
3. The Web Service converts the operation's parameters in the SOAP message from their XML representation to their Java representation using the appropriate deserializer class. The deserializer class is either one provided by WebLogic Server for built-in data types or a user-created one for non-built-in data types.
4. The Web Service invokes the appropriate back-end component method, passing it the Java parameters.
5. The Web Service converts the method's return value from Java to XML using the appropriate serializer class, and packages it into a SOAP message response.
6. The Web Service sends the SOAP message response back to the client application that invoked the Web Service.
For further information, browse through this beautiful doc provided by BEA.
http://e-docs.bea.com/wls/docs81/webserv/arch.html
Hi Folks,
Recently one of my friends put forth this question to me ?
Why POJO web services does not require binding and what are the limitations of POJO web services?
I tried convincing him by giving many answers like, When you are dealing with Business web services you need some kind of contract , so you need to bind the Java objects with the XML data together and also to handle security of the data passing between systems, He didnt agree to any of my suggestions?
Then I asked him can you tell me when do you use a Java Bean vs Java class,to see whether he gets the point here,but no luck, he is a hard nut to crack.
So my question to everyone of folks interested in POJO Web Services,please provide me any answers to this question and avoid more embarrassment for me.
Cheers,
Yaseen
digg
reddit
del.icio.us