Applications of WebService and remoting in Distributed Programs

WebService and remoting are distributedProgramApplication in

1 ,. net remoting uses httpchannel and can use HTTP protocol in the same way as WebService, for example, passthrough firewall, but WebService is a cross-platform, Java and.. Net can provide and reference each other's WebService ,. net remoting is limited.. NET platform. I think. Net remoting is more practical than Web service at this stage.
2. remoting is stateful and tightly coupled; web services are stateless and loosely coupled; In general, remoting is suitable for local area networks that require high performance and response efficiency; web services are suitable for cross-network and cross-system scenarios with high requirements on portability and versatility. remoting and Web services are not strictly related to the EJB technology of J2EE, if the comparison is required, it is deployed on COM +/MTS. the net remoting component can correspond to EJB. Fairly speaking, the structure of DOTNET in enterprise-level applications is still incomplete.
3,

Remoting is definitely better than Web Services in the LAN. It uses the TCP pipeline to transmit data without losing sight, thus reducing serialization and deserialization. Of course, when using Web Services, A computer stores 32-bit integers in a different way than another computer. Therefore, an easy-to-understand format like XML is required. Web services are executed by IIS, while remoting is highly scalable. Using HTTP channels and XML can be part of Web Services technology. The key to each advantage is its understanding at the bottom, it will only be useless
4. There is Article I forgot where to find it. Please forgive me.
Abstract: understand Microsoft. net remoting infrastructure and Microsoft ASP. net web services, learn how these two technologies work, and how to select the appropriate technology for your applications.
Directory
Overview
Serialization and metadata
Distributed Application Design: ASP. NET web service and. Net remoting
Select Architecture
Summary
Overview
Over time, it has formed a convention that builds applications into a group of components distributed across computer networks and runs together as part of the entire program. In the past, distributed application logic required component/object technologies, such as Microsoft? Distributed Component Object Model (DCOM), Common Object Request proxy architecture (CORBA) of Object Management Group, or remote method call (RMI) of sun ). These technologies provide a reliable and scalable architecture to meet the growing needs of applications.
Although these component-based technologies run well in the Intranet environment, if you try to apply them to the Internet, there will be two major problems. First, these technologies cannot interact with each other. Although these technologies can process objects, the details are different. For example, lifecycle management, support for constructors, and support for inheritance. Second, more importantly, they all focus on RPC communication, which usually builds a tightly coupled system around explicit calls to object methods.
On the contrary, browser-based web applications are loosely coupled with strong interoperability. They use HTTP for communication and exchange many mime-type data in different formats. Web services make traditional WEB programming models suitable for various applications, not just browser-based applications. They use HTTP and other Internet protocols to exchange soap messages. Because Web services rely on HTTP, XML, SOAP, WSDL, and other industry standards to display the functions of applications on the Internet, they are independent Programming Language , Platform, and device.

The basic structure of ASP. NET Web Services provides simple APIs for Web Services by ing soap messages to method calls. This mechanism is implemented by providing a very simple programming model (based on ing SOAP message exchange to method calls. Clients of ASP. NET web services do not need to understand the platform, object model, or programming language used to create them. Services do not need to know the clients that send messages to them. The only requirement is that both parties should recognize the SOAP message format being created and used, which is composed of the WSDL and XML architecture (XSD) web Service Contract definition.
. Net remoting provides a basic structure for distributed objects. It uses flexible and scalable pipelines to provide full object semantics of. Net to remote processes. ASP. NET Web Service provides a very simple programming model based on message transmission. net remoting provides complex functions, including passing objects, callbacks, and multi-object activation and lifecycle management policies through values or references. To use. Net remoting, the client needs to understand all the details. In short, you need to use. Net to create a client. (Or use other frameworks that support. Net remoting. the only framework we know is intrinsyc's Ja. Net for Java .). The net remoting pipeline also supports soap messages, but note that this does not change the client requirements. If the remoting endpoint provides. Net-specific object semantics, the client must understand them whether or not they are using soap.
. NET Framework supports two completely different distributed programming models-Web Services and distributed objects, which creates great confusion for developers. When should the system use ASP. NET web services and. Net remoting be used? To answer this question, you must understand the working principles of these two technologies.
Serialization and metadata
All the distributed communication pipelines finally complete two tasks: Mail Program Data-type instances to messages that can be transmitted over the network, and provide descriptions of those messages. The former is completed using a certain form of serialization engine (or called the mail collector), and the latter is completed through some form of metadata. For example, for most (modern) DCOM interfaces, the serialization engine is a type library blocker, while the Type Library provides metadata. The main difference between ASP. NET web services and. Net remoting is how they serialize data into messages and the format they select for metadata.
ASP. NET web service, xmlserializer, and XSD
ASP. NET web services depend on the system. xml. serialization. xmlserializer class. data is sent to and from soap messages during runtime. For metadata, they generate the WSDL and XSD definitions to describe the content contained in the message. Fully dependent on WSDL and XSD To Make ASP. net web service metadata is portable. It represents the data structure method and can be understood by other Web Service toolkit that use different programming models on different platforms. In some cases, this limits the type that can be provided from the Web Service-xmlserializer can only send data that can be represented by XSD. That is to say, xmlserializer will not be able to block object images, and it has limited support for container types.
Although these limitations seem important from the perspective of traditional distributed objects, they help to ensure interoperability with other Web service frameworks-this is the basic goal of a loosely coupled web service model. A large number of custom attributes enable you to annotate data types to control how xmlserializer blocks them, thus enhancing interoperability. Therefore, you can carefully control the XML shape generated when the object is serialized. In addition, you can adjust ASP. Net-based web services to describe messages using text XSD or soap Encoding Rules (that is, soap section 5. Text XSD is the default and will become a standard in the future. It also supports soap encoding to facilitate interoperability with existing toolkit. This is very helpful to users, especially when users need to communicate with existing web services or clients (they need to communicate with predefined message formats.
. Net remoting, iformatter, and public Language Runtime Library
. Net remoting depends on the insertable Implementation Program of the iformatter interface used by the system. runtime. serialization engine to send data to/from messages. There are two standard formatting programs: system. runtime. serialization. formatters. Binary. binaryformatter and system. runtime. serialization. formatters. Soap. soapformatter. As the name implies, binaryformatter and soapformatter are respectively delivered in binary and soap formats. For metadata,. Net remoting depends on the set of common language runtime libraries that contain all the information about the data types they implement and provide it through reflection. For metadata, relying on the Assembly makes it easier to retain the system fidelity of the full runtime type. Therefore, when. when the net remoting pipeline sends data, it includes all the public and proprietary members in the class, correctly processes object graphics and supports all container types (such as system. collections. hashtable ). However, the dependency on runtime metadata also limits the scope of use of the. NET remoting system-the client must understand the. NET structure to communicate with the. NET remoting endpoint. In addition to the pluggable formatting program, the. NET remoting layer also supports the pluggable channel, which removes the details about the message sending method. There are two standard channels, one for original TCP and the other for HTTP. Messages can be sent through any channel independently of the format.
Advantages and disadvantages: remoting and Web Services
The existence of the soap formatting program and the HTTP Channel produces the following problem: Can I use. Net remoting to create a web service? The answer is yes and no. The standard Web Service technology stack depends not only on soap-based messages, but also on the description of messages based on WSDL and XSD. The remoting pipeline can truly generate the WSDL definition that describes the messages generated and used by the endpoint. However, if you follow this idea, several problems will arise.
First, the generated WSDL file always uses soap encoding rules instead of text XSD to describe the message. Although this is not a problem, as more and more tools focus entirely on the architecture, this problem will become more and more serious.
Second, the generated WSDL file includes the extension function dedicated to. Net remoting. For example, the following is a simple class that uses. Net remoting to provide its behavior.
Public class Methods: marshalbyrefobject
{
// The now method returns the current date and time.
Public String now ()
{
Return System. datetime. Now. tostring ();
}
}
If the WSDL is generated from this class, the binding information will include detailed information dedicated to. Net remoting, as shown below.
<Binding name = 'methodsbinding 'Type = 'ns0: methodsporttype'>
<Soap: Binding style = 'rpc'
Transport = 'HTTP: // schemas.xmlsoap.org/soap/http'/>
<Suds: class type = 'ns0: Methods 'roottype = 'externalbyrefobobject'>
</Suds: Class>
<Operation name = 'now '>
<Soap: Operation soapaction =
'Http: // schemas.microsoft.com/clr/nsassem/remsoap.methods/methods?now'/>
<Suds: Method attributes = 'public'/>
<Input name = 'nowrequest'>... </input>
<Output name = 'nowresponse'>... </output>
</Operation>
</Binding>
These additional elements are valid because the WSDL specification supports scalability. Any well-functioning Web Service toolkit will simply ignore them if they are not understood. However, some Web Service toolkit cannot be ignored. For example, the following is a response to Microsoft? The remoting endpoint of ADO. Net System. Data. dataset.
Public class Methods: marshalbyrefobject
{
Public System. Data. dataset getemptydataset ()
{
Return new system. Data. dataset ();
}
}
The following is the WSDL definition generated for the output message of this method:
<Message name = 'Methods. getemptydatasetoutput'>
<Part name = 'Return 'Type = 'ns3: DataSet '/>
</Message>
Generally, a wsdl message refers to the type defined in a specific namespace using the XML architecture. In this case, NS3 is not defined in XSD, but is implicitly defined at runtime. In this example, the prefix NS3 should be bound to the XML namespace determined by the following URI:
Http://schemas.microsoft.com/clr/nsassem/System.Data/System.Data%2C%20Version%3D1.0.3300.0%2C%20Culture%3Dneutral%2C%20PublicKeyToken%3Db77a5c561934e089
The client defined by this WSDL wants to understand the special meaning of this "well-known" URI-it is the strict name (consisting of four parts) of a specific runtime Assembly included in the. NET Framework ). This type of WSDL is very useful for clients implemented using. Net remoting, because they can generate a proxy assembly using messages suitable for sending. However, for other Web Service toolkits (including ASP. NET) that do not understand this Uri and want to find schema definitions for the dataset type, such WSDL will be useless.
The problem persists: Can I use. Net remoting to create a web service? Strictly speaking, yes. However, can people who do not use the. NET remoting pipeline use them? The answer is: Maybe you can, if you are careful to reduce the endpoint to the basic data type and semantics. That is to say, if you want to interoperate with other Web Service toolkit, You need to restrict the parameters to the built-in simple type and your own data type (the dataset type cannot be used.. NET Framework type), and avoid objects and events activated by the client. In short, if you are concerned about the scope of use, you need to restrict yourself to those functions supported by ASP. NET web services.
Or take a better way to use ASP. NET web services, because this is exactly the purpose of designing them.
ASP. NET web service or. NET remoting: How to Choose (2)
Distributed Application Design: ASP. NET web service and. Net remoting
ASP. NET Web Service supports the XML architecture type system and provides a simple programming model, which is widely used and can be used across platforms .. Net remoting supports runtime systems and provides complex programming models with narrow application scope. This essential difference is the main factor that determines which technology to use. However, there are many other design factors to consider, including transport protocols, host processes, security, performance, status management, and transaction support.
Transmission protocol and host process
Although the SOAP specification does not require HTTP as the transmission protocol, the client can only access ASP through HTTP. net web service, because it is an ASP. net supports the only transmission protocol. The service is called through IIS and executed in ASP. NET's auxiliary process aspnet_wp.exe.
. Net remoting allows you to flexibly host remote objects in any type of applications (including Windows Forms, hosted Windows Services, console applications, or ASP. NET auxiliary processes. As described earlier,. Net remoting provides two transmission channels-TCP and HTTP. Both channels can use sockets to provide communication between any sending and receiving processes.

It can also integrate the HTTP channel with IIS and ASP. NET auxiliary processes. This is important for the following reasons. First, it is the only way to automatically start the. NET remoting endpoint when the client requests arrive .. The net remoting pipeline does not include the DCOM-type Service Control Manager (SCM) required to start the remote server ). If remote objects are provided from any process, ensure that those processes are running. Also ensure that they are thread-safe. For example, after thread B is started to close the process, thread a cannot activate the object. If you provide remote objects from ASP. NET, you can use the aspnet_wp.exe auxiliary process to enable automatic start and thread security. Second, integration with IIS is the only way to ensure cross-process. Net remoting calls, as described in the following section.
ASP. NET web services and. Net remoting infrastructures are scalable. You can filter inbound and outbound messages to control the generation of type messages and metadata. With. Net remoting, you can also implement your own formatting programs and channels.
Security
Because ASP. NET web services depend on HTTP, they are integrated with the standard Internet security infrastructure. ASP. NET uses the security features of IIS to provide standard HTTP verification solutions (including basic, brief, digital certificates, and even Microsoft? . NET Passport) provides strong support. (Windows integration verification can also be used, but can only be used to trust clients in the domain .) One advantage of using the available HTTP authentication scheme is that you do not need to change Code IIS performs authentication before ASP. NET web services are called. ASP. NET also supports. NET Passport-based authentication and other custom authentication schemes. ASP. NET supports access control based on the target URL, and supports access control through integration with the. NET code access security (CAS) infrastructure. SSL can be used to ensure communication security.
Although these standard transmission technologies are quite effective in ensuring web services, they can only do so. When multiple web services in different trust domains are involved, you must create custom special solutions. Microsoft and other companies are working to create a Security Specification that provides message-level security functions based on the scalability of soap messages. One of these specifications is the XML Web Service Security Language (WS-Security [English]), which defines the framework for message-level credential transmission, message integrity, and message confidentiality.
As described in the previous section, the. NET remoting pipeline generally does not ensure the security of cross-process calls. Using ASP. NET to host. Net remoting endpoints in IIS, you can use all the security features available for ASP. NET web services, including support for SSL to ensure the security of wired communication. If you are using a TCP channel or HTTP channel (instead of aspnet_wp.exe) hosted in a process, you must perform authentication, authorization, and confidentiality on your own.
Another security issue to be concerned is the ability to execute code in an environment that is not fully trusted without changing the default security policy. ASP. NET web service client proxy can work in these environments, but. Net remoting proxy cannot. Special serialization permissions are required to use the. NET remoting proxy in an environment that is never fully trusted. By default, this permission is not granted to code downloaded from the Intranet or the Internet. If you want to use the. NET remoting client in an environment that is not fully trusted, you need to change the default security policy for the code loaded from those regions. When you connect to the system from a client running in a sandbox (such as a downloaded Windows Forms Application), ASP. NET web services are a simple choice because security policies do not need to be changed.
Status Management
By default, the ASP. NET web service model adopts a stateless service architecture. It is not instinctively related to multiple calls from the same user. In addition, each time the client calls the ASP. NET web service, a new object is created to serve the request. After the method is called, the object is destroyed. To maintain the status between requests, you can use the technology used by the ASP. NET page (that is, the session and application property package) or execute a custom solution.

. Net remoting supports many state management options and may be related to or irrelevant to multiple calls from the same user, depending on the object lifecycle architecture you have selected. The singlecall object is stateless (for example, used to call ASP. net web service object). The singleton object shares the status of all clients, the objects activated by the client are kept in the State on the basis of each client (with all related issues of scalability and reliability ).
Performance
In terms of raw performance, the. NET remoting pipeline can provide the fastest communication when using TCP channels and binary formatting programs. In our comparison ASP.. NET web service and. in almost all tests of net remoting's relative performance, Asp. the performance of the Net web service exceeds that of the soap formatting program using HTTP or TCP channels. net remoting endpoint. More interestingly, the performance of ASP. NET and. Net remoting endpoints using the binary formatting program is very similar to that of the HTTP channel. For more information, see Performance Comparison:. Net remoting and ASP. NET web services.
Enterprise Services
ASP. NET web services or objects provided through. Net remoting can use local transactions to coordinate work based on a single database. If you need to coordinate work based on multiple resources, it can use. NET Enterprise Services (also known as COM +) published transactions (DTC distributed transactions managed by COM + pipeline ). However, ASP. NET web services and. Net remoting pipelines cannot spread published transactions. Therefore, neither of these endpoints can inherit published transactions through cross-process calls.
This is not necessarily a bad thing. In general, published transactions are more costly than local transactions, and published transactions need to be spread across processes at a higher cost. If you really need this feature, the simple solution is in.. NET Enterprise Service server application. enterpriseservices. classes derived from servicedcomponent (for more information, see COM + Integration: How. NET Enterprise Services can help you build distributed applications [English]). Cross-process calls to such objects are processed using DCOM to ensure correct propagation of the transaction environment. The more difficult solution is to use the underlying API to manually spread distributed transactions.
It is worth noting that the traditional distributed transaction model is generally not applicable to loosely coupled Web Services. The model based on compensation transactions (that is, revoking the transactions submitted by other firms) is more meaningful because the isolation constraints are not very strict. There is a common saying among web service providers, including Microsoft, that is, the more flexible the transaction model is required by the web service space, the more work is done in the space. When you define a standard method for Web service transactions, you can use local or published transactions as needed to implement your own compensation architecture.
Select Architecture
If you are designing a. Net-based distributed application, consider all the issues discussed in this article and draw some conclusions on the expected results of the system architecture. Generally, this is easier than you think. However, there are always some special situations that require other methods. The following are some general assumptions you can make to simplify the situation.
First, ASP. NET web services are used by default. They are easy to execute and use. They can be used as wide as possible for the client platform, and can be called from the code running in the sandbox of the default security policy.. NET web service client proxy code.
If you want to use a traditional distributed object model with CLR type fidelity, you do not need to interoperate with other platforms, and you have control over the client and server configurations, consider using. Net remoting. If you select. Net remoting, it is best to integrate the HTTP channel with IIS and ASP. NET. Otherwise, you must establish your own process lifecycle management and security infrastructure. Assuming that. Net remoting requires a. Net client, it makes sense to use a binary formatting program instead of a soap formatting program. Interoperability will not be a problem and performance will be significantly improved.
Finally, if you want to publish a transaction, use the Enterprise Service (COM + ). If you execute servicedcomponents, they are deployed in the library application by default for performance considerations. If they need to run on a remote computer, deploy them in the server application. (If you need to execute different process security tokens [instead of the token used by aspnet_wp.exe] Code, even on the same computer, you may also need to consider using the COM + server application .)
The following are three public architecture based on these concepts.
Figure 1 shows a simple layer-3 architecture with a web server domain that supports a series of different clients. All server-side code is executed in ASP. NET's auxiliary process aspnet_wp.exe. These three different types of clients can use HTTP to access the server domain. Browser-based clients call ASP. NET web pages. Multiple Clients (such as Windows Forms applications, Microsoft? Visual Basic? 6 applications) and other Web services use ASP.. NET web service ,.. Net multi-client (such as Windows Forms applications) and Web services use ASP.. NET web service, or use the HTTP channel and binary formatting program. net remoting (assuming it is not in the sandbox ).
Figure 2: using the n-layer architecture of ASP. NET
Some very large applications use a set of computers to share their work from the outer layer of the Web server. This architecture 2 shows. In this case, the second layer also provides functions through ASP. NET.
Figure 3: using the n-layer architecture of Enterprise Service (COM +)
Figure 3 shows another version of this architecture. Its second layer uses the servicedcomponents deployed in COM + to provide functionality.
Obviously, these are not all possible architectures supported by. NET Framework. However, it provides an appropriate basis for you to design your own system.
Summary
Although both the. NET remoting infrastructure and ASP. NET web services can communicate across processes, each design is applicable to different users. The Programming Model of ASP. NET web service is very simple and widely used .. The Programming Model of net remoting is complex and has a narrow application range. Be sure to understand how these two technologies work and select the technology that suits your application. In either case, IIS and ASP. NET are used to manage the process lifecycle and provide general security.
I don't know if anyone has used it in the project. Anyway, I just used COM +.
However, in my own learning connection, I think remoting seems to be a simpler DCOM, and WS should treat it
The publishing tool of COM + component functions on the Internet does not feel the position of WS in distributed applications at this stage.
Of course, WS transmit data in XML format and adopt a standard message response mechanism, which makes the versatility very strong. While remoting only
It can be used in the ms.net framework.