Shulou(Shulou.com)06/02 Report--

This article will explain in detail how to understand J2ME's Web service API. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

If you know anything about J2ME's Web service API, let me share with you that Web service in Java2 platform Pocket (J2ME) platform is defined by Java Specification request 172 (JSR172), which follows the same specification, structure, and invocation model as standard Web service.

J2ME's API explanation of Web Service

Web Services API (WSA) for Java2 platform Pocket Edition (Java2Platform,MicroEdition,J2ME) is defined by JavaCommunityProcess for Java specification request 172 (JSR172). These API are two independent optional packages for remote service invocation and XML parsing. They are for frameworks based on connected device configurations (ConnectedDeviceConfiguration,CDC) and limited connected device configurations (ConnectedLimitedDeviceConfiguration,CLDC1.0 and CLDC1.1). Why should users pay attention to this? Because JSR172 provides support for remote service invocation and XML parsing at the device level, this means that developers do not have to embed this functionality in every application. This article introduces the optional package API for remote service invocation.

Web Services in J2ME

Web services in the Java2 platform Pocket Edition (J2ME) platform are defined by Java specification request 172 (JSR172), which follows the same specification, structure, and invocation model as standard Web services. Let's review the list.

Comparison with standard Web services

The JSR172Web Services API (WSA) follows these core Web service specifications:

Simple object access Protocol (SOAP) 1.1, which defines transport and data encoding.

Web Services definition language (WSDL) 1.1, which defines how to describe remote services.

XML1.0, which defines XML markup language.

XMLSchema, no doubt, defines the XML schema.

Note that JSR172 does not support the Unified description, Discovery, and Integration (UDDI) 2.0 specification, which defines how to discover remote services.

Due to the emergence of a considerable number of specifications related to Web services and covering different technologies, and more and more, the Web Services Interoperability Organization (WS-I) defines WS-I basic profile 1.0 (WS-IBasicProfile,Version1.0) to define the minimum set of Web service specifications, which, like conformance rules, must be followed by all underlying Web service providers and consumers. The JSR172 specification also conforms to the WS-I basic profile.

Have the same architecture as standard Web services:

JSR172WSA accesses Web services from the client, and from a service-consumer perspective, WSA provides remote service invocation API (JAX-RPC) and a runtime environment, allowing J2ME applications to consume services on Web instead of running as service producers (endpoints). Apart from this difference, other parts of the JSR172WSA architecture are consistent with the standard architecture / organization of Web services, as shown in the following figure:

The high-level architecture is organized as follows:

Client, Web service consumer: it is a J2ME application, such as MIDP or personal version framework-based applications, JSR172 stubs and supporting classes, and the JSR172 runtime.

Network: refers to wireless and wired networks and communication protocols, which are part of Internet. Note that JSR172 itself does not dictate the use of XML encoding methods on devices, but allows executors (as long as they are transparent to consumers and producers) to use more efficient encoding methods, such as the use of binary protocols between devices and wireless gateways.

Server, Web service producer: it is a Web server, usually behind firewalls and / or proxy gateways. The server can access background resources.

The invocation model and data flow are the same as standard Web services:

J2ME applications invoke remote services through JSR172 stubs and runtime, usually through HTTP and SOAP. Stubs and runtimes hide the complexities associated with remote service invocations, including how input and return values are encoded and decoded, and how to manage network communication with the server. Method calls follow the synchronous request-reply model, as shown in the following figure:

Figure 2-JSR172 invocation model

* because calls are made on a module-by-module basis, you should dispatch these calls to different execution threads.

Consume Web services

To consume a Web service, you must first create a service call stub. Let these stubs perform tasks, such as encoding and decoding input and return values, and interacting with the JSR172 runtime to invoke remote service endpoints. Stubs interact with the runtime through the runtime's service provider interface (SPI), which makes it easier for stubs to execute between different vendors by outlining the details of runtime execution.

Stubs are usually generated by a tool that reads an WSDLXML document that describes the Web service to be used. Similarly, WSDL documents are usually generated by a tool that reads interface definitions, such as the Java interface that produces WSDL documents.

From our mobile development perspective, the WSDL documents that need to be consumed usually already exist, and all you need to do is generate JSR172WSA stubs. To generate these stubs, you should use a tool such as the J2MEWirelessToolkit2.1 stub generator, as shown in the following figure:

Figure 3-generate JSR172WSA stubs

The generator generates stub Java files and related supporting classes. As described in the following section, it also takes into account WSDL-to-Java data type mapping.

Once the JSR172JAX-RPC stubs and support files are generated, your application has been compiled and deployed to JSR172-enabled devices, and consuming Web services is simple and almost transparent. As you will soon see, calling a remote method is almost as simple as calling a local method.

JSR172JAX-RPC subset API

The JSR172 remote method call API is based on a subset of J2SEJavaAPI (JAX-RPC1.1) of XML-based RPC. It also complies with the WS-I basic profile. Let's take a closer look at the JSR172JAX-RPC subset API:

It supports:

SOAP1.1 .

Any transport that can carry SOAP messages, such as HTTP1.1, has a defined protocol binding for SOAP1.1.

The literal representation of the SOAP message represents an RPC call or reply.

The following is the data type and the corresponding Java mapping:

Xsd:boolean to boolean or Boolean.

Xsd:byte to byte or Byte.

Xsd:short to short or Short.

Xsd:int to int or Integer.

Xsd:long to long or Long.

Xsd:float to float, or Float. For CLDC1.0-based platforms, this data type maps to String.

Xsd:double to double, or Double. For CLDC1.0-based platforms, this data type maps to String.

Xsd:string to String.

Xsd:base64Binary to byte [].

Xsd:hexBinary to byte [].

Xsd:complexType to a sequence of base and class types.

Xsd:QName to javax.xml.namespace.QName.

An array of basic types and complex types (structures containing basic or complex types) based on the XML array pattern.

It does not support:

SOAP message with attachment.

SOAP message processor.

The encoded representation of the SOAP message.

Service endpoints (not Web service producers).

Service discovery support (UDDI).

The XML coding method is not specified on the device side. This helps reduce network traffic by allowing executors to use more efficient data encoding methods, such as using binary protocols between devices and wireless gateways (as long as this coding is transparent to consumers and producers).

The JSR172 remote call API includes the following packages:

Javax.microedition.xml.rpc

Javax.xml.namespace

Javax.xml.rpc

Java.rmi (including ensuring JAX-RPC relevance)

Note that these API (with some exception API, such as RemoteException) are not called directly by the application; instead, the application invokes the generated stub. The API above is mainly for stubs. Refer to the JSR172 specification and / or Java documentation for more information.

Invoke a remote service using JSR172JAX-RPC

Once the JSR172JAX-RPC stubs and support files are generated, compiled, and deployed, it is easy to consume remote services. In fact, apart from importing RemoteException and doing a minimum of JAX-RPC detail initialization, your application not only looks, but also runs like a non-Web service consumer application. Because of the JSR172 stub and runtime, it is possible to implement such a simple application, which, as mentioned earlier, hides most of the details related to remote calls.

To invoke a remote service, you first need to instantiate the stub, do the least stub initialization, and then how to write the calling stub method. The following code snippet shows how to invoke a remote service using JSR172JAX-RPC.

On how to understand J2ME's Web service API to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.