Talk to me. SOA & SOAP & WebService, and Code logic parsing for client-side development

http://blog.csdn.net/hikaliv/article/details/6459779

A day of time to pass a WebService Java side of C/s, a Android terminal C/S, adjusted the only, very uncomfortable, very stuffy. Because I'm just getting started with JAVA & Eclipse, it's not good for me as a student of VS 2010. The feeling of being forced and unfamiliar makes it easy for me, the Cancer man, to have a strong resistance. But then again, the network aspect of things I have been very interested in, suffer from no project participation. Who makes the project require me AXIS2 + ecliipse + Tomcat + Android? Look at the network project development of face, endure!

Then spent two days looking at the story more than 20 years ago, Moonlighting looked at SOA & soap & WebService and looked at the WSDL and SOAP standards.

In short, the WSDL thing, a Network Service description specification, it is an implementation of the WebService component, but also provides a description of the framework, if you want to use SOAP, to add SOAP element node, if you want to use MIME things, add the MIME element node, want to use H Ttp-get/post something, add the corresponding element node to it.

Figuring out the entire WSDL structure and understanding the main elements that make up the WSDL content tag is fine, and it's a layered sense:

1. 1. Type
2. 2. Message: Definition of type data that requires interaction
3. 3, Operation: Service support of an action description
4. 4. Porttype: A collection of operation supported by several endpoint
5. 5. Binding: Specific protocol and data format specification for a Porttype
6. 6. Port: Defined as the union of a Binding and a network address endpoint
7. 7. Service: Related Endpoints Set

SOA is a good thing. But it's annoying to use AXIS2 + Eclipse + Tomcat to match up a WebService architecture ! SOA and WebService are not a thing, SOA is a concept and a model, a business, WebService is a framework to implement the concept of SOA, a tool.

In a joke, the word SOAP, when I first saw it, thought it was the so-called SOA + P ...

SOAP should be an application protocol designed for RPC, but the fate of HTTP, originally designed to run with application protocols, is becoming more and more of a "degenerate" to "transport protocol." However, both SOAP and HTTP are still application protocols for message transmission.

Some say SOAP = RPC + xml+ HTTP, basically, no. Or try to point out the relationship between SOAP and HTTP. The request and response actions of SOAP messages are requests and responses that need to be mapped to HTTP to complete the communication between C/S. How to map, whatever it is, it's the same thing anyway. For WebService, there are also http-get/post and MIME two ways of communicating messages, in addition to SOAP. But for a better realization of the SOA concept, we can only focus on SOAP.

What SOAP is passing, is the XML data element, hmm ... is a serialized XML data element. SOA is so-called terminal Platform independent, that is, no matter what business, everyone to follow the same specification is- SOAP + XML (Application protocol and data format), this is a typical world unification historical evolution trend, so we accommodating huaxia 7,000 years of civilized history, Ancestors early Enlightenment, early to promote the world unification idea of the ruling world, foreigners civilization history only more than 1000 years, enlightened late, just know, it is time to push the world unification, or, this world is too fucking messy.

For development, programmers need to be clear about code logic, especially when it comes to developing programming that follows business specifications, rather than figuring out the logic of the code, it's better to figure out what the business logic is, what the specification is, and how it is reflected in the code structure.

If you use AXIS2 's Wsdl2java to give birth to the STUB, then you develop the client can save the big thing, but to use the code to build the entire request response operation process, including specifying the endpoint, specify the URI, specify the method signature, specify the parameters, specify the mode of transmission, Specifies the request target, which part of the SOAP message should be populated with which pair of images and so on ... You just need to specify which service method to invoke, what to pass, how to manipulate the return value, and focus on the focus, because the whole SOAP is how to run you do not care, you can certainly succeed in the right.

If you do not want to use or do not use or afraid of using wsdl2java tools to give birth to the code, want to write the client, or similar to the things on ANDROID, to go KSOAP2, the client will have to write their own. At this time, you can only give yourself a "studious" reason to understand the whole SOA & SOAP & WebService is going to go back and look at the code.

But using AXIS2 's parcel to write clients and use KSOAP2 's parcel to write clients is a lot different. AXIS2 in the back or do a lot of work for you, at this point you have no choice, so that AXIS2-based parcel development of the client's code logic is very little SOAP, so first look at the KSOAP2-based client code logic bar.

Before you look, think about what you need to prepare to handle a SOAP request/response process completely on the client side.

We look back at the structure of SOAP, an envelope, a dispensable head, a body. The envelope indicates who will handle the message, that is, who sent the message. With HTTP communication, you must populate the SOAP Action http Header domain with a URI that indicates to whom the letter is to be given. The SOAP body is used to install the RPC pair image, and RPC contains all the information about the function that needs to be called, at least the function name and parameter must be specified. To transfer SOAP using HTTP, you must specify the server-side endpoint, specified by the URL.

Look, this information is the minimum set of a complete SOAP process. It makes clear how this SOAP message is sent (HTTP), where it is sent (Endpoint/url), to whom (Uri/soap Action Header), what (SOAP body/rpc) is sent, and the requirements are written in RPC.

Okay, now look back at the code:

//RPC pair image, service method with namespace and method name  
Soapobject rpc = new Soapobject (NAMESPACE, method_name);  
// Method parameter name and parameter value  
Rpc.addproperty (Para_name, para_value);  
//Use HTTP transport, specify URL, where to send the letter, URL specified to? wsdl   
Httptransportse ht = new Httptransportse (URL);  
//To write a letter indicating the SOAP 1.1 standard  
Soapserializationenvelope envelope = 
       New Soapserializationenvelope ( SOAPENVELOPE.VER11);  
//Will RPC Sechin inside  
envelope.bodyout = rpc; 
//This step is important, tell the person who sent the letter, populate the SOAP Action Header field  
Ht.call (soap_action, envelope);  
//processing feedback  
if (Envelope.getresponse ()! = null) {  
      //returns to an image that contains the underlying type of the package body  
        Soapprimitive re = (soapprimitive) envelope.getresponse ();  
       System.out.println (Re.tostring ());  
}

This section of the client-side code logic developed using the KSOAP2 package is already well understood!

The client-side code logic developed with the AXIS2 package is not very good to look at, it only needs to take care of a few aspects around the service method to invoke: The service endpoint, namespace, and function signature, parameters in which the function resides:

//Call webservice   using RPC,
rpcserviceclient rpcclient = new Rpcserviceclient ();  
Options soption = Rpcclient.getoptions ();            
// Where the service endpoint where the function resides is not specified to wsdl  
EndpointReference enpointref = 
        New EndpointReference ("Http://192.168.1.100:8080/axis2/services/hikaliv");  
//Associate endpoint reference with RPC pair like    
Soption.setto (enpointref);   
//Parameter  
object[] Inargs = new object[]{"Hikaliv"}; 
//return parameter type  
class[] returnclasses = new class[]{string.class}; 
//Specify the method and namespace to invoke  
QName QName = new QName (NAMESPACE, method_name);  
//Adopt synchronous blocking call, wait for result feedback  
Object[] result= Rpcclient.invokeblocking (QName, Inargs, returnclasses);  
for (Object obj:result) { 
        System.out.println (obj);  
} 

Talk about SOA & SOAP & WebService, and Code logic parsing for client-side development