at-m42:lecture11
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
at-m42:lecture11 [2009/04/16 21:57] – eechris | at-m42:lecture11 [2011/01/14 12:45] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 223: | Line 223: | ||
- | JNDI: Accessing Naming and Directory Services | + | ===== JNDI: Accessing Naming and Directory Services |
- | JNDI = Java Naming and Directory Interface | + | |
- | Java Enterprise API for working with networked naming and directory services. | + | |
- | Allows Java programs to use name servers and directory servers to look up objects or data by name and search for objects or data according to a set of specified attribute values. | + | |
- | Implemented in the javax.naming package and its sub-packages as a standard extension to the Java 2 platform. | + | |
- | JNDI – the facts | + | |
- | Not specific to any particular name or directory server protocol. | + | ===== JNDI – the facts ===== |
- | Provides a generic API that will work with any name or directory server. | + | |
- | To support a particular protocol: | + | |
- | Plug in a service provider for that protocol into a JNDI installation. | + | |
- | Service providers for common protocols: NIS, LDAP, and Novell’s NDS available. | + | |
- | Service providers also available for RMI and CORBA object registries. | + | |
+ | | ||
+ | | ||
===== Distributed Computing APIs ===== | ===== Distributed Computing APIs ===== | ||
Line 247: | Line 249: | ||
===== CORBA and SOAP ===== | ===== CORBA and SOAP ===== | ||
- | Need to interface with legacy data stores? | + | * Need to interface with legacy data stores? |
- | Need to call methods of a language other than Java? | + | |
- | Need services from a server object regardless of its physical location? | + | |
- | Then you need some form of remote procedure call (RPC): | + | |
- | Common Object Request Broker Architecture (CORBA) is an integration specification defined by the Object Management Group. | + | |
- | Simple Object Access Protocol (SOAP) uses XML and networking technology to achieve much the same ends. | + | |
- | Both promise distributed, | + | |
- | What is CORBA? | + | ===== What is CORBA? |
- | CORBA vs. RMI | + | * Common Object Request Broker Architecture (CORBA) is not a language |
- | One of the main CORBA features | + | * It's a specification that vendors |
- | RMI makes RPC possible between Java objects. | + | * CORBA is part of the OMG's effort to define a standard framework for distributed, |
- | CORBA makes RPC possible between objects implemented in any language. | + | * CORBA supplies the ability |
- | RMI can be used to call services on remote, non-Java code. | + | * Java complements |
- | you need is some kind of wrapper Java object around | + | |
- | The wrapper object connects externally | + | |
- | This approach requires you to write a kind of integration layer, which is exactly what CORBA does for you, but the advantage is that you don’t need a third party ORB. | + | |
- | RMI-IIOP | + | ===== CORBA vs. RMI ===== |
- | RMI over Internet Inter-Orb Protocol | + | |
- | A variation of RMI that uses the standard Object Request Broker (ORB) to provide RMI services. | + | * One of the main CORBA features is RPC support, which allows your local objects to call methods in remote objects. |
- | A One Slide Guide to SOAP | + | * RMI makes RPC possible between Java objects. |
+ | * CORBA makes RPC possible between objects implemented in any language. | ||
+ | * RMI can be used to call services on remote, non-Java code. | ||
+ | * you need is some kind of wrapper Java object around the non-Java code on the server side. | ||
+ | * the wrapper object connects externally to Java clients via RMI, and internally connects to the non-Java code using Java Native Interface (JNI). | ||
+ | * This approach requires you to write a kind of integration layer, which is exactly what CORBA does for you, but the advantage is that you don’t need a third party ORB. | ||
+ | |||
+ | ===== RMI-IIOP | ||
+ | |||
+ | | ||
+ | | ||
+ | |||
+ | ===== A One Slide Guide to SOAP ===== | ||
+ | |||
+ | * Simple Object Access Protocol (SOAP) is a lightweight protocol for the exchange of information in a decentralized, | ||
+ | * It is an XML based protocol that consists of three parts: | ||
+ | * an envelope that defines a framework for describing what is in a message and how to process it, | ||
+ | * a set of encoding rules for expressing instances of application-defined data-types, | ||
+ | * a convention for representing remote procedure calls and responses. | ||
+ | * SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in [the specification] describe how to use SOAP in combination with HTTP and HTTP Extension Framework. | ||
+ | * Big part of Microsoft’s .NET strategy. Java Support for SOAP from IBM. Support from Sun in J2EE 1.4. Possibly easier to use than CORBA. | ||
+ | |||
+ | //Source//: Technical Note: SOAP 1.1, 8/ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | A problem with SOAP is that it uses HTTP as a transport protocol, primarily to avoid firewall problems (HTTP messages are normally allowed through corporate firewalls). | ||
===== Distributed Computing APIs ===== | ===== Distributed Computing APIs ===== | ||
Line 280: | Line 305: | ||
===== Restful Web Services ===== | ===== Restful Web Services ===== | ||
+ | |||
+ | > " | ||
+ | |||
+ | In summary, the five key principles((Stefan Tilkov, Stefan (2007), [[http:// | ||
+ | |||
+ | * Give every " | ||
+ | * Link things together | ||
+ | * Use standard methods | ||
+ | * Resources with multiple representations | ||
+ | * Communicate statelessly | ||
+ | |||
+ | ---- | ||
+ | |||
+ | **Notes**: Fielding was one of the principal authors of the Hypertext Transfer Protocol (HTTP) specification. REST is a set of principles that define how Web standards, such as HTTP and URIs, are supposed to be used. If you adhere to REST principles you will end up with a system that exploits the Web's architecture to your benefit. | ||
+ | |||
+ | ===== Give every " | ||
+ | |||
+ | On the web any individual object can have a URL: | ||
+ | http:// | ||
+ | http:// | ||
+ | http:// | ||
+ | http:// | ||
+ | |||
+ | But so can collections: | ||
+ | |||
+ | http:// | ||
+ | http:// | ||
+ | |||
+ | ---- | ||
+ | |||
+ | This makes it easy for both web browsers and other programs to be able to find objects that need to be manipulated in a distributed system. | ||
+ | |||
+ | ===== Link things together ===== | ||
+ | |||
+ | Some made up XML: | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | < | ||
+ | </ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | Represents the inventory of a player in our game (could of course be HTML is a web application, | ||
+ | |||
+ | ===== Use standard methods ===== | ||
+ | |||
+ | * Traditional Service-Oriented Architecture: | ||
+ | * Might be implemented in RMI, CORBA, SOAP | ||
+ | {{: | ||
+ | |||
+ | |||
+ | |||
+ | ---- | ||
+ | |||
+ | You can see that there are two services defined here (without implying any particular implementation technology). The interface to these services is specific to the task -- it's a '' | ||
+ | |||
+ | ===== RESTful services ===== | ||
+ | |||
+ | * Must use '' | ||
+ | {{: | ||
+ | |||
+ | ---- | ||
+ | |||
+ | You can see that what have been specific operations of a service have been mapped to the standard HTTP methods -- and to disambiguate, | ||
+ | |||
+ | Essentially, | ||
+ | |||
+ | The uniform interface also enables every component that understands the HTTP application protocol to interact with your application. | ||
+ | |||
+ | To summarize: For clients to be able to interact with your resources, they should implement the default application protocol (HTTP) correctly, i.e. make use of the standard methods GET, PUT, POST, DELETE. | ||
+ | |||
+ | ===== Resources with multiple representations ===== | ||
+ | |||
+ | * An HTTP client is expected to be able to handle multiple resources types and to make use of //content negotiation// | ||
+ | |||
+ | GET / | ||
+ | Host: game.com | ||
+ | Accept: text/html | ||
+ | |||
+ | GET / | ||
+ | Host: game.com | ||
+ | Accept: application/ | ||
+ | |||
+ | ---- | ||
+ | |||
+ | There is a significant benefit of having multiple representations of a resource in practice: If you provide both an HTML and an XML representation of your resources, they are consumable not only by your application, | ||
+ | |||
+ | ===== Communicate statelessly ===== | ||
+ | * HTTP is a // | ||
+ | * Therefore state must be stored in the client or in the resources. | ||
+ | |||
+ | ===== Impact of REST ===== | ||
+ | |||
+ | * World-wide web is built on a RESTful architecture, | ||
+ | * Becoming more popular for distributed computing: key feature of application frameworks like Rails and Grails. | ||
+ | * Needs a rethink: away from traditional OO design based around a few nouns and a rich vocabulary of verbs to few verbs and many nouns. | ||
===== Distributed Computing APIs ===== | ===== Distributed Computing APIs ===== | ||
Line 292: | Line 415: | ||
===== JINI: distributed services ===== | ===== JINI: distributed services ===== | ||
- | Jini is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services. | + | * Jini is a set of APIs and network protocols that can help you build and deploy distributed systems that are organized as federations of services. |
- | A service can be anything that sits on the network and is ready to perform a useful function. Hardware devices, software, communications channels—even human users themselves—can be services. | + | |
- | A Jini-enabled disk drive could offer a “storage” service. | + | |
- | A Jini-enabled printer could offer a “printing” service. | + | |
- | A federation of services is a set of services, currently available on the network, that a client (meaning a program, service, or user) can bring together to help it accomplish some goal. | + | |
- | JINI: Peer-to-Peer Networking | + | |
- | In Jini there is no central controlling authority. | + | ===== JINI: Peer-to-Peer Networking |
- | Because no one service is in charge, the set of all services available on the network form a federation—a group composed of equal peers. | + | |
- | Jini’s run-time infrastructure merely provides a way for clients and services to find each other via a lookup service. | + | |
- | After services locate each other, they are on their own. The client and its enlisted services perform their task independently of the Jini run-time infrastructure. | + | |
- | If the Jini lookup service crashes, any distributed systems brought together via the lookup service before it crashed can continue their work. | + | |
- | Jini includes a network protocol that clients can use to find services in the absence of a lookup service. | + | |
- | An example of JINI in use | + | |
- | To perform a task, a client enlists the help of services, e.g.: | + | |
- | client program might upload pictures from the image storage service in a digital camera | + | ===== An example of JINI in use ===== |
- | download the pictures to a persistent storage service offered by a disk drive | + | |
- | send a page of thumbnail-sized versions of the images to the printing service of a colour printer. | + | * To perform a task, a client enlists the help of services, e.g.: |
- | The client program builds a distributed system consisting of itself, the image storage service, the persistent storage service, and the colour-printing service. | + | |
- | The client and services of this distributed system work together to perform the task: to offload and store images from a digital camera and print a page of thumbnails. | + | |
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | ===== Summary ===== | ||
+ | |||
+ | * Distributed computing is when you have some part of the application on one machine and some part(s) on another machine perhaps separated geographically. | ||
+ | * If both parts of the application are written in Java you can use RMI or RMI/IIOP. | ||
+ | * To find the services available on a server you can use JNDI | ||
+ | * If some part of the application uses legacy code or is not written in Java then use CORBA | ||
+ | * SOAP is a recent attempt to simplify distributed computing by use of XML and standard internet technologies like HTTP. | ||
+ | * RESTful services recognizes that HTTP itself can provide many of the benefits of CORBA or SOAP at much lest cost. | ||
+ | * JINI is a networking technology that allows small applications or networked devices to communicate with other and dynamically configure themselves to create distributed applications. | ||
+ | |||
+ | ===== What Should You Remember? ===== | ||
- | Summary | + | Apart from some special cases, current trend (as we'll see) is away from distributed computing using RMI, CORBA and SOAP towards |
- | Distributed computing is when you have some part of the application on one machine and some part(s) on another machine perhaps separated geographically. | + | |
- | If both parts of the application are written in Java you can use RMI or RMI/IIOP. | + | |
- | To find the services available on a server you can use JNDI | + | |
- | If some part of the application uses legacy code or is not written in Java then use CORBA | + | |
- | SOAP is a recent attempt | + | |
- | JINI is a networking | + | |
- | Labs | + | |
- | Simply get the RMI example to work on your setup. | + | |
- | Experiment with passing and receiving objects. | + | |
---- | ---- | ||
- | [[Home]] | [[lecture10|Previous Lecture]] | [[Lectures]] | [[lecture11|Next Lecture]] | + | [[Home]] | [[lecture10|Previous Lecture]] | [[Lectures]] | [[part3|Next Lecture]] |
at-m42/lecture11.1239919038.txt.gz · Last modified: 2011/01/14 12:21 (external edit)