MOSP與Web Service間互通性實作：MOSP呼叫Web Service

(1)

國立臺灣大學管理學院資訊管理研究所碩士論文

Department of Information Management College of Management

National Taiwan University Master Thesis

MOSP 與 Web Service 間互通性實作：

MOSP 呼叫 Web Service

Interoperation Between MOSP and Web Service:

MOSP Calling Web Service

郭家禎 Chia-Chen, Kuo

指導教授：莊裕澤博士 Advisor: Yuh-Jzer, Joung, Ph.D.

中華民國 97 年 7 月 July, 2008

(2)

THESIS ABSTRACT

GRADUATE INSTITUE OF INFORMATION MANAGEMENT NATIONAL TAIWAN UNIVERSITY

Student: Chia-Chen, Kuo Month/Year: July, 2008 Advisor: Yuh-Jzer, Joung

Interoperation between MOSP and Web Service:

MOSP Calling Web Service

Nowadays, companies are moving their main operations to web for better automation, efficient business processes and global visibility. We need an integrated, robust solution for leveraging the existing applications, rapidly adapt to the unique needs and continually evolve as requirements change over time. Web Service, with loosely coupled and dynamically bound components, is the present evolution of this new category of services.

Although Web Service is very popular and in general use, which solves many problems, there are still some insufficiency. For example, it is a stateless service system, which does not record the state of each client using it and can only provide services with simpler interaction.

A brand-new solution, MeshObject Service Protocol (MOSP) provides another choice now. MOSP uses the concept of object-oriented, which enables users to obtain an object instance of the service provided by a peer by binding to its MOSP URL.

MOSP can provide stateful services with such way. Besides, MOSP contains the concept of inheritance as well, which enables MOSP services to be reused more freely and easily, and therefore reduces the cost and time to develop applications.

In this thesis, we proposed a gateway system which enables MOSP clients to call Web Service in order to promote MOSP and to make Web Service still available in MOSP environment.

Keywords: Web Service, MOSP, MeshObject Service Protocol, Gateway, WSDL, SOAP.

(3)

List Of Figures

Figure 1-1: A Sample of MOSP Environment ... 4

Figure 1-2: MOSP Shopping Cart Service – Object Instance Creation ... 4

Figure 1-3: Web Service Shopping Cart Service ... 5

Figure 1-4: Web Service Shopping Cart Service – Instance Creation and Deletion .. 5

Figure 1-5: MOSP Shopping Cart Service – Inheritance ... 6

Figure 1-6: Web Service Shopping Cart Service – Inheritance does not work here .. 6

Figure 1-7: MOSP Shopping Cart Service – Polymorphism ... 7

Figure 1-8: Web Service Shopping Cart Service – Polymorphism does not work here ... 7

Figure 1-9: Web Service Shopping Cart Service – try another way to Override ... 8

Figure 1-10: MOSP Shopping Cart Service – Dynamic Binding ... 8

Figure 1-11: Web Service Shopping Cart Service – Dynamic Binding ... 9

Figure 1-12: XML Schema Data Types [30] ... 11

Figure 2-1: Web Service Framework [30] ... 15

Figure 2-2: Web Service Processing Model ... 16

Figure 2-3: A sample of an XML document ... 16

Figure 2-4: SOAP Architecture ... 18

Figure 2-5: The sender transfers SOAP message ... 18

Figure 2-6: The SOAP Message which Client sends ... 19

Figure 2-7: The SOAP Message which Server responses ... 19

Figure 2-8: WSDL document Architecture ... 20

Figure 2-9: MOSP Service Architecture ... 21

Figure 2-10: The exchange of MOSP request/response messages of service descriptions or service calls between MOSP client and MOSP service ... 22

Figure 2-11: A sample MIDL ... 23

Figure 2-12: MOSP message framework ... 24

Figure 2-13: MOSP client request for MIDL ... 25

Figure 2-14: MOSP service response of the MIDL request ... 25

Figure 2-15: MOSP client request message for an operation call ... 26

Figure 2-16: MOSP service response message of the operation call ... 26

Figure 2-17: Components in the CORBA 2.x Reference Model [2] ... 28

Figure 2-18: Generic SOAP/HTTP to IIOP Bridge Diagram [20] ... 30

Figure 2-19: Static Dedicated SOAP/HTTP to SCOAP/ORB Bridge Diagram [20] . 31 Figure 2-20: SOAP-CORBA Interoperability Interaction Model [20] ... 31

Figure 2-21: XORBA Architecture [23] ... 33

Figure 2-22: IDL Fragment of a XORBA Message Example [13] ... 33

(6)

Figure 2-23: A Sample SOAP Request [13] ... 34

Figure 2-24: CORBA/SOAP Integration Model [7] ... 35

Figure 3-1: How a MOSP Service works ... 38

Figure 3-2: Generic Gateway Service System ... 39

Figure 3-3: Generic Gateway Service System (when createGateway() is called) .. 39

Figure 3-4: Gateway Service Work Model ... 41

Figure 4-1: MOSP Server ... 44

Figure 4-2: MOSP Service ... 45

Figure 4-3: MOSP Client ... 45

Figure 4-4: MIDL document of Gateway Factory Service ... 46

Figure 4-5: A sample of WSDL document ... 53

Figure 4-6: The description part of a WSDL document ... 54

Figure 4-7: An MIDL document transformed from WSDL document ... 55

Figure 4-8: A sample SOAP request message ... 57

Figure 4-9: A sample SOAP response message ... 58

Figure 4-10: The sample Time Period of Generic Gateway Service System ... 60

Figure 4-11: The Relationship between WSDL Size and Time Spent in Each Step .. 61

Figure 4-12: The Time spent when MOSP client calls Web Service operation (Step 3) ... 61

Figure 4-13: Time spent of different Web Service operation call ... 63

Figure 5-1: Inheritance to No-Inheritance ... 66

(7)

List Of Tables

Table 1-1: Comparison between Web Service, JAVA and MOSP ... 10

Table 1-2: Java Types marshal to MOSP Data Types and unmarshal to Java Types .... 12

Table 2-1: Comparison between Web Service and CORBA [10] ... 29

Table 2-2: Comparison between WSDL and IDL [13] ... 29

Table 2-3: Comparison between XML Schema and CORBA Object Model [13] ... 29

Table 4-1: The algorithm of createGateway() ... 47

Table 4-2: The WSDL input/output message type to MOSP type ... 50

Table 4-3: The type transformation algorithm ... 51

Table 4-4: Mappings between XML and MOSP data types – 1 ... 55

Table 4-5: Mappings between XML and MOSP data types – 2 ... 56

Table 4-6: Mappings between XML and Java data type – 1... 58

Table 4-7: Mappings between XML and Java data type – 2... 59

(8)

Chapter 1 Introduction

1.1 Background

With the intensively progressing of technology, Internet has helped forward the development of all kinds of services. However, the traditional independent single service can no longer fulfill the increasing growth of user needs. Imagine that we have got a long vacation and plan to go traveling abroad. Before departing, we may need some services like traveling information query, flight tickets and hotel room booking, and weather forecast, etc. To get these services, we will usually surf on the websites of the airline companies and hotels. Thus we may need an integrated digital assistant to help us arrange the schedule, and all we have to do is just confirm and pay the bill.

So, how does information technology solve this kind of problem?

At the time when networks are more and more universal, the above demands will obviously increase. However, the data are dispersed in different websites at everywhere in the world. To accommodate this tendency and to solve this kind of problems, Web Service [29] has been born at this era when Internet rose and developed and when XML [26] was mature.

Web Service is a software system, which provides a systemized and extensible framework with network communication protocol and an open standard of data format. As the component providing services, Web Service can be used to build distributed systems. Moreover, open standards make Web Service more interoperable, which also gives the systems, which are on different platforms and developed with different language, the ability to integrate and thus solves the problems distributed systems may face when integrating.

Furthermore, in many circumstances, we can easily observe the benefits Web Service brings. First of all, Web Service can communicate across the firewall. Now suppose that we need to provide an application service, whereas there are thousands of uses spread around the world. There are usually firewalls and proxy servers between clients and servers. Besides, application service providers generally are not willing to release the programs to each one of the great amount of users. Eventually, we can only choose to use browser and ASP to reveal the programs to client, which only result in a rise in difficulty of system development and maintenance. Under such condition, we can use Web Service to easily simplify this problem. We can build a

(9)

SOAP [27] client with Microsoft SOAP Toolkit [15] or .NET [14] and connect it with the application. In this way, we can not only shorten the development terms and reduce the complexity of codes but also increase the maintainability of the application.

Secondly, Web Service can be used to integrate different applications. One of the challenges which application developers often face is that they usually need to integrate all kinds of applications developed with different languages and implemented on different platforms, which generally takes a large amount of cost.

With Web Service, we can use a standardized method to reveal the operations and data of applications for other application to use. Assume that there is an order program responsible for the registration of new orders from clients and another program used to manage the shipping of merchandise. Whenever a new order comes out, the order-registration program has to notify the order-administration program to deliver the cargoes. If these two programs come from different software manufacturers, traditional application mergence way must take lots of cost. But now with Web Service, we can simply reveal some operations of order-administration program like

“addOrder()” for order-registration program to deliver cargoes.

In addition, Web Service also improves the reuse of software. In the past, the reuse of software was limited to program codes but not the data. It’s because that we can readily publish the source code but hard to do the same thing on data, unless they are static and rarely change. In contrast, Web Service allows the reuse of codes and the data behind them. With Web Service, we no longer need to purchase, install and make use of software components in applications. All we have to do is merely invoke the remote Web Service.

For instance, if we want to confirm the address that user inputs in our own applications, we can directly pass this address to relative Web Service to confirm it by looking up the street, city, country and zip code, etc. Web Service provider can charge for this service according to the using time and frequency. It is not practical to achieve this with traditional way, since users consequently have to download and install the database, which do not provide real-time data, containing all of the above address information.

Another case of software reuse is just like the example we give at the beginning of this chapter. Nowadays, there are many application suppliers who provide services such as traveling information query and ticket reservation. Once they expose those functions through Web Service, programmers can easily integrate all of which in a traveling website to provide a united and friendly interface to customers.

(10)

Hence, by integrating each kind of Web Service that we need, we can quickly solve problems which originally seem to be difficult to handle. Moreover, Web Service has depicted a new blueprint to the future of the software world, which enables the application to share its API to other applications through the window of Internet.

Nevertheless, even if Web Service is so convenient, it still has some bottlenecks.

First of all, Web Service is a “static” and “stateless” service. It means that Web Service is more likely to provide static service, such as the search service Amazon Web Service [1] provides, the key-word-search service Google provides, or the stock-price-enquiry service E*TRADE provides, which only enable users to extract the information but not to use dynamical service, such as editing or saving files, which interacts with users. This is because that Web Service does not have the concept of object instance. It is just like a Java class with many static methods. To provide dynamical service, Web Service has to record the state of each user, which can be achieved by adding a unique user id parameter on all methods. However, it requires the administration of user id controlled by users themselves, which is not suitable for public service. Therefore, if we want to provide a stateful service, Web Service is no longer capable. We need a new protocol to record user states more conveniently and to support dynamical service, which is so-called MOSP (Mesh Object Service Protocol.)

MOSP is a new network service protocol for distributed services. Its main character is that it is developed in object-oriented way with Java [25] language.

Similar to Web Service, it allows different services to exchange messages through XML-based document in distributed environment and simple services to integrate into a complex value-added service. The difference between them is that MOSP has the object-oriented concept, and each object instance represents an encapsulation of a state, the object instance each user holds will directly record the user state. The garbage collection of Java will delete the object instance no longer referenced, so we do not have to administer objects. Moreover, MOSP also uses the concept of inheritance, which together with object-oriented increase the convenience of development.

While using a MOSP service, the MOSP user will login from an integrated port user interface. Because of the transparency MOSP Service provides, the user will not notice the differences between the local and the remote side. One single service that a user uses might be integrated from a variety of remote services. Figure 1-1 is an example of MOSP environment presenting a file-saving service, which in fact is integrated from file service and storage service.

(11)

Figure 1-1: A Sample of MOSP Environment

We have mentioned the superiority of MOSP, and the contrast between MOSP and Web Service is listed below.

Take a book store and a shopping-cart service for example. Firstly, Figure 1-2 to Figure 1-4 show the differences between MOSP and Web Service in instance creation.

We use Java pseudo code to present it. The left side of the figure is the shopping-cart service, which contains Product and Cart class. The Cart class provides lots of operations for the user, the Book Store Inc. in right side of the figure, to get information of Cart through operation calls. Figure 1-2 shows that in the MOSP environment, user can create a Cart object instance, add different products into Cart, and get information of Cart through calling different operations of Cart. Cart object can thus record the shopping state of each user.

Figure 1-2: MOSP Shopping Cart Service – Object Instance Creation

(12)

However, Figure 1-3 shows that in the Web Service environment, we can not create an object instance. Consequently, different users will hold the same shopping cart while they use this service. In order to solve this and let different users manage their own shopping cart, we can use the way shown in Figure 1-4. The server provides a parameter id to present different instances and operations newCart() and

deleteCart() to create and delete id. Users can get a unique id and return it after usage from the code like this: int id = cart.newCart() and cart.deleteCart(id). This kind of method requires users to create and delete the instance themselves and thus does not apply to public service. Obviously, we can figure out that MOSP is more suitable for dealing with dynamical and stateful service, enables users not only to use the static search service but also to handle different objects in the service.

Figure 1-3: Web Service Shopping Cart Service

Figure 1-4: Web Service Shopping Cart Service – Instance Creation and Deletion

(13)

Secondly, Figure 1-5 and Figure 1-6 shows their difference in inheritance aspect.

Figure 1-5 shows that in MOSP environment, we can create a class Book which inherits from Product, and adds an operation ^getISBN() let users look up the ISBN of the book. So users can directly cast Product to Book to get its ISBN.

Figure 1-5: MOSP Shopping Cart Service – Inheritance

However, we can not use inheritance under Web Service environment. As Figure 1-6 shows, even if users copy the content of Product to Book and add a new parameter ISBN in Book, users can not cast Product to Book and get its ISBN.

Figure 1-6: Web Service Shopping Cart Service – Inheritance does not work here

(14)

Thirdly, Figure 1-7 to Figure 1-9 shows their difference in polymorphism aspect.

In MOSP environment, as Figure 1-7 shows, if users want to use dynamic price for each book: make a discount of 30% while the book is stocked for more than two years, they can use the polymorphism concept to override getPrice() to achieve this.

Figure 1-7: MOSP Shopping Cart Service – Polymorphism

However, in Web Service environment, showing in Figure 1-8, users can not override the price argument, since the lack of inheritance. Thus Web Service can not get such information of the new price as well.

Figure 1-8: Web Service Shopping Cart Service – Polymorphism does not work here

(15)

Another possible way to solve this problem, shown in Figure 1-9, is turning Book class into a new Web Service using ^getPrice() to represent dynamic price.

Unfortunately, Web Service can not be passed as an argument to another Web Service;

otherwise we have to build specific Web Services for all users. Hence this solution is also not capable.

Figure 1-9: Web Service Shopping Cart Service – try another way to Override

Lastly, Figure 1-10 and Figure 1-11 shows the situation of dynamic binding in MOSP and Web Service environment.

Figure 1-10: MOSP Shopping Cart Service – Dynamic Binding

(16)

Figure 1-10 shows how to enable users to make different discount for different clients. Because MOSP inheritance includes not only interface inheritance but also implementation inheritance, users can inherit the implementation details of parent class. To achieve this, all we have to do is just add an abstract operation

getDiscountRate() for users to implement, and users can easily adjust discount for each client on their demand.

However, if we want to achieve such dynamic binding requirement in Web Service environment, shown in Figure 1-11, we have to build a new Web Service for every single user to maintain getDiscountRate(), which is obviously very unpractical.

Figure 1-11: Web Service Shopping Cart Service – Dynamic Binding

(17)

In conclusion, we list the comparison between Web Service, Java and MOSP in Table 1-1. We can see that MOSP receives the advantages of Web Service and Java.

Web Service is a more independent service than MOSP. Each Web Service is a single individual, which does not depend on other service. MOSP services are more dependant, they may inherit from and reference to each others.

Web Services Java MOSP

Encapsulation Y Y Y

Polymorphism Y Y

Interface Inheritance Y Y

Implementation Inheritance Y Y

Function Overloading Y Y Y

Firewall Friendly Y Y

Instance Creation Y Y

Instance Lifetime Garbage

Collection Y

Table 1-1: Comparison between Web Service, JAVA and MOSP

1.2 Motivation

From the above section, we can see that MOSP is much more powerful and with more capability than Web Service. For the environment that server and client side have more interaction, MOSP fits better than Web Service. Even though MOSP seems to be better than Web Service, it is not yet that popular as Web Service.

We have known that Web Service is the most general SOA technology at present, and MOSP is relatively fresher and less-known technology. To promote MOSP, attract new users and make the old Web Service still available in new MOSP environment, we need to provide a gateway system to enable MOSP clients to call Web Services.

On developing this gateway system, we may face some challenges shown as follows:

(18)

1.2.1 Challenges

1.2.1.1 Different Data Types

Since the documents Web Service delivers are XML based, the data types we use also need to be accepted by XML Schema. We list XML Schema data types in Figure 1-12.

Figure 1-12: XML Schema Data Types [30]

XML Schema separates all data types into primitive types and complex types.

Primitive types are the subtypes of anySimpleType listed in Figure 1-12, and complex types are composed from multiple primitive types and complex types.

MOSP separates all data into three main data types: mt:/ref, mt:/val and

mt:/void. The characters behind slash represent subtype of the characters before it. If receivers can recognize the subtype, they can absolutely further understand the data type. For example, mt:/val/num represents numeric data, and mt:/val/num/int

shows that int is one of the numeric data types. When receiver can not recognize

mt:/val/num/int, they can take it as mt:/val/num or mt:/val data type.

(19)

Java mosp Java

// Special type

Array

#[]

(urt of base type)

Array

(use primitive base type when possible) org.mosp.OutArg OutArg.getType() (to corresponding java type)

(null value) mt:/void (null value)

// Reference type

org.mosp.Instance mt:/ref/mosp/interface org.mosp.Instance org.mosp.Creator mt:/ref/mosp/creater org.mosp.Creator org.mosp.Typedef mt:/ref/mosp/typedef org.mosp.Typedef

org.mosp.MeshObject mt:/ref/mosp org.mosp.MeshObject

java.net.URL mt:/ref/url java.net.URL

java.net.URI mt:/ref java.net.URI

// Value type

(string literal)

mt:/val/str java.lang.String java.lang.String

boolean

mt:/val/bool Boolean java.lang.Boolean

int

mt:/val/num/int int java.lang.Integer

double

mt:/val/num/double double java.lang.Double

float

mt:/val/num/float float java.lang.Float

long

mt:/val/num/long long java.lang.Long

short

mt:/val/num/short short java.lang.Short

byte

mt:/val/num/byte byte java.lang.Byte

java.lang.Number mt:/val/num (subclass of number based on data) char

mt:/val/char char java.lang.Character

org.mosp.Struct mt:/val/struct org.mosp.InStruct org.mosp.MidlDoc mt:/val/xml/midl org.mosp.MidlDoc

org.w3c.dom.Document mt:/val/xml org.w3c.dom.Document

byte[] mt:/val byte[]

Table 1-2: Java Types marshal to MOSP Data Types and unmarshal to Java Types

(20)

MOSP is developed from Java language, thus its data types are marshaled from Java data types. Table 1-2 lists the Java data types marshaling to MOSP data types and unmarshaling back to Java data types. The left columns lists Java types, the middle columns show the MOSP data types marshaled respectively from the Java data types in left columns, and the right columns represent the Java data types unmarshaled from MOSP data types. We can see that some Java types like java.lang.Integer will be lost during the marshaling and unmarshaling process. The detailed MOSP data types can be referred to in Section 2.2.2.

Compare MOSP data types with XML data types, we will discover that some XML data types, such as dateTime, time, date and so on do not exist in MOSP.

Therefore we need to define a transformation rule. Besides, the mt:/val/struct and array types (#[]) in MOSP represent the structure (composition of multiple structures and primitive types) and array (composition of one single type such as structure or primitive type), which can be transformed into XML complex types and array type respectively since they have similar ideas.

1.2.1.2 Parameter Passing (Marshalling)

While implementing the gateway which enables MOSP clients to call Web Service, we need to marshal one data type to another in order to describe the idea of data types in different environment or to transfer data through networks. This may cause some challenges, like how to transform one data type into another to deliver, and then transform it back into the original data type or near-original data type (the data type which performs just as the original one does).

1.2.1.3 Protocol Binding

The protocol bindings that Web Service uses are open. The binding protocol in most common use is SOAP binding. While facing different protocol binding of Web Service, not only the action it performs but also the user requirements may change from it. For example, if Web Service is transferred via e-mail (using MIME binding), the delay time may be longer, thus we have to adjust the timeout of the MOSP service.

How the MOSP service should perform each different action of Web Service while Web Service uses different bindings is also one of the challenges.

(21)

1.3 Research Goal

Solve Problems

Because of the difference between MOSP and Web Service, some problems and difficulties or even limitations may be brought about. We want to solve these kinds of problems.

Transparency

We want to reach transparency between MOSP and Web Service message passing, which means that users will not be aware of the transformation.

Efficiency

We do not want to lose efficiency while passing message between MOSP and Web Service.

Extensibility

We hope to provide a perfect and extensible system design to ease the future extension, such as interoperability between MOSP and RMI [22] or MOSP and CORBA [4].

(22)

Chapter 2 Related Work

2.1 Web Service

Web Service is composed of a series of standards and developing standards, which is establish and assigned to advance inter-platform language to language communication by World Wide Web Consortium (W3C [30].) Its definition to Web Service is as follows, “A Web service is a software system identified by a URI, whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by internet protocols.” More specifically, W3C has already formulate a model (Web Service Description Language, also known as WSDL [28]) and a procedure calling protocol (SOAP [27] API) as formal standards of Web Service.

Web Service Framework is shown in Figure 2-1, including XML [26], SOAP, WSDL and UDDI [17], and each will be introduced later. As the figure shows, SOAP, WSDL and UDDL are all described through XML. The processing model of Web Service is as follows: Firstly, we need to transform data into XML-based type. Then we use WSDL to describe the contents of service and make the receiver side understand the information of this service from which. Lastly, we use SOAP to transfer operation requests and responses. Also, we can use UDDL to search for or register a service.

Figure 2-1: Web Service Framework [30]

(23)

We can describe the Web Service Processing Model more specifically. As Figure 2-2 shows, Web Service Provider will describe its service with WSDL, and register to UDDI of Service Broker. UDDI is just like an index catalog, which Service Requester can inquire about the service it needs, and get a WSDL file to know the information of the Web Service which describes. When the Service Requester find the service it needs, it can directly communicate with Service Provider and use the services via SOAP messages passing.

Figure 2-2: Web Service Processing Model

Web Service is based on Web open standard, and the essentials of which are HTTP and XML. However, more standards are needed to build a complete Web Service. We introduce XML and those important standards based on XML as follows.

2.1.1 Extensible Markup Language (XML)

XML is a series of principles which allows its users to define tags and simplifies data access, processing, exchange and transforming. In a word, XML is a kind of language whose document format can be defined freely. XML itself is so-called hyper-language. Figure 2-3 is a simple example of an XML-format document representing a quiz.

Figure 2-3: A sample of an XML document

(24)

XML can cross different platforms, networks and languages. Before its showing up, every remote procedure call of message passing have to be accomplished through the communication protocol and API which are supported by both sides. XML provides better elasticity, whose open standards allow different systems to exchange data and communicate with each others. The applications build in different platforms and languages can interoperate by using XML. Web Service can combine services from XML interoperability and extensibility to provide more complex value-added services.

2.1.2 Simple Object Access Protocol (SOAP)

SOAP, as implied by its name, is a simple communication protocol which allows users to access objects in networks. SOAP use XML format together with other Internet protocols, like HTTP, SMTP and TCP, to transfer messages. SOAP messages of Web Service are usually transferred by HTTP so that SOAP messages can cross firewalls and support SSL.

SOAP is a lightweight data transfer protocol. Its way of passing data which can cross different platforms greatly simplifies information exchange in distributed environment. As long as both sides support SOAP, they can talk to each others. Thus SOAP becomes a great tool of Web Service to cross the platforms and languages.

SOAP message is transferred in Request/Response way which we familiar to. It also defines an XML framework to call an operation and pass the arguments of the operation. In the meantime, SOAP defines an XML framework to respond the return value or exceptions. However, SOAP does not define how do the sender and receiver send and receive messages, but let the developers to decide how to deal with it. SOAP does not define how the operation be implemented. In a word, SOAP leaves the implementation details to the developers.

Figure 2-4 is the architecture of SOAP Message. SOAP Envelope is a standard XML document, dividing into Header and Body. Header is used to define the SOAP contents, data types and codes; Body is used to transfer the contents of client side request or server side response, and SOAP Fault in Body is used to transfer the error messages. SOAP Message in fact is the document which packs the requests of senders and the responses of the receivers in XML format, and enables both sides to communicate with each others.

(25)

Figure 2-4: SOAP Architecture

Take an example in Figure 2-5 to describe how SOAP message works. Client wants to call addTwoNums() in Server through Internet. Client firstly composes a SOAP Message and sends it with HTTP as Figure 2-5 shows.

Figure 2-5: The sender transfers SOAP message

The message content which Client side sends is shown in Figure 2-6. The first line of it shows that the version of this XML document. The second line is the SOAP Envelope tag. The content “xmlns:SOAP=…” in this tag defines the prefix and namespace URL of SOAP. The third line is the tag of SOAP Body.

Between SOAP Envelope tag, there are tags with operation names (<addTwoNums>) and arguments (<FirstNumber> and <SecondNumber>.) The contents between argument tags (the 2 between <FirstNumber> and </FirstNumber>) in the argument values transferred to the operation. When Server receives this SOAP

(26)

message, it will call the operation with the arguments shown in this message (call operation addTwoNums(2, 6).) Then Server will produce a SOAP message to return the execution result to Client, as Figure 2-7 shows. The message contains the name of response and the return values.

1 <?xml version=“1.0” ?>

2 <SOAP:Envelope xmlns:SOAP=“urn:schemas-xmlsoap-org:soap.v1”>

3 <SOAP:Body>

4 <addTwoNums>

5 <FirstNumber> 2 </FirstNumber>

6 <SecondNumber> 6 </SecondNumber>

7 </addTwoNums>

8 </SOAP:Body>

9 </SOAP:Envelope>

Figure 2-6: The SOAP Message which Client sends

<?xml version=“1.0” ?>

<SOAP:Envelope xmlns:SOAP=“urn:schemas-xmlsoap-org:soap.v1”>

<SOAP:Body>

</addTwoNumsResponse>

</SOAP:Body>

</SOAP:Envelope>

Figure 2-7: The SOAP Message which Server responses

One of the advantages of SOAP is its simplicity. Users can easily enjoy the convenience it brings even if he/she does not have professional knowledge. SOAP also helps accomplishment of distributed system, which enables developers use software services others provide more easily.

2.1.3 Web Services Description Language (WSDL)

WSDL is also an XML format document, which is mainly used to describe the details of Web Service. It enables Web Service program a standard way to describe what abilities it has and how the clients use Web Service. The content it describes includes the Web Services and the operations the service provider provides, and how the service requests communicate with these Web Service operations, including transmission protocol, data types and arguments.

(27)

Figure 2-8 shows the standard architecture of WSDL document, which is developed by IBM and Microsoft.

Figure 2-8: WSDL document Architecture

In this figure, we can see that WSDL document includes two parts: Service Interface Definition and Service Implementation Definition. Service Interface Definition describes the interface of Web Service. Types is used to describe definitions of data types, which may come from all kinds of type systems. Message defines the arguments and types of input and output messages. PortType defines the operations of endpoints of this service. Binding defines the communication protocol and data format of each PortType. Service Implementation Definition describes the name of the service, the company which provides the service and the location of the service. Port represents an endpoint for users to communicate with the service, which will assign its binding and location. Service is the collection of all endpoints, which is the collection of all Web Services provided as well.

2.1.4 UDDI

(Universal Description, Discovery and Integration) UDDI [16] is a developing registration center and catalog standard. It is proposed as one of the core standards of Web Service at first. It is designed to provide SOAP message inquiry service and the access of WSDL, to let users get the information like service binding and data formats to interact with services in the catalog.

(28)

UDDI is also based on XML. It can not only let service providers register to it and announce the Web Services it provides, but also let service requesters get the Web Service they need with the search service it provides.

UDDI registration includes three components. White page is the basic information of the enterprises, such as addresses, contact information; yellow page is the standard classification of enterprises; green page is the technical information about the services enterprises provide.

2.2 Mesh Object Service Protocol (MOSP)

2.2.1 MOSP Service Architecture

Figure 2-9: MOSP Service Architecture

MOSP, like HTTP, is the network application layer protocol responsible for transferring data on the networks. Figure 2-9 describes MOSP Service architecture.

We can clearly observe the difference and similarity between MOSP and Web Service from this figure. First of all, MOSP service does not contain component like UDDI. In MOSP service, with the URL of a service, users can directly access the service and request for its MOSP Interface Definition Language (MIDL). MIDL, a little bit like but simpler than WSDL, is used to describe MOSP service. MIDL contains the operations and arguments which the MOSP service provides. Without SOAP Messages and HTTP Messages, MOSP service uses MOSP Messages to transfer data, such as the request/response messages of requesting for MIDL documents or operation calls, through networks.

(29)

Figure 2-10 shows the scenario that MOSP client and MOSP service exchange MOSP messages. Note that MOSP (DESC) represents the request for MIDL, and the response of it is a MOSP message containing MIDL; MOSP (CALL) represents the request for an operation call, and the response is a MOSP message containing the execution result of the operation call.

Figure 2-10: The exchange of MOSP request/response messages of service descriptions or service calls between MOSP client and MOSP service

2.2.2 MOSP Object Model

We list the main data types of MOSP in middle columns of Table 1-2. MOSP separates its data types to value type (mt:/val) and reference type (mt:/ref). The slash sign in each data types represents the inheritance relationship. That is to say, the string behind the slash sign represents the derived-type of the string before it. If the receivers can understand the meaning of the derived-type, they can thus get what this data type represents more clearly; otherwise, they can just deal with it as the base type.

For example, mt:/val/num/int/temp represents an integer temperature data type. If the receivers can not recognize this data type, they can just see it as an integer type (mt:/val/num/int) or even a numeric type (mt:/val/num.)

In MOSP environment, we name the nodes “Peer.” Every peer will be referred to by its location, noted as a MOSP URL, such as mosp://foo.com/. The MOSP service object of a peer, named “Mesh-Object,” is referred to by the MOSP URL of the peer and the path to it, such as mosp://foo.com/bar. Since MOSP is object-oriented, every mesh-object in MOSP environment is seen as a specific data type, represented by its MOSP URL. That is to say, mosp://foo.com/bar is a data type which can be accessed by any peer in MOSP. We class such data type as reference type. For example, if the argument data type is assigned as mt:/ref, we can put any data as an argument whose type belongs to reference type.

(30)

Moreover, MOSP contains the idea of inheritance. MOSP mesh-objects can not only access but also inherit from each others. This means that the mesh-object

mosp://foo.com/bar may inherit from mosp://zoo.com/abc, which inherit from

mosp://koo.com/xyz, and so on.

Table 1-2 also shows the data type marshaling and unmarshling process between MOSP data types and Java data types. We can discover that there exists some information loss situation. So in order to enable MOSP client to call Web Service, we need to define a marshaller to deal with the marshaling and unmarshaling among MOSP, Java and Web Service data types. Note that Web Service data types do not contain the concept of scoping like MOSP. Besides, there are some other differences among these three types, which may cause some limitations.

2.2.3 MOSP Interface Definition Language (MIDL)

Figure 1-1 shows a simple example of MIDL document. We can easily discover that MIDL architecture is much simpler and easier to read than WSDL, since it only contains operation and argument information, and combines operation and arguments together. The first line is the midl tag, which represents that it is an MIDL file. The op

tag in the second line represents the operations provided by this MOSP service; name

represents the operation name, and type represents the return type. The third line represents the input argument of this operation. Note that #[] represents MOSP array type, and st represents MOSP struct type, which can be referred to by a # sign and its name, such as #power shown in the fourth line. While implementing a MOSP service in Java, we only have to add a @Midl label before a class to announce it as a MOSP service and a @Op label before each operation open to MOSP clients.

1 <midl role="instance" xmlns="mt:/val/xml/midl">

2 <op name=“calculate” type=“mt:/val/int”>

3 <arg type=“mt:/val/int#[]” name=“intArray”>

4 <arg type=“#power” name=“powerOfNumbers”>

5 </op>

6 <st name=“power”>

7 <arg type=“mt:/val/int#[]” name=“powerArray”>

8 <arg type=“mt:/val/bool” name=“usePower”>

9 </st>

10 </midl>

Figure 2-11: A sample MIDL

(31)

2.2.4 MOSP Messages

We have described the exchange of MOSP messages between MOSP client and service in Figure 2-10. Web service uses HTTP message to pack SOAP message and transfer on networks, while MOSP considers that way too complicated and bothering, which makes messages become heavy and cause time-waste while unpacking them.

Hence MOSP merges HTTP message and SOAP message into a single message, which is so-called MOSP message. MOSP message passes data in plaintext form.

Figure 2-12: MOSP message framework

Figure 2-12 shows the MOSP message framework. The first line in MOSP message is the description of this message, such as operation call or response message.

Later part of MOSP message is the message header, which is optional, used to reveal some information such as operation name. The rest of the message is the data to transfer. The data content is described by a combination of a number representing the length of the data and then the data itself. Such combination may show up over and over in this part of MOSP message. 0 represents the end of this message, since 0

means that the length of the following data is 0. Information in this message is separated with a line feed.

Figure 2-13 and Figure 2-14 shows the request and response MOSP message while MOSP client requests for MIDL respectively. The first line in Figure 2-13 shows the MOSP version this message uses is MOSP 0.8, and DESC represents the request for the description of the service, MIDL. This message does not contain other information, thus 0 is used to represent the end of this message.

MOSP service uses an operation onDesc() with arguments InMsg and OutMsg to receive the MOSP description request message. Once the service receives MOSP description request message, it will be received as an InMsg object. Then service can pack the response message containing MIDL file as an OutMsg object to transfer.

(32)

Figure 2-14 is the response of the above request message from MOSP service.

200 is the standard response code (a similar idea with HTTP), and each number represents different meaning. OK is the meaning of the response code 200, which means that the receiver successfully resolves the receipt message and returns the correct result, which is the content of MIDL (in plaintext form) here. Other response codes such as 403 Forbidden, 404 Not Found, and so on, can be referred to in the RespCode class in MOSP source code.

Figure 2-13: MOSP client request for MIDL

Figure 2-14: MOSP service response of the MIDL request

Figure 2-15 and Figure 2-16 shows the request and response MOSP messages while MOSP client requests for an operation call respectively. In Figure 2-15, CALL

represents the request for an operation call to MOSP service, and /path/service

represents the location of the service in server peer. The message header Op:fun1

represents the operation which is called, and the input arguments are shown in the later message content. 3 represents the length of the value of the argument,

type=mt:/val/num/int represents the data type of the argument, and 123 represents the value of the argument.

MOSP service uses an operation ^onCall() with arguments InMsg and OutMsg to receive the MOSP operation call message. Once the service receives MOSP call message, it will be received as an InMsg object from which receiver can get Arg objects, which represent arguments, to get the data content. After the execution of the operation, service can pack the response message as an OutMsg object to transfer.

(33)

Figure 2-16 is the response of the above request message from MOSP service.

200 OK means that the receiver successfully resolves the receipt message, calls the operation and returns the correct result. 18 represents the length of return value, and

mosp://foo.com/xyz represents the data type of return value: mosp://bar.com/abc. From this message, we can also discover that object mosp://bar.com/abc inherits from mosp://foo.com/xyz. It is the concept of the inheritance on networks in MOSP.

Figure 2-15: MOSP client request message for an operation call

Figure 2-16: MOSP service response message of the operation call

(34)

2.3 Interoperation between CORBA and

Web Service

The Common Object Request Broker Architecture (CORBA) is a standard defined by the Object Management Group (OMG [21]) that enables software components written in multiple computer languages and running on multiple computers to work together. CORBA, a little bit similar to MOSP, also has the concept of object-oriented and inheritance. We can use the integration experience of CORBA and Web Service as consultation.

2.3.1 Common Object Request Broker Architecture ( CORBA )

CORBA was built by OMG in 1992, which is an open standard used on distributed objects. CORBA enables clients to call operations of remote objects, regardless of the language binding and locations of the objects.

Interaction between CORBA client and server is regulated by Object Request Brokers (ORBs) on both sides. CORBA client and server communicate through Internet Inter-ORB Protocol (IIOP) or General Inter-ORB Protocol (GIOP). CORBA objects can be on client side or server side without affecting the execution and use of it. The operations provided by CORBA objects are defined by Interface Definition Language (IDL). The operations defined on the interface will accept input arguments and get return values or exceptions.

The language CORBA supports includes C, C++, Java, Ada95 and COBOL, and some scripting languages like Perl, Python and JavaScript. Besides, CORBA is independent of operating systems, which can work on many platforms, such as Win32, UNIX and real-time embedded system. The communication protocols CORBA uses in ORB communication includes TCP/IP, IPX/SPX, ATM and so on.

Figure 2-17 shows the main components of CORBA reference model. These components provide portability, interoperability and transparency for CORBA.

(35)

Figure 2-17: Components in the CORBA 2.x Reference Model [2]

CORBA application life cycle is as follows:

1. Define the provided service interface in IDL.

2. Compile the IDL and create client stub and server skeletons.

3. Execute the service and connect it to skeletons with Object Adapter in Figure 2-17.

4. Publish this service with Naming Service or Trading Service.

The execution process of CORBA client is as follows:

1. Connect to the service with Naming Service and get object reference.

2. Create client stubs with IDL-compiler to call the operations of the object reference. Besides, client can also look up the operations the service provides in Interface Repository (IR), and dynamically generate request with Dynamic Invocation Interface (DII).

3. Deal with the responses or exceptions the server transferred.

(36)

Table 2-1 lists a comparison between Web Service and CORBA, from which we can see that even though these two systems use different technology, the idea and the architecture are similar. Table 2-2 lists the comparison of WSDL and IDL, and the transformation between them can be designed based on this table. Table 2-3 lists the comparison between XML schema and CORBA object model, we can refer to it as the comparison between XML schema and MOSP object model.

Item Web Services CORBA

Protocol SOAP, HTTP, XML, Schema IIOP, GIOP Location

Identifiers URLs IORs, URLs

Interface Spec. WSDL IDL

Naming,

Directory UDDI Naming Service, Interface

Repository, Trader Service Table 2-1: Comparison between Web Service and CORBA [10]

WSDL IDL

No mappings to programming

languages Mappings to many programming languages Describes mapping to

transport layer

Mapping to transport layer defined by CORBA specification

XML Schema “object model”

for XML documents

Object model for programming languages defined by CORBA specification Draft OMG standard, many implementations

Table 2-2: Comparison between WSDL and IDL [13]

XML Schema CORBA Object Model

Deriving by extension,

equivalence classes Multiple interface inheritance Defines elements and

attributes of instances

Defines objects, operations and operation parameters of instances

No stable validators yet Many IDL compiler implementations Table 2-3: Comparison between XML Schema and CORBA Object Model [13]

(37)

2.3.2 Gateway Systems between Web Service and CORBA

Since Web Service and CORBA have similar architecture, directly use Web Service to replace CORBA is not practical. We can just build the interoperability between Web Service and CORBA service by implementing the gateway service, which can transform SOAP and CORBA IIOP messages automatically. Present SOAP-CORBA gateway includes SCOAP [20], XORBA [23] and soap2corba bridge [24]. The actions gateway performs here are accepting SOAP requests, transferring it to CORBA server and transferring the return result to SOAP response.

SCOAP combines SOAP with CORBA by mapping CORBA IDL with Web Service SOAP, and its architectures are shown in Figure 2-18 and Figure 2-19, Generic SOAP/HTTP to IIOP Bridge and Static Dedicated SOAP/HTTP to IIOP Bridge respectively. The former translates SCOAP message into IIOP and transfer it to IIOP domain, as Figure 2-18 shows, and this kind of translation needs to use IR or IDL to generate the mapping, and SCOAP types mapping to IDL types can be referred to in [20], which can be returned only when IIOP message body is accessible in SCOAP body. The later regulates the access to arbitrary CORBA/SOAP servers, which can only bridge operations of specific interfaces.

Figure 2-18: Generic SOAP/HTTP to IIOP Bridge Diagram [20]

(38)

Figure 2-19: Static Dedicated SOAP/HTTP to SCOAP/ORB Bridge Diagram [20]

The above scenario shows how SOAP client interact with CORBA server through bridge. However, this interaction works only when SOAP and CORBA types are compatible. (For instance, there will be some problems when object reference is concerned.)

Figure 2-20: SOAP-CORBA Interoperability Interaction Model [20]

Figure 2-20 shows the interaction model between SOAP, SCOAP, CORBA clients and servers. SIM represents SOAP-IDL mapping, which plays the role to translate SOAP encoded arguments and messages to the format which system can

(39)

interpret. Arrows represents the interaction between entities, and the annotations on arrows shows the encoding technology used during interaction. We can see from this model that we can package CORBA with SOAP, which means Web Service. Thus CORBA can be transferred in Internet by tunneling with SOAP messages. Besides, SOAP and CORBA and communicate through IDL-SOAP mapping. We can design the mapping between MOSP and Web Service by referring to this model.

We show a simple IDL-SOAP mapping below. CORBA IDL type “boolean” is similar to SOAP type “SOAP:boolean”, so we can transfer it as follows:

boolean

↓

<simpleType

name=“boolean”

base=“SOAP:boolean”>

</simpleType>

We can transfer IDL struct type as follows:

struct Vector { long xcoord;

long ycoord;

long length;

short direction;

};

↓

<complexType name=“Vector”>

<element name=“xcoord” type=“SCOAP:long” />

</sequence>

</complexType>

We can see that data types of CORBA and MOSP are similar. The above mapping way may be feasible in MOSP-Web Service gateway.

(40)

Figure 2-21: XORBA Architecture [23]

XORBA, also known as XML-CORBA Link, is developed by Rogue Wave Software, shown in Figure 2-21. XORBA is a Generic SOAP to CORBA Bridge, using SOAP Envelope to transfer in network, which can translate SOAP request to IIOP request and translate IIOP response to SOAP response. CORBA interface will be translated to the sub-elements Interface in SOAP message header, as the interface shown in Figure 2-22 and the SOAP message header in Figure 2-23.

In XORBA, CORBA object reference can be represented as string format or URI in Naming Service, which solves the predicament that SCOAP can not use object reference. In MOSP, object reference is represented by its MOSP URL. However, MOSP contains the concept of implementation inheritance, while CORBA only supports interface inheritance. The situation in MOSP is not as simple as in CORBA.

Figure 2-22: IDL Fragment of a XORBA Message Example [13]

(41)

Figure 2-23: A Sample SOAP Request [13]

However, [7] proposed a more complete integration model referring to OMG standards. It adds a SOAP-CORBA gateway based on CORBA servant, completes the OMG standards and solves the performance bottleneck and single point of failure problems other gateways can not solve.

Firstly, two specifications [19] [18] of OMG about the interoperation between CORBA and WSDL/SOAP defines how IDL and WSDL/SOAP maps to each other.

However, these standards omitted the support of CORBA client to SOAP service, which can not satisfy the requirement overall. [6] considered the single way situation from CORBA client to Web Service, and accomplish the static transformation between WSDL and IDL according to OMG specifications. However, the gateway it proposed can only be arranged at relative ORB server side, which will cause performance bottleneck and single point of failure problem at ORB server side.

The Proxy service proposed in [9] supports CORBA client to call CORBA service through Internet. However, there is only one proxy service responsible for the translation between SOAP and CORBA, which thus becomes the performance bottleneck of the entire system, and causes the single point of failure problem.

[7] proposed an overall solution, an Integration Model, which can solve the above problems, shown in Figure 2-24. This model provides two types of gateways:

the CORBA-SOAP gateway is responsible for packing CORBA service into standard Web Service form; the SOAP-CORBA gateway is the part not concerned in OMG specification, which enables pure CORBA client access Web Service without any modifications. The mapping in this figure is responsible for translating IDL and WSDL documents, assigning the result to the relative repository in each domain, and saving a copy with relationships and attachments, such as the relationship between CORBA Interoperable Object Reference and Web Service Endpoint, in the original message repository, since IDL and WSDL focuses on different points.

(42)

CORBA-SOAP gateway is like a standard CORBA service object servant in CORBA domain, every translation and method of calling service is packaged in implementation. CORBA clients and servers do not have to change. This kind of design not only solves the problems of performance bottleneck and single point of failure but also balances the loading of the entire system.

The process of service call in SOAP-CORBA gateway can be described by a simple example. Firstly maps WSDL to IDL. Then saves the IDL document and the attachments to CORBA Interface Pool, and saves information related to implementation, such as Endpoint, to CORAB Implementation Pool. CORBA developer can implement the service depends on this IDL document, and register service object implementation information in CORBA Naming/Trading Service.

CORBA clients can statically request with DII through the client stub compiled from IDL document. For CORBA client, this process is not much different from calling other CORBA service objects.

Figure 2-24: CORBA/SOAP Integration Model [7]

(43)

2.4 Brief Summary

Based on the earlier studies, we can make a brief summary. Firstly, Web Service provides a systemized and extensible architecture through the open standards of network communication protocols and data formats. Its main purpose is to simplify the integration of applications from different platforms in distributed systems. Web service is composed of three main components: SOAP, WSDL and UDDL, which all use XML format based on its open standard.

SOAP plays a role as the request message that Web Service client used to call Web Service and the response message the server returns to client. That is to say, SOAP is the message about service operation call and response. SOAP can easily fit the user needs for its convenient and simple architecture. WSDL is the document enabling Web Service applications describe itself with a standardize way, including the operations, protocol bindings, arguments and data types. UDDI is like a catalog of Web Services to which Web Service providers can register and publish its Web Services, and on which service requesters can search for services, get WSDL documents they need, and invoke the services as well.

A brand new protocol, MOSP, was born for the needs which Web Service can not satisfy. A great difference of MOSP from Web Service is the concept of object-oriented, inheritance and the dependence relationship between MOSP services.

MOSP is stateful, it can record user states with object instances, thus can provide more complex and interactive services to users. It is hardly possible to transfer Web Service, which is independent, to MOSP service, which is interdependent.

CORBA is similar to MOSP since they both have the concept of object-oriented and inheritance. Note that CORBA inheritance is limited to interface inheritance, while MOSP enables implementation inheritance. We discussed some studies of the gateway between Web Service and CORBA.

SCOAP contains two models of publishing CORBA/SOAP service at server side:

Generic SOAP/HTTP to IIOP Bridge and Static Dedicated SOAP/HTTP to IIOP Bridge. The former translates SCOAP message to IIOP and transfers it to IIOP domain, while the later regulates the access to arbitrary CORBA/SOAP server focusing on operations of specific interfaces. We can use the IDL-SOAP mapping in SCOAP as a reference for the data type mapping between MOSP and Web Service.

(44)

XORBA, XML-CORBA Link, is a Generic SOAP to CORBA Bridge, which uses SOAP Envelop to transfer in networks, translates SOAP request to IIOP request, and vice versa. The information of CORBA interface will be attached in SOAP message header, and CORBA object reference can be represented as string format or URI in the Naming Service, which solves the predicament that SCOAP can not use object reference.

Lastly, we mentioned a CORBA/SOAP Integration Model which combines OMG official specification and old gateway systems. It completes the OMG standards, which supports CORBA client calling SOAP service, and solves the performance bottleneck and single point of failure problems of old gateway systems. This system provides bidirectional gateway system, one is the CORBA-SOAP gateway which fits OMG specification, and the other is the SOAP-CORBA gateway. The concept of this system model and the benefit of load balancing can be a great prototype to build the gateway system between MOSP and Web Service.

(45)

Chapter 3 System Design

3.1 System Overview

3.1.1 Concept of MOSP Service

Figure 3-1: How a MOSP Service works

To introduce the architecture of our gateway system which enables MOSP clients to call Web Service, we need to start with the architecture of MOSP service. In MOSP environment, every node is called a Peer. Each peer may be a MOSP client or server.

As Figure 3-1 shows, the peer in this figure plays the role as a MOSP server, and each MOSP server contains a ServiceRoot, which contains many MOSP Service objects. Each MOSP Service object refers to one specific path to the MOSP server.

ServiceRoot represents the entrance point of each server, like the root of a service tree.

When the clients request for services, they will enter the tree from ServiceRoot and search for the services they need.

When a MOSP server peer starts, and opens a port (say, port:9000), the peer will be located to its specific MOSP URL (a link starts with ^mosp://, just as HTTP URL).

MOSP clients can get a MeshObject representing a MOSP server by binding to the peer through its MOSP URL, and use the provided services through this MeshObject.

If MOSP server peers want to provide some services, they can just add the service objects and the paths of the service objects to their ServiceRoot.

(46)

When MOSP clients want to use the services that MOSP servers provide, they can get a MeshObject object instance of each service from its MOSP URL (the MOSP URL of its server plus its path), and perform the actions directly to the object instance.

For example, get the MIDL document of a MOSP service by getMidl() operation of the object instance, or call the MOSP service by call() operation.