Me It

Generated by Foxit PDF Creator Foxit Software http://www.foxitsoftware.com For evaluation only.
1. Overview of CORBA Services

Collections of system-level services packaged with IDL-specified interfaces are called CORBA services. They are used to augment and complement the functionality of the ORB. OMG has published standards for sixteen object services: The Life Cycle Service defines operations for creating, copying, moving and deleting components on the bus. The Persistence Service provides a single interface for storing components persistently on a variety of storage servers, including Object Databases (ODBMS), Relational Databases (RDBMSs), and simple files. The Naming Service components on the bus to locate other components by name; it also supports federated naming contexts. The service also allows objects of be bound to existing network directories or naming contexts, including ISO's X. 500, OSF's DCE, Sun's NIS+ etc. The Event Service allows components on the bus to dynamically register or unregister their interest in specific events. The service defines a well-known object called an event channel that collects and distributes events among components that know nothing of each other. The Concurrency Control Service provides a lock manager that can obtain locks on behalf of either transactions or threads. The Transaction Service provides two-phase commit coordination among recoverable components using either flat or nested transactions. The Relationship Service provides a way to create dynamic associations between components that know nothing or each other. It also provides mechanisms for traversing the links that group these components. You can use the service to enforce referential integrity constraints, track containment relationships, and for any type of linkage among components. The Externalization Service provides a standard way for getting data into and out of a component using a stream-like mechanism. The Query Service provides query operations for objects. It is a superset of SQL. It is base on the upcoming SQL3 specification and the Object Database Management Group's (ODMG) Object Query Language (OQL). The Licensing Service provides operations for metering the use of components to ensure fair compensation for use. The service supports any model of usage control at any point in a component's life cycle. It supports charging per session, per node, per instance creation and per site. The Properties Service provides operations that let developers associate named values (or properties) with any components. Using this service, the properties can be associated with a component's state, e. g. a title or date. The Time Service provides interface for synchronizing time in a distributed object environment. It also provides operations for defining and managing time-triggered events.
The Security Service provides a complete framework for distributed object security. It supports authentication, access control lists, confidentiality and non-repudiation. It also manages the delegation of credentials between objects. The Trader Service provides a "Yellow Pages" for objects; it allows objects to publicize their services and bid for jobs. The Collection Service provides CORBA interfaces to generically create and manipulate the most common collections. The Startup Service enables requests to automatically start up when an ORB is invoked.
2. CORBA Component Model The CORBA Component Model (CCM) is a specification for creating server-side scalable, languageneutral, transactional, multi-user and secure enterprise-level applications. It provides a consistent component architecture framework for creating distributed n-tier middleware. A typical CCM Architecture consists of CCM Containers, CORBA components that run in these containers, the Portable Object Adapter (POA), the Object Request Broker (ORB) other CORBA object services like CORBA Transactions, CORBA Security, CORBA Persistence, CORBA Events, etc...
In a typical development and deployment scenario, there will be an Application server provider who creates and sells an Application server along with CCM containers that will run on these servers. Then there will be the CCM providers-people responsible for developing CORBA components and the Application assemblers-people that use pre-built CORBA components to build their applications.
Fig. 7.2 CCM Components
Application Servers : These provide the system services like a raw execution environment, multiprocessing, load-balancing, device access, provide naming and transaction services and make containers visible. CCM Containers : These act as the interface between a CORBA component and the outside world. A CCM client never accesses a CORBA component directly. Any component access is done through container-generated methods which in turn invoke the component's methods. There are basically two basic types of containers. They are transient containers that may contain transient, non-persistent components whose states are not saved at all and persistent containers that contain persistent components whose states are saved between invocations. Depending upon the types of components that they can execute, CCM Containers may be divided into: Service containers, Session containers, Entity containers, and Other containers CCM Clients : These make use of the CCM components for their operations. They find the CCM container that contains the component through COSNaming and create, or obtain a reference to the component's container through the component's Home Interface. They then make use of the CCM Container to invoke the component methods. CCM Components: CCM components can expose multiple interfaces. While defining the IDL for each component, the interfaces that it provides and the interfaces that it uses have to be specified. Similarly, the events that it emits (or publishes) and the events that it consumes have to be defined in the IDL. The interfaces that it provides are called facets. The ability to use an interface is facilitated by declaring it as a receptacle. Event emission and publication declarations are used to define an event source. Event consumption declarations are used to describe event sinks. Facets, receptacles, event sources and event sinks are collectively called Ports. There are four types of CCM components. They are: Service components, Session components, Process components and Entity components
Service Components: Each Service component is usually associated with one CCM Client and it's lifetime is restricted to that of one single operation request (or a single method call) . Each Service component is created and destroyed by the particular CCM Client that it is associated with. Service components do not survive a System shutdown.
Session Components: Each Session component is usually associated with one CCM Client. Each Session component is created and destroyed by the particular CCM Client that it is associated with. A Session component can either have states or they can be stateless. However, Session components do not survive a System shutdown. A Session component is very similar to a Session EJB. Process Components: Process components always have states. Each Process component may however be shared by multiple CCM Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns. Entity Components: Entity components always have states. Each Entity component may however be shared by multiple CCM Clients. Their states can be persisted and stored across multiple invocations. Hence they can survive System Shutdowns. Each Entity component can be uniquely identified by its Primary Key. An Entity component is very similar to an Entity EJB. One of the major differences between Process and Entity components are that while the Entity component has a Primary Key to uniquely be identified by the client, a Process component does not expose its identity to the client except through user-defined operations. While Entity Components are used to represent entities like customers or accounts, Process components represent business processes like applying for a loan or creating a work order, etc. Servers have a right to manage their working set and they sometimes achieve this using Persistence. They may either use CORBA persistence or a user-defined persistence mechanism. Passivation is the process by which the state of a component is saved to persistent storage and then is swapped out. Activation is the process by which the state of a component is restored by swapping it in from persistent storage. There are two types of Session Components. They are: Stateless Session Components and Stateful Session Components
Stateless Session Components: These types of components have no internal state. Since they do not have any states, they need not be passivated. Because of the fact that they are stateless, they can be pooled in to service multiple clients (remember MTS components and Stateless Session EJBs?) Stateful Session Components: These types of components possess internal states. Hence they need to handle Persistence. These types of components can be saved and restored across client sessions. Persistence in Entity and Process components is of two types. They are:
Container-managed persistence Component-managed persistence
Container-managed persistence: Here, the CCM container is responsible for saving the component's state. Since it is container-managed, the implementation is independent of the data source. Persistence is automatically handled by the container. Component-managed persistence: Here, the Entity component is directly responsible for saving its own state. The container does not need to generate any database calls. Hence the implementation is less adaptable than the previous one as the persistence needs to be hard-coded into the component.
Interfaces between the Application Server and CCM Containers: The CCM specification defines a standard way to implement the container API through CORBA object services. Therefore, the interfaces between the Server and the container are well specified. In fact, since EJB is a subset of CCM, vendors can now implement the EJB container API through CORBA object services. Packaging and Deployment: CCM uses XML descriptors for specifying information about packaging and deployment just like EJB. However, additionally, CCM has an assembly descriptor, which contains metadata about how two or more CCM components are wired together.
Benefits of CCM Its architecture is based on OMG MDA (Model Driven Architecture) and ensures standard CORBA 3.0 compliance. It helps you to extend your CORBA 2.x infrastructure to CORBA 3.0 and thus leverage your existing asset. It enables reuse by extending proprietary implementations of C++ components or legacy CORBA-based Java components to the standard OMG CORBA Component Model(CCM). It allows containers to span machines for load-balancing purposes and also allows dynamic clustering for enhanced scalability & high performance. The K2 CCM container manages component instances' life cycle (creation and destruction) and resource control (activation and passivation), and provides infrastructure services including state persistence and transactionality via standardized interfaces. Inter-working between CCMs and EJBs, allows them to call each other through a bridge (extremely thin & efficient). This is achieved effectively due to the commonality of the EJB model with basic CORBA component model.
Allow non-intrusive maintenance and upgrade. Enhanced and guaranteed QoS(Quality of Service) levels to support large-scale Web OLTP traffic (scalability, availability, integrity and manageability). Using the component technology of CORBA (i.e. CCM), enterprise can build complex systems faster than many packaged applications. CCM based application development is easy to develop and manage. Programmers need not know low-level programming details. Cost of ownership reduces by 40%.
3. Architecture of DCOM DCOM is just COM with a longer wire DCOM extends COM to support communication among objects on different computers In DCOM, the client stub is referred to as proxy and server stub is referred to as stub.
Fig. 8.2 Architecture of DCOM
The architecture of DCOM consists of three layers: top, middle and bottom layer. 1. Top Layer: It is the basic programming architecture. It describes the clients requests and creation of object instances in the server. This mechanism is called activation mechanism. Creation of remote objects requires server name and CLSID. Then SCM in COM libraries on client machine connects to SCM on server machine and request creation of the remote object. Class factory creates instances of a COM class. The SCM then return the pointer to the interface of the object. Using this, the client communicates with the object.
2. Middle Layer: It consists of remoting architecture. It takes care of sending data across different address spaces using processes such as marshalling and unmarshalling. Marshalling : It packs a method calls parameters or return values into standard form for transmission. Unmarshalling: It unpacks standard form into an appropriate data representation in the address space of a receiving process. 3. Bottom Layer: It is the wire protocol architecture It is based on OSF DCE RPC specification. It provides pinging to enable the server object to collect remote object references when a client abnormally terminates. When the server is started by the server-side SCM, it is assigned an object export identifier (OXID). An object reference (OBJREF) is created to represent the interface pointer. OBJREF contains IID, OXID, and address of OXID resolver.
Working of DCOM
Fig.8.3 COM/DCOM Working 1. The COM API: CoCreateInstance() is called with two identifiers (IDs) whether the object is remote or local. One ID is used to instantiate the COM class (CLSID) and the other is used to instantiate the DLL or EXE file which hosts the COM class. 2. The DLLs or EXEs ID is converted to a filename by scanning through the system registry. 3. Once the filename is obtained, COM loads the required DLL or proxy/stub DLL using the LoadLibrary() API call or starts the desired EXE using the RPC API. 4. COM then instructs the DLL or EXE to instantiate the required class using the CLSID specified in CoCreateInstance(). 5. CoCreateInstance() returns a pointer to the created object. 6. Once the pointer is obtained, the remote method is invoked. DLL methods are called like any other class methods. EXE methods calls are serialized by COM using RPC and a proxy object. 7. When the client releases the COM object, the COM API decrements the objects reference count by one. When the count becomes zero, the object is released. 8. When all the objects in the DLL/EXE for the application are destroyed, COM unloads the DLL or stops the EXE.
4. Marshalling Techniques in COM

The issue of passing parameters in DCOM is a major area of concern and is called marshalling. Marshalling is a process of packaging method calls and their parameters into a packet & transmitting them over the network.COM offers three types of marshalling Standard, custom and type library marshalling .Standard marshalling is in fact, a type of custom marshalling; and type library marshalling is type of standard marshalling.
Fig.8.4. Relationship between different types of marshalling Custom Marshalling It is a fundamental marshalling in COM. This method allows the client to gain a complete control over the marshalling process. As it is difficult to implement and is more generic, standard marshalling mechanism is used. In custom marshalling, COM has no support for transmission of data between proxy and stub .Programmer can choose IPC mechanism. However, no stub DLL is created in the component address space. The client can directly communicate with component. Custom marshalling is used in situation to generate customized proxies to improve speed of transmission, reduce the network traffic, improve security etc. It is used in image processing application to improve the speed of multimedia file transmission by compressing the code to be transmitted. Custom marshalling makes use of IMarshal interface. It marshals interface pointer into a stream object and back. It has the following functionalities: 1. MarshalInterface: It is used to marshal an interface pointer into a stream object. 2. UnMarshalInterface: It is used to unmarshal the stream object into interface pointer at the client side. 3. ReleaseMarshalData: It is used to free the data stored in the marshalling packet. 4. DisconnectObject: It is used to disconnect clients that maintain pointers to the object. 5. GetUnmarshalClass: It is used to fetch the unmarshal class. 6. GetMarshalSizeMax: It is used to fetch the size of marshal buffer.
Fig.8.5 Custom Marshalling Process
Standard Marshalling It is used when an object does not implement the marshalling interface but generates it using user defined interfaces for the objects. It standard marshalling, COM generic proxy and stub communication using RPCc. These custom interfaces are compiled by MIDL compiler to generate standard marshalling code. MIDL compiler generates the following files: 1. A header file in the programming Language for the interface definitions in COM format. 2. A file containing definition for IID and CLSID. 3. A file containing the marshalling code. 4. A type library file. 5. DLL entry points for marshalling code. These files are compiled and linked to produce the stub/proxy DLL to marshal the interface. This stub/proxy must be registered. A Stub manager is a COM object that has a unique OID and is connected with one COM object. It maintains a reference count for the COM object. When it becomes Zero, the stub manager is also destroyed. To handle OR PC, interface stub are used. It is helper method, using which the signature of methods in the interface is known. It is identified using interface pointer ID (IPID) and holds a pointer to the object. The client calls the Query Interface to obtain the interface to the remote object using the proxy object. The interface proxy is a part of the proxy manager. It communicates with the component through the IRpcChannel Buffer interface implemented by COM. On the server side, the channel communicates with the interface stub through IrpcStub Buffer interface which in turn calls the COM object (Figure 15). Standard marshalling has four interfaces: 1. IP Factory Buffer that is used to instantiate IrpcProxy Buffer in the server and IrpcStub Buffer object in the client address space. 2. IrpcProxy Buffer that has the connect method to connect to the stub. 3. IrpcStub Buffer that has the invoke method to instantiate the stub code. 4. IrpcChannel Buffer that is used for communication between stub and proxy object.
Fig. Standard marshalling process Type Library Marshalling It uses Idispatch (automation) marshaller. COM has a built-in marshaller for this interface as automation marshaller is generic, it is not as efficient as marshalling code generated. Owing to type library look up more time is consumed, but is more flexible and is easy to use. No proxy/stub needs to be built and registered. It is available in windows. Handler Marshalling It is between standard and full custom marshalling. It is useful for objects that perform work in clients address space, making remote calls only when necessary. These objects support IstdMarshalInfo interface that retrieves the CLSID of the handler object to be loaded in clients address space and load it.
5. Comparison of RMI, CORBA and DCOM Table 8.1 Parameters Programming language RMI Language independent CORBA Language independent DCOM Language independent
Platform Independent Interface Object Identification Object Reference Protocols Storage
Yes Java Object and Interface URL based object reference IIOP/JRMP RMI Registry
Yes IDL Object and Interface OBJREF IIOP/GIOP ORB or Implementation Registry Statically- SSI/SII Dynamically-DII/DSI Yes Yes Yes Yes Yes CCM CORBA Obj Yes Yes Yes Yes
No MIDL CLSID, IID Reference pointers ORPC Registry
Invocation
Stubs and Skeletons
Statically-IUnknown dynamically-IDispatch Yes No Yes Yes Yes COM/MTS COM Obj Yes No No No
Inheritance Trading Services Naming Service Concurrency Service Security Service Component Models Modularity Objects Flag Transactions Replication and recovery Mitigation service Persistence reference
Yes No Yes Yes Yes EJB Java Obj No No Yes Yes
Nested transactions Binding Predictability Communication transparency Network data format Security Garbage Collection IDE Support Cluster Capsules Operation interface Stream interface Signal interface
No Uni-bidirectional and symmetric No JRMP Java object serialization Java security Available Good Yes Yes Yes Yes No
Yes Bidirectional and symmetric Yes GIOP CDR Four models of security Implementation dependent Poor Yes Yes Yes Yes No
Yes Bidirectional and symmetric No ORPC NDR Windows NT security Available Poor Yes Yes Yes Yes No
6.
(a) Write an internal DTD to validate the XML document sample below
<PARTS> <TITLE>Computer Parts</TITLE> <PART> <ITEM>Motherboard</ITEM> <MANUFACTURER>ASUS</MANUFACTURER> <MODEL>P6T</MODEL> <COST>2000</COST> </PART> <PART> <ITEM>24 inch Monitor</ITEM> <MANUFACTURER>Samsung</MANUFACTURER> <MODEL>XL2370</MODEL> <COST>3000</COST> </PART> </PARTS> Solution:
<!DOCTYPE PARTS [ <!ELEMENT PARTS (TITLE, PART*)> <!ELEMENT TITLE (#PCDATA)> <!ELEMENT PART (ITEM, MANUFACTURER, MODEL, COST)> <!ELEMENT ITEM (#PCDATA)>
<!ELEMENT MANUFACTURER (#PCDATA)> <!ELEMENT MODEL (#PCDATA)> <!ELEMENT COST (#PCDATA)> ]>
(b) Write an internal DTD to validate the XML document sample below
<newspaper> <article author="kelvin" date="2009-9-9"> <headline>Apple's next big thing is Steve Jobs</headline> <body>On September 9, Steve Jobs returned to the public eye ...</body> <notes>nice</notes> <notes>good</notes> </article> <article author="tim" edition="1"> <headline>Headline B. Each can only has one lead</headline> <lead>This is a lead. Each article can only has one lead</lead> <body>This is the body of the news &publisher; &copyright;</body> </article> </newspaper> Solution:
<!DOCTYPE newspaper [ <!ELEMENT newspaper (article+)> <!ELEMENT article (headline,lead?,body,notes*)> <!ELEMENT headline (#PCDATA)> <!ELEMENT lead (#PCDATA)> <!ELEMENT body (#PCDATA)> <!ELEMENT notes (#PCDATA)> <!ATTLIST article author CDATA #REQUIRED> <!ATTLIST article date CDATA #IMPLIED> <!ATTLIST article edition CDATA #IMPLIED> <!ENTITY publisher "Vervet Logic Press"> <!ENTITY copyright "copyright 1998 Vervet Logic Press"> ]>
(c) Convert the following DTD into XML Schema, name it juicers.xsd.
<!ELEMENT juicers (juicer)*> <!ELEMENT juicer (name, image, description, warranty?, weight?, cost+, retailer)> <!ELEMENT name (#PCDATA)> <!ELEMENT image (#PCDATA)> <!ELEMENT description (#PCDATA)> <!ELEMENT warranty (#PCDATA)> <!ELEMENT weight (#PCDATA)> <!ELEMENT cost (#PCDATA)> <!ELEMENT retailer (#PCDATA)> Solution: <?xml version="1.0"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="juicers"> <xsd:complexType> <xsd:sequence> <xsd:element name="juicer" minOccurs="0" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="name" type="xsd:string"/> <xsd:element name="image" type="xsd:string"/> <xsd:element name="description" type="xsd:string"/> <xsd:element name="warranty" type="xsd:string" minOccurs="0"/> <xsd:element name="weight" type="xsd:string" minOccurs="0"/> <xsd:element name="cost" type="xsd:string" maxOccurs="unbounded"/> <xsd:element name="retailer" type="xsd:string"/> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> 7. The following XML document monitors.xml is an instance of monitors.xsd. (a) Create XML schema monitors.xsd for the below XML document. Each monitor has a unique model no. and up to 3 features. (b) The value of the attribute can only be LED, LCD or CRT. Modify the schema to add this constraint. (June 2010 -10 Marks) (c) The smallest monitor is 10" while the largest monitor is 30". Modify the schema so that it can validate the size range. (Create a new type and call it SizeType) (d) The value of the element ratio must either be "4:3" or "16:9" or "16:10". Modify the schema to add this constraint. <?xml version="1.0"?> <monitors xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="monitors.xsd"> <monitor type="LED" modelNo="m0010"> <size>24</size> <ratio>16:9</ratio> <launchDate>2009-09-10</launchDate> <feature>100% sRGB color space</feature> <feature>High contrast ratio</feature> <price>7000</price> </monitor> <monitor type="LCD" modelNo="m0101"> <size>20</size> <ratio>16:10</ratio> <launchDate>2008-09-10</launchDate> <feature>Tilt, Swivel, Pivot, height adjustment</feature> <price>200.5</price> </monitor>
<monitor type="CRT" modelNo="c0120"> <size>15</size> <ratio>4:3</ratio> <launchDate>2002-09-10</launchDate> <price>500</price> </monitor> </monitors> Solution: (a) <?xml version="1.0"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> <xsd:element name="monitors"> <xsd:complexType> <xsd:sequence> <xsd:element name="monitor" maxOccurs="unbounded"> <xsd:complexType> <xsd:sequence> <xsd:element name="size" type="xsd:integer"/> <xsd:element name="ratio" type="xsd:string"/> <xsd:element name="launchDate" type="xsd:date"/> <xsd:element name="feature" type="xsd:string" minOccurs="0" maxOccurs="3"/> <xsd:element name="price" type="xsd:decimal"/> </xsd:sequence> <xsd:attribute name="modelNo" use="required" type="xsd:ID"/> <xsd:attribute name="type" use="required" type="xsd:string"/> </xsd:complexType> </xsd:element> </xsd:sequence> </xsd:complexType> </xsd:element> </xsd:schema> (b) <xsd:simpleType name="MonitorType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="LED"/> <xsd:enumeration value="LCD"/> <xsd:enumeration value="CRT"/> </xsd:restriction> </xsd:simpleType> (c) <xsd:simpleType name="SizeType"> <xsd:restriction base="xsd:integer"> <xsd:minInclusive value="10"/> <xsd:maxInclusive value="30"/> </xsd:restriction>
</xsd:simpleType> (d) <xsd:simpleType name="RatioType"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="4:3"/> <xsd:enumeration value="16:9"/> <xsd:enumeration value="16:10"/> </xsd:restriction> </xsd:simpleType> 8. WSDL WSDL is an XML-based language for describing Web services and how to access them.

WSDL stands for Web Services Description Language WSDL is written in XML WSDL is an XML document WSDL is used to describe Web services WSDL is also used to locate Web services WSDL is a W3C recommendation A WSDL document describes a web service using these major elements: Element <types> <message> <portType> <binding> Defines The data types used by the web service The messages used by the web service The operations performed by the web service The communication protocols used by the web service
Fig. 10.3 WSDL Document Structure
The main structure of a WSDL document looks like this: <definitions> <types> definition of types........ </types> <message> definition of a message.... </message> <portType> definition of a port....... </portType> <binding> definition of a binding.... </binding> </definitions> A WSDL document can also contain other elements, like extension elements, and a service element that makes it possible to group together the definitions of several web services in one single WSDL document. WSDL Ports The <portType> element is the most important WSDL element. It describes a web service, the operations that can be performed, and the messages that are involved. The <portType> element can be compared to a function library (or a module, or a class) in a traditional programming language. WSDL Messages The <message> element defines the data elements of an operation. Each message can consist of one or more parts. The parts can be compared to the parameters of a function call in a traditional programming language. WSDL Types The <types> element defines the data types that are used by the web service. For maximum platform neutrality, WSDL uses XML Schema syntax to define data types. WSDL Bindings The <binding> element defines the message format and protocol details for each port. WSDL Example
This is a simplified fraction of a WSDL document: <message name="getTermRequest"> <part name="term" type="xs:string"/> </message> <message name="getTermResponse"> <part name="value" type="xs:string"/> </message> <portType name="glossaryTerms"> <operation name="getTerm"> <input message="getTermRequest"/> <output message="getTermResponse"/> </operation> </portType>
In this example the <portType> element defines "glossaryTerms" as the name of a port, and "getTerm" as the name of an operation. The "getTerm" operation has an input message called "getTermRequest" and an output message called "getTermResponse". The <message> elements define the parts of each message and the associated data types. Compared to traditional programming, glossaryTerms is a function library, "getTerm" is a function with "getTermRequest" as the input parameter, and getTermResponse as the return parameter.
9. SOAP

SOAP stands for Simple Object Access Protocol SOAP is a communication protocol SOAP is for communication between applications SOAP is a format for sending messages SOAP communicates via Internet SOAP is platform independent SOAP is language independent SOAP is based on XML SOAP is simple and extensible SOAP allows you to get around firewalls SOAP is a W3C recommendation
Why SOAP? It is important for application development to allow Internet communication between programs.
Today's applications communicate using Remote Procedure Calls (RPC) between objects like DCOM and CORBA, but HTTP was not designed for this. RPC represents a compatibility and security problem; firewalls and proxy servers will normally block this kind of traffic. A better way to communicate between applications is over HTTP, because HTTP is supported by all Internet browsers and servers. SOAP was created to accomplish this. SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages. SOAP Building Blocks A SOAP message is an ordinary XML document containing the following elements:

An Envelope element that identifies the XML document as a SOAP message A Header element that contains header information A Body element that contains call and response information A Fault element containing errors and status information
Syntax Rules Here are some important syntax rules:

A SOAP message MUST be encoded using XML A SOAP message MUST use the SOAP Envelope namespace A SOAP message MUST use the SOAP Encoding namespace A SOAP message must NOT contain a DTD reference A SOAP message must NOT contain XML Processing Instructions
Skeleton SOAP Message <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:Header> ... </soap:Header> <soap:Body> ... <soap:Fault> ... </soap:Fault> </soap:Body> </soap:Envelope>
The SOAP Envelope Element The required SOAP Envelope element is the root element of a SOAP message. This element defines the XML document as a SOAP message. Example <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> ... Message information goes here ... </soap:Envelope>
The xmlns:soap Namespace Notice the xmlns:soap namespace in the example above. It should always have the value of: "http://www.w3.org/2001/12/soap-envelope". The namespace defines the Envelope as a SOAP Envelope. If a different namespace is used, the application generates an error and discards the message. The encodingStyle Attribute The encodingStyle attribute is used to define the data types used in the document. This attribute may appear on any SOAP element, and applies to the element's contents and all child elements. A SOAP message has no default encoding. Syntax soap:encodingStyle="URI" Example <?xml version="1.0"?> <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> Message information goes here </soap:Envelope>

Me It

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Me It

Загружено:

Авторское право:

Доступные форматы

Generated by Foxit PDF Creator Foxit Software http://www.foxitsoftware.com For evaluation only.

1. Overview of CORBA Services

Fig. 7.2 CCM Components

Container-managed persistence Component-managed persistence

Fig. 8.2 Architecture of DCOM

4. Marshalling Techniques in COM

Fig.8.5 Custom Marshalling Process

Platform Independent Interface Object Identification Object Reference Protocols Storage

No MIDL CLSID, IID Reference pointers ORPC Registry

Stubs and Skeletons

Yes No Yes Yes Yes EJB Java Obj No No Yes Yes

Fig. 10.3 WSDL Document Structure

Syntax Rules Here are some important syntax rules:

Вам также может понравиться