Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. This document (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide the community. The WSA provides a conceptual model and a context for understanding Web services and the relationships between the components of this model.
The architecture does not attempt to specify how Web services are implemented, and imposes no restriction on how Web services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services.
The Web services architecture is an interoperability architecture: it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services.
A Web service is a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.
In java :- Web services are Web based applications that use open, XML-based standards and transport protocols to exchange data with clients. Web services are developed using Java Technology APIs and tools provided by an integrated Web Services Stack called Metro. The Metro stack consisting of JAX-WS, JAXB, and WSIT, enable you to create and deploy secure, reliable, transactional, interoperable Web services and clients. The Metro stack is part of Project Metro and as part of GlassFish, Java Platform, Enterprise Edition (Java EE), and partially in Java PlatForm, Standard Edition (Java SE). GlassFish and Java EE also support the legacy JAX-RPC APIs.
Wednesday, January 21, 2009
RMI Server
The compute engine server accepts tasks from clients, runs the tasks, and returns any results. The server code consists of an interface and a class. The interface defines the methods that can be invoked from the client. Essentially, the interface defines the client's view of the remote object. The class provides the implementation.
Designing a Remote Interface
This section explains the Compute interface, which provides the connection between the client and the server. You will also learn about the RMI API, which supports this communication.
Implementing a Remote Interface
This section explores the class that implements the Compute interface, thereby implementing a remote object. This class also provides the rest of the code that makes up the server program, including a main method that creates an instance of the remote object, registers it with the RMI registry, and sets up a security manager.
Designing a Remote Interface
This section explains the Compute interface, which provides the connection between the client and the server. You will also learn about the RMI API, which supports this communication.
Implementing a Remote Interface
This section explores the class that implements the Compute interface, thereby implementing a remote object. This class also provides the rest of the code that makes up the server program, including a main method that creates an instance of the remote object, registers it with the RMI registry, and sets up a security manager.
RMI()
RMI applications often comprise two separate programs, a server and a client. A typical server program creates some remote objects, makes references to these objects accessible, and waits for clients to invoke methods on these objects. A typical client program obtains a remote reference to one or more remote objects on a server and then invokes methods on them. RMI provides the mechanism by which the server and the client communicate and pass information back and forth. Such an application is sometimes referred to as a distributed object application.
Distributed object applications need to do the following:
* Locate remote objects. Applications can use various mechanisms to obtain references to remote objects. For example, an application can register its remote objects with RMI's simple naming facility, the RMI registry. Alternatively, an application can pass and return remote object references as part of other remote invocations.
* Communicate with remote objects. Details of communication between remote objects are handled by RMI. To the programmer, remote communication looks similar to regular Java method invocations.
* Load class definitions for objects that are passed around. Because RMI enables objects to be passed back and forth, it provides mechanisms for loading an object's class definitions as well as for transmitting an object's data.
Distributed object applications need to do the following:
* Locate remote objects. Applications can use various mechanisms to obtain references to remote objects. For example, an application can register its remote objects with RMI's simple naming facility, the RMI registry. Alternatively, an application can pass and return remote object references as part of other remote invocations.
* Communicate with remote objects. Details of communication between remote objects are handled by RMI. To the programmer, remote communication looks similar to regular Java method invocations.
* Load class definitions for objects that are passed around. Because RMI enables objects to be passed back and forth, it provides mechanisms for loading an object's class definitions as well as for transmitting an object's data.
Ado.Net connected classes
ADO.Net libraries contains providers classes which can be use to transfer data between data store and client application.
Microsoft .Net Framework contains the following providers :-
OleDB:-It contains classes that provides general purpose data access to many data sources.
ODBC :- IT contain classes for general purpose data access to many data sources.This provider is useful when no other provider is available.
Sql Server:- It contains classes that provide functionality similar to the generic OLEDB provider.
Oracle :- It contain classes for accessing Oracle 8 and later servers.It provide better performance than OLEDB.
Microsoft .Net Framework contains the following providers :-
OleDB:-It contains classes that provides general purpose data access to many data sources.
ODBC :- IT contain classes for general purpose data access to many data sources.This provider is useful when no other provider is available.
Sql Server:- It contains classes that provide functionality similar to the generic OLEDB provider.
Oracle :- It contain classes for accessing Oracle 8 and later servers.It provide better performance than OLEDB.
Custom Web Control Types
There are 3 primary custom controls :-
user control,custom web control and composite control
User control :- A user control is a template control that provides extra behaviour to allow constituent controls to be added to the user control in the graphical User Interface .These controls are added to the user controls template file that is ascx file.
custom web control :- It Inherits from web control,were you can write all code to render the control or inherit it from existing web control .The class file can be compiled to a .dll that can be shared among applications and can optionally be installed in global assembly cache.
composite control :- A composite control is a custom web control that can contain constituent controls.The class file can be compiled to a .dll that can be shared among other application .
user control,custom web control and composite control
User control :- A user control is a template control that provides extra behaviour to allow constituent controls to be added to the user control in the graphical User Interface .These controls are added to the user controls template file that is ascx file.
custom web control :- It Inherits from web control,were you can write all code to render the control or inherit it from existing web control .The class file can be compiled to a .dll that can be shared among applications and can optionally be installed in global assembly cache.
composite control :- A composite control is a custom web control that can contain constituent controls.The class file can be compiled to a .dll that can be shared among other application .
Web Server Controls
It offers more functionality that HTML server controls.It may also render as many HTML tags and may also include client side Java script code.Web Server control inherits from Web Control Class.All Web server controls must contains a valid ID to give you a way to programatically reference the controls.We can set the properties of server controls in source view or design view.It is easy to set the properties of server control in design view and code are automatically generated at source page.
Using Server control in Asp.net
Server control is a server side code written to respond to events from controls.They maintain their state between calls to the server and are easily identified by runat = "server" attribute.It must have an ID attribute to reference to the code.All server controls inherits from System.Web.UI.Control class.
Life cycle of Web Page and controls :-
The life cycle begins when the browser requests a web Page from a website.The Web Server constructs the web page objects and all of its child controls objects and uses these objects to render the Web page browser.later objects are destroyed.They are destroyed to free its resources.
Life cycle of Web Page and controls :-
The life cycle begins when the browser requests a web Page from a website.The Web Server constructs the web page objects and all of its child controls objects and uses these objects to render the Web page browser.later objects are destroyed.They are destroyed to free its resources.
Subscribe to:
Posts (Atom)