Introduction to Grid programming with Globus Toolkit 4 By Valentin Kravtsov and David Carmeli Combined from material provided by: Jennifer M. Schopf, Borja Sotomayor
Administration n n Project submission: 8/2/2007 Meeting frequency: every 2 -3 weeks. ¨ n n Group’s member are expected to be acquainted with the meeting’s material and present documents submitted in advance if asked to. Homework: one easy homework, meant to show to set up Globus<->Eclipse environment Design: UML use case diagrams will be used to identify requirement, components, and functionality. ¨ UML static and dynamic models will be used to describe the system structure and behavior ¨ design review with the course team should be held before the actual implementation ¨ n Design, code, and documentation guidelines will be published on the course web site.
Administration n n Programming in Java, using the Globus Toolkit 4 environment 4 GT 4 stations are pre-configured in the DSL and will be supported by lab admin. ¨ n n n Any configuration problem should be reported ASAP It is recommended to set up basic working environment at home. Work can be done remotely via ssh to the DSL machines Send email to us with your: {first&family name, id number, phone number} in order to open an account at DSL. CMS system and a CVS will be used to track team’s documents, manage software versions, etc.
Administration - Grades n Grade: ¨ 5% - hw 1 ¨ 10% - meetings ¨ 15% - documentation ¨ 30% - software design ¨ 40% - implementation
What is a Grid? n n n Resource sharing ¨ Computers, storage, sensors, networks, … ¨ Sharing always conditional: issues of trust, policy, negotiation, payment, … Coordinated problem solving ¨ Beyond client-server: distributed data analysis, computation, collaboration, … Dynamic, multi-institutional virtual orgs ¨ Community overlays on classic org structures ¨ Large or small, static or dynamic
Why Is this Hard or Different? n Lack of central control ¨ Where things run ¨ When they run n Shared resources ¨ Controversy, variability n Communication ¨ Different sites implies different sys admins, users, institutional goals
So Why Do It? Computations that need to be done with a time limit n Data that can’t fit on one site n Data owned by multiple sites n Applications that need to be run bigger, faster, more n
What Kinds of Applications? n n n Computation intensive ¨ Interactive simulation (climate modeling) ¨ Large-scale simulation and analysis (galaxy formation, gravity waves, event simulation) ¨ Engineering (parameter studies, linked models) Data intensive ¨ Experimental data analysis (e. g. , physics) ¨ Image & sensor analysis (astronomy, climate) Distributed collaboration ¨ Online instrumentation (microscopes, x-ray) Remote visualization (climate studies, biology) ¨ Engineering (large-scale structural testing)
A short introduction to Web Services Websites for humans, Web Services for software
Pros n n Web Services are platform-independent and language-independent, since they use standard XML languages. (C++ client under Windows with Java Web Service under Linux) Most Web Services use HTTP for transmitting messages. Most of the Internet's proxies and firewalls won't mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls).
Cons n n Overhead. Transmitting all your data in XML… Simplicity. Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. CORBA, for example, offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc. ). ¨ Fortunately, there a lot of emerging Web services specifications (including WSRF) that are helping to make Web services more and more versatile.
Typical Web Service invocation For now, don't worry about all the acronyms (SOAP, WSDL, . . . ). We'll explain them in detail in just a moment.
So, what exactly are SOAP and WSDL?
For example… n WSDL of the Fahrenheit 2 Celsius web service: http: //www. w 3 schools. com/webservices/tempconvert. asmx? WSDL n SOAP message http: //www. w 3 schools. com/webservices/tempconvert. asmx? op=Fahrenheit. To. Celsius
How does this work in practice? Web Services programmers usually only have to concentrate on writing code in their favorite programming language and, in some cases, in writing WSDL. n SOAP code, on the other hand, is always generated and interpreted automatically for us. n
How does this work in practice? Once we've reached a point where our client application needs to invoke a Web Service, we delegate that task on a piece of software called a stub. The good news is that there are plenty of tools available that will generate stubs automatically for us, usually based on the WSDL description of the Web Service.
A Typical Web Service Invocation n So, let's suppose that we've already located the Web Service And we've generated the client stubs from the WSDL description What exactly happens when we want to invoke a Web service operation from a program?
The server side, close up
The server side, close up n n Web service: This is basically a piece of software that exposes a set of operations. For example, if we are implementing our Web service in Java, our service will be a Java class (and the operations will be implemented as Java methods). Obviously, we want a set of clients to be able to invoke those operations. However, our Web service implementation knows nothing about how to interpret SOAP requests and how to create SOAP responses. That's why we need a. . .
The server side, close up n n SOAP engine: This is a piece of software that knows how to handle SOAP requests and responses. One good example of a SOAP engine is Apache Axis (this is, in fact, the SOAP engine used by the Globus Toolkit). However, the functionality of the SOAP engine is usually limited to manipulating SOAP. To actually function as a server that can receive requests from different clients, the SOAP engine usually runs within an. . .
The server side, close up n n n Application server: This is a piece of software that provides a 'living space' for applications that must be accessed by different clients. The SOAP engine runs as an application inside the application server. A good example is the Jakarta Tomcat server, a Java Servlet and Java Server. Pages container that is frequently used with Apache Axis and the Globus Toolkit. Many application servers already include some HTTP functionality, so we can have Web services up and running by installing a SOAP engine and an application server. However, when an application server lacks HTTP functionality, we also need an. . .
The server side, close up n HTTP Server: This is more commonly called a 'Web server'. It is a piece of software that knows how to handle HTTP messages. A good example is the Apache HTTP Server, one of the most popular web servers in the Internet.
OGSA & WSRF Open Grid Services Architecture Web Service Resource Framework
OGSA, WSRF & GT 4
The Web Services n n Plain Web services are usually stateless (even though, in theory, there is nothing in the Web Services Architecture that says they can't be stateful). Suppose we have an add operation which receives the value to add and returns the current value of the accumulator
The Web Services n However, Grid applications do generally require statefulness. So, we would ideally like our Web service to somehow keep state information:
WSRF: The Web Services Resource Framework n n Instead of putting the state in the Web service (which is generally regarded as a bad thing) we will keep it in a separate entity called a resource, which will store all the state information. Each resource will have a unique key, so whenever we want a stateful interaction with a Web service we simply have to instruct the Web service to use a particular resource.
WSRF: It's all about state n Counter service example:
WSRF: It's all about state n A Web Service with several resources. Each resource represents a file.
Before vs. Now
New term: WS-Resource
The WSRF specification The Web Services Resources Framework is a collection of five different specifications. Of course, they all relate (in some way or another) to the management of WS-Resources. n WS-Resource. Properties A resource is composed of zero or more resource properties. For example, in the figure shown above each resource has three resource properties: Filename, Size, and Descriptors. WS-Resource. Properties specifies how resource properties are defined and accessed. As we'll see later on when we start programming, the resource properties are defined in the Web service's WSDL interface description. n WS-Resource. Lifetime Resources have non-trivial lifecycles. In other words, they're not a static entity that is created when our server starts and destroyed when our server stops. Resources can be created and destroyed at any time. The WS-Resource. Lifetime supplies some basic mechanisms to manage the lifecycle of our resources. n WS-Service. Group We will often be interested in managing groups of Web Services or groups of WS-Resources, and performing operations such as 'add new service to group', 'remove this service from group', and (more importantly) 'find a service in the group that meets condition FOOBAR'. The WS-Service. Group specifies how exactly we should go about grouping services or WSResources together. Although the functionality provided by this specification is very basic, it is nonetheless the base of more powerful discovery services (such as GT 4's Index. Service) which allow us to group different services together and access them through a single point of entry (the service group). n WS-Base. Faults Finally, this specification aims to provide a standard way of reporting faults when something goes wrong during a WS-Service invocation.
Related specifications n n WS-Notification is another collection of specifications that, although not a part of WSRF, is closely related to it. This specification allows a Web service to be configured as a notification producer, and certain clients to be notification consumers (or subscribers). This means that if a change occurs in the Web service (or, more specifically, in one of the WS-Resources), that change is notified to all the subscribers (not all changes are notified, only the ones the Web services programmer wants to). WS-Addressing As mentioned before, the WS-Addressing specification provides us a mechanism to address Web services which is much more versatile than plain URIs. In particular, we can use WS-Addressing to address a Web service + resource pair (a WS-Resource).
Writing Your First Stateful Web Service in 5 Simple Steps 1. 2. 3. 4. 5. Define the service's interface. This is done with WSDL Implement the service. This is done with Java. Define the deployment parameters. This is done with WSDD and JNDI Compile everything and generate a GAR file. This is done with Ant Deploy service. This is also done with a GT 4 tool
Step 1: Defining the interface in WSDL Structure Header (namespaces definition) n Data Types n ¨ Resource Properties Messages n Port. Type (operations) n
Step 1: Defining the interface in WSDL If we wanted to define our interface in Java, we could simply write the following: public interface Math { public void add(int a); public void subtract(int a); public int get. Value. RP(); }
target. Namespace: The target namespace of the Header of WSDL - Math Service WSDL file. This means that all the Port. Types and operations defined in this WSDL file will belong to this namespace. <? xml version="1. 0" encoding="UTF-8"? > <definitions name="Math. Service" target. Namespace="http: //www. globus. org/namespaces/examples/co re/Math. Service_instance" xmlns="http: //schemas. xmlsoap. org/wsdl/" xmlns: tns="http: //www. globus. org/namespaces/examples/core/Math Service_instance" xmlns: wsdl="http: //schemas. xmlsoap. org/wsdl/" xmlns: wsrp="http: //docs. oasis-open. org/wsrf/2004/06/wsrf-WSPlease, remember this one Resource. Properties-1. 2 -draft-01. xsd" xmlns: wsrpw="http: //docs. oasis-open. org/wsrf/2004/06/wsrf-WSResource. Properties-1. 2 -draft-01. wsdl" xmlns: wsdlpp="http: //www. globus. org/namespaces/2004/10/WSDLP reprocessor" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema"> <wsdl: import namespace= "http: //docs. oasisopen. org/wsrf/2004/06/wsrf-WS-Resource. Properties-1. 2 -draft 01. wsdl" location=". . /wsrf/properties/WSResource. Properties. wsdl" />
Types of WSDL - Math Service <types> <xsd: schema target. Namespace="http: //www. globus. org/namespaces/examples/co re/Math. Service_instance" xmlns: tns="http: //www. globus. org/namespaces/examples/core/Math Service_instance" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema"> <!-- REQUESTS AND RESPONSES --> <xsd: element name="add" type="xsd: int"/> <xsd: element name="add. Response"> <xsd: complex. Type/> </xsd: element> <xsd: element name="subtract" type="xsd: int"/> <xsd: element name="subtract. Response"> <xsd: complex. Type/> </xsd: element> <xsd: element name="get. Value. RPResponse" type="xsd: int"/>
Resource Properties of WSDL - Math Service <xsd: element name="Value" type="xsd: int"/> <xsd: element name="Last. Op" type="xsd: string"/> <xsd: element name="Math. Resource. Properties"> <xsd: complex. Type> <xsd: sequence> <xsd: element ref="tns: Value" min. Occurs="1" max. Occurs="1"/> <xsd: element ref="tns: Last. Op" min. Occurs="1" max. Occurs="1"/> </xsd: sequence> </xsd: complex. Type> </xsd: element> </xsd: schema> </types>
Messages of WSDL - Math Service <message name="Add. Input. Message"> <part name="parameters" element="tns: add"/> </message> <message name="Add. Output. Message"> <part name="parameters" element="tns: add. Response"/> </message> <message name="Subtract. Input. Message"> <part name="parameters" element="tns: subtract"/> </message> <message name="Subtract. Output. Message"> <part name="parameters" element="tns: subtract. Response"/> </message> <message name="Get. Value. RPInput. Message"> <part name="parameters" element="tns: get. Value. RP"/> </message> <message name="Get. Value. RPOutput. Message"> <part name="parameters" element="tns: get. Value. RPResponse"/> </message>
Port. Type of WSDL - Math Service wsrp: Resource. Properties: resource properties are where we'll keep all our state information. <port. Type name="Math. Port. Type" wsdlpp: extends="wsrpw: Get. Resource. Property" wsrp: Resource. Properties="tns: Math. Resource. Properties"> <operation name="add"> <input message="tns: Add. Input. Message"/> <output message="tns: Add. Output. Message"/> Thanks to the wsdlpp: extends attribute of the port. Type element we </operation> can include existing WSRF port. Types in our own port. Type without <operation name="subtract"> having to copy-and-paste from the official WSRF WSDL files. <input message="tns: Subtract. Input. Message"/> <output message="tns: Subtract. Output. Message"/> A WSDL Preprocessor will use the value of that attribute to generate correct WSDL which includes our own port. Type definitions plus any </operation> WSRF port. Type we might need in our service. This is a Globus<operation name="get. Value. RP"> specific feature that is included to make life easier for programmers <input message="tns: Get. Value. RPInput. Message"/> <output message="tns: Get. Value. RPOutput. Message"/> </operation> </port. Type> </definitions>
Namespace mappings WSDL is language-neutral. n At some moment we'll want to refer to this interface from a specific language (Java) n To successfully generate the stub classes, we need to tell where (i. e. in what Java package) to place the stub classes. n
Namespace mappings We do this with a mappings file, which maps WSDL namespaces to Java packages namespace 2 package. properties http: //www. globus. org/namespaces/examples/core/Math. Service_instance= org. globus. examples. stubs. Math. Service_instance http: //www. globus. org/namespaces/examples/core/Math. Service_instance/bindings= org. globus. examples. stubs. Math. Service_instance. bindings http: //www. globus. org/namespaces/examples/core/Math. Service_instance/service= org. globus. examples. stubs. Math. Service_instance. service
Step 2: Implementing the service in Java n Qualified name, or QName for short. This is a name which includes a namespace and a local name. For example, the QName of the Value RP is: {http: //www. globus. org/namespaces/examples/ core/Math. Service_instance}Value
Step 2: Implementing the service in Java package org. globus. examples. services. core. first. impl; import javax. xml. namespace. QName; public interface Math. QNames { public static final String NS = "http: //www. globus. org/namespaces/examples/core/Math. Servic e_instance"; public static final QName RP_VALUE = new QName(NS, "Value"); public static final QName RP_LASTOP = new QName(NS, "Last. Op"); public static final QName RESOURCE_PROPERTIES = new QName(NS, "Math. Resource. Properties"); }
Step 2: Implementing the service in Java package org. globus. examples. services. core. first. impl; import java. rmi. Remote. Exception; import org. globus. wsrf. Resource; By implementing the Resource. Properties interface we are import org. globus. wsrf. Resource. Properties; indicating that our class has a set of resource properties import org. globus. wsrf. Resource. Property; which we want to make available. Must implement: import org. globus. wsrf. Resource. Property. Set; get. Resource. Property. Set() public Resource. Property. Set import org. globus. wsrf. impl. Reflection. Resource. Property; import org. globus. wsrf. impl. Simple. Resource. Property. Set; Since our Java class will implement both the service and import org. globus. examples. stubs. Math. Service_instance. Add. Response; the resource, we need to implement the Resource import org. globus. examples. stubs. Math. Service_instance. Subtract. Response; interface. It is an empty interface. import org. globus. examples. stubs. Math. Service_instance. Get. Value. RP; public class Math. Service implements Resource , Resource. Properties { … }
Step 2: Implementing the service in Java public class Math. Service implements Resource, Resource. Properties { /* Resource Property set */ private Resource. Property. Set prop. Set; /* Resource properties */ private int value; private String last. Op; /* Get/Setters for the RPs */ public int get. Value() { return value; } public void set. Value(int value) { this. value = value; } public String get. Last. Op() { return last. Op; } public void set. Last. Op(String last. Op) { this. last. Op = last. Op; } /* Required by interface Resource. Properties */ public Resource. Property. Set get. Resource. Property. Set() { return this. prop. Set; } …
A bit of syntax
Step 2: Implementing the service in Java /* Constructor. Initializes RPs */ What we have just seen is the simplest type of resource public Math. Service() throws Remote. Exception { creation: using Reflection. Resource. Property to this. prop. Set = new Simple. Resource. Property. Set( represent each resource property Math. QNames. RESOURCE_PROPERTIES); /* Initialize the RP's */ try { Resource. Property value. RP = new Reflection. Resource. Property (Math. QNames. RP_VALUE, "Value", this); this. prop. Set. add(value. RP); set. Value(0); Resource. Property last. Op. RP = new Reflection. Resource. Property (Math. QNames. RP_LASTOP, "Last. Op", this); this. prop. Set. add(last. Op. RP); set. Last. Op("NONE"); } catch (Exception e) { throw new Runtime. Exception(e. get. Message()); } }
Step 2: Implementing the service in Java Finally, we need to provide the implementation of our remotely-accessible methods (add, subtract, and get. Value. RP) public Add. Response add(int a) throws Remote. Exception { value += a; last. Op = "ADDITION"; return new Add. Response(); } /*** subtract implementation is similar ***/ public int get. Value. RP(Get. Value. RP params) throws Remote. Exception { return value; }
How document/literal bindings affect our parameters Whenever we write an operation which is part of our WSDL interface (such as add, subtract, or get. Value. RP), the parameters and the return values will in some cases be 'boxed' inside stub classes (which are generated automatically from the WSDL file). For example, if we declared the following operation in our WSDL file: void multiply(int a 1, int a 2); The actual Java code would look like this: public Multiply. Response multiply(Multiply params) throws Remote. Exception { int a 1 = params. get. A 1(); int a 2 = params. get. A 2(); // Do something return new Multiply. Response(); } Multiply and Multiply. Response are stub classes. Notice how the two parameters (a 1 and a 2) are 'boxed' inside a single Multiply parameter, and how we return a Multiply. Response object, even though we don't really want to return anything.
Step 3: Configuring the deployment in WSDD (and JNDI) The Web Service Deployment Descriptor (WSDD): Will be transfered into something like: http: //localhost: 8080/wsrf/services/examples/core/first/Math. Service Our implementation Notice how there's a "_service" at the end of the filename. This is not a typo. This WSDL file (Math_service. wsdl) will be generated automatically by a GT 4 tool when we compile the service.
Step 3: Configuring the deployment in WSDD (and JNDI) The Java Naming and Directory Interface (JNDI) deployment file, barely comes into play in this simple example:
Step 4: Create a GAR file with Ant
Step 5: Deploy the service into a Web Services container globus-deploy-gar $EXAMPLES_DIR/org_globus_example s_services_core_first. gar globus-undeploy-gar org_globus_examples_services_core_first
A simple client 1/2 n This client expects one argument from the command line: The service URI package org. globus. examples. clients. Math. Service_instance; import org. apache. axis. message. addressing. Address; import org. apache. axis. message. addressing. Endpoint. Reference. Type; import org. globus. examples. stubs. Math. Service_instance. Math. Port. Type; import org. globus. examples. stubs. Math. Service_instance. Get. Value. RP; import org. globus. examples. stubs. Math. Service_instance. service. Math. Service. Addressing. Locator; public class Client { public static void main(String[] args) {
A simple client 2/2 This endpoint reference is used to address a Math. Service. Addressing. Locator locator = new particular WS-Resource (the pairing of a Math. Service. Addressing. Locator(); service and a resource). try { String service. URI=args[0]; Endpoint. Reference. Type endpoint = new Endpoint. Reference. Type(); endpoint. set. Address(new Address(service. URI)); Math. Port. Type math = locator. get. Math. Port. Type. Port(endpoint); // Perform an addition Math. Service. Addressing. Locator, given the math. add(10); service's endpoint, returns a Math. Port. Type object // Perform another addition that will allow us to contact the Math port. Type. Once we have that reference, we can work with the web service math. add(5); // Access value as if it were a local object. System. out. println("Current value: " + math. get. Value(new Get. Value. RP())); // Perform a subtraction All the remote operations can throw math. subtract(5); Remote. Exceptions (for example, if there is a // Access value network failure and we can't contact the service). System. out. println("Current value: " + math. get. Value(new Get. Value. RP())); } catch (Exception e) { e. print. Stack. Trace(); } }
Testing… java -classpath. /build/stubs/classes/: $CLASSPATH org. globus. examples. clients. Math. Service_instance. Client http: //127. 0. 0. 1: 8080/wsrf/services/examples/core/first/Math. Service If all goes well, you should see the following: Current value: 15 Current value: 10 Now, remember that our service is, at the same time, the resource itself. So, if we invoke the service repeatedly, we will access the same stateful information. If you run the client a couple more times, you should see the value increase with each run: Current value: 25 Current value: 20 Current value: 35 Current value: 30
The WS-Resource factory pattern n In this pattern, we are not allowed to create instances of objects directly, but must do so through a factory that will provide a create operation
Implementing the WS-Resource factory pattern in GT 4
What did till now was: o n e did W … ny use a t it did e ): e DI file e. Hom (in JN urc sed Reso We u ice l. Serv imp wsrf. bus. W We d id it lo org. g W d e di it
What did till now was: n <resource name="home" type="org. globus. wsrf. impl. Service. Resource. Home">
To implement the WS-Resource factory pattern in GT 4 we need: To im ne this o ent plem ) (a bit nge ne o d this An a To ch To s epar ate t he im plem enta tion
Sequence diagram for resource creation
Sequence diagram for WSResource invocation
The factory service WSDL: <? xml version="1. 0" encoding="UTF-8"? > <definitions name="Factory. Service" target. Namespace="http: //www. globus. org/namespaces/ examples/core/Factory. Service" xmlns="http: //schemas. xmlsoap. org/wsdl/" xmlns: tns="http: //www. globus. org/namespaces/ examples/core/Factory. Service" xmlns: wsa="http: //schemas. xmlsoap. org/ws/2004/03/ addressing" xmlns: wsdl="http: //schemas. xmlsoap. org/wsdl/" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema"> The service's create. Resource operation returns an endpoint reference, a structure that is part of the WS-Addressing specification. We need to declare the WS-Addressing namespace.
The factory service WSDL: <types> <xsd: schema target. Namespace= "http: //www. globus. org/namespaces/examples/core/Factory. Service" xmlns: tns= "http: //www. globus. org/namespaces/examples/core/Factory. Service" xmlns: xsd="http: //www. w 3. org/2001/XMLSchema"> <xsd: import namespace= "http: //schemas. xmlsoap. org/ws/2004/03/addressing" schema. Location=". . /ws/addressing/WS-Addressing. xsd" /> <!-- REQUESTS AND RESPONSES --> <xsd: element name="create. Resource"> <xsd: complex. Type/> </xsd: element> <xsd: element name="create. Resource. Response"> <xsd: complex. Type> <xsd: sequence> <xsd: element ref="wsa: Endpoint. Reference"/> </xsd: sequence> </xsd: complex. Type> </xsd: element> </xsd: schema> </types>
The factory service WSDL: <!--M E S S A G E S --> <message name="Create. Resource. Request"> <part name="request" element="tns: create. Resource"/> </message> <message name="Create. Resource. Response"> <part name="response" element="tns: create. Resource. Response"/> </message> Our port. Type, Factory. Port. Type, has a single operation create. Resource. <!-- P O R T T Y P E --> <port. Type name="Factory. Port. Type"> <operation name="create. Resource"> <input message="tns: Create. Resource. Request"/> <output message="tns: Create. Resource. Response"/> </operation> </port. Type> </definitions>
The factory service Java implementation: public class Math. Factory. Service { /* Implementation of create. Resource Operation */ public Create. Resource. Response create. Resource(Create. Resource request) throws Remote. Exception { } … Inside this method, we will perform three steps: n Retrieve the resource home. n Use the resource home to create a new resource. n Create the endpoint reference we will return to the client. This EPR must contain the instance service's URI and the new resource's key.
The factory service Java implementation: n. Retrieve the resource home. Resource. Context ctx = null; Math. Resource. Home home = null; Resource. Key key = null; try { ctx = Resource. Context. get. Resource. Context(); home = (Math. Resource. Home) ctx. get. Resource. Home(); key = home. create(); } catch (Exception e) { throw new Remote. Exception("", e); n. Use the resource home to create a new resource. }
URL(protocol, host, port, "/" + config. get. WSRFLocation()); Endpoint. Reference. Type epr = null; try { URL base. URL = Service. Host. get. Base. URL(); String instance. Service = (String) Message. Context . get. Current. Context(). get. Service(). get. Option("instance"); String instance. URI = base. URL. to. String() + instance. Service; /* The endpoint reference includes the instance's URI and the resource key */ epr = Addressing. Utils. create. Endpoint. Reference(instance. URI, key); § Create the endpoint reference we will return to } catch (Exception e) { the client. This EPR must contain the instance throw new Remote. Exception("", e); service's URI and the new resource's key. } Create. Resource. Response response = new Create. Resource. Response(); response. set. Endpoint. Reference(epr); return response;
The big picture: Nee ds t Weo be just imp did lem it ente d To m odif y (a bi Nee t) To s epar ds to be im ate t he Ourimple next men steptation plem e nted
The instance service public Add. Response add(int a) throws Remote. Exception { Math. Resource math. Resource = get. Resource(); math. Resource. set. Value(math. Resource. get. Value() + a); math. Resource. set. Last. Op("ADDITION"); return new Add. Response(); Resource. Context will look inside the endpoint reference that } is used to invoke add, extract the resource key, and lookup the corresponding resource through the resource home private Math. Resource get. Resource() throws Remote. Exception { Object resource = null; try { resource = Resource. Context. get. Resource. Context(). get. Resource(); } catch (Exception e) { throw new Remote. Exception("", e); } Math. Resource math. Resource = (Math. Resource) resource; return math. Resource; }
The resource public class Math. Resource implements Resource, Resource. Identifier, Resource. Properties { } /* Resource key. This uniquely identifies this resource. */ private Object key; /* Required by interface Resource. Identifier */ public Object get. ID() { return this. key; } /* Initializes RPs and returns a unique identifier for this resource */ public Object initialize() throws Exception { this. key = new Integer(hash. Code()); // Initialize the resource properties return key; }
The big picture: d e di it W ep st next ur it did e O W We id st d it ju We ju it did st
The resource home Notice that this must be done using the protected package org. globus. examples. services. core. factory. impl; create. New. Instance method, not by using the new operator. import org. globus. wsrf. Resource. Key; Also, since create. New. Instance returns a Resource object, we import org. globus. wsrf. impl. Resource. Home. Impl; must cast it to our specific resource type: Math. Resource. Type import org. globus. wsrf. impl. Simple. Resource. Key; public class Math. Resource. Home extends Resource. Home. Impl { public Resource. Key create() throws Exception { // Create a resource and initialize it Math. Resource math. Resource = (Math. Resource) create. New. Instance(); math. Resource. initialize(); We initialize the resource. // Get key Resource. Key key = new Simple. Resource. Key(key. Type. Name, add is a protected method of math. Resource. get. ID()); Resource. Home. Impl // Add the resource to the list of resources in this home add(key, math. Resource); key. Type. Name is a protected return key; } attribute of Resource. Home. Impl containing the key's type }
The big picture: t s o lm A E N O D
Deployment – JNDI 1/2 <? xml version="1. 0" encoding="UTF-8"? > <jndi. Config xmlns="http: //wsrf. globus. org/jndi/config"> <!-- Instance service --> <service name="examples/core/factory/Math. Service"> <resource name="home" type="org. globus. examples. services. core. factory. impl. Math. Resource. Home"> <resource. Params> <parameter> <name>resource. Class</name> <value>org. globus. examples. services. core. factory. impl. Math. Resource</value> </parameter> <parameter> <name>resource. Key. Type</name> <value>java. lang. Integer</value> </parameter> <parameter> <name>resource. Key. Name</name> <value> {http: //www. globus. org/namespaces/examples/core/Math. Service_instance}Math. Reso urce. Key </value> </parameter> <parameter> <name>factory</name> <value>org. globus. wsrf. jndi. Bean. Factory</value></parameter> </resource. Params> </resource> </service>
Deployment – JNDI 2/2 <!-- Factory service --> <service name="examples/core/factory/Math. Factory. Service"> <resource. Link name="home" target="java: comp/env/services/examples/core/factory/ Math. Service/home"/> </service> </jndi. Config> The factory service uses the same resource home as the instance service. So, we do not need to repeat all the parameters of the instance service. We simply have to include a <resource. Link> tag linking to the previously specified resource home. Notice that we must do so using a special path.
Modified simple client Factory. Service. Addressing. Locator factory. Locator = new Factory. Service. Addressing. Locator(); Math. Service. Addressing. Locator instance. Locator = new Math. Service. Addressing. Locator(); try { String factory. URI = args[0]; Endpoint. Reference. Type factory. EPR, instance. EPR; Factory. Port. Type math. Factory; Math. Port. Type math; factory. EPR = new Endpoint. Reference. Type(); factory. EPR. set. Address(new Address(factory. URI)); math. Factory = factory. Locator. get. Factory. Port. Type. Port(factory. EPR); Create. Resource. Response create. Response = math. Factory . create. Resource(new Create. Resource()); instance. EPR = create. Response. get. Endpoint. Reference(); math = instance. Locator. get. Math. Port. Type. Port(instance. EPR); // Instance created , now perform an addition math. add(10); …
What is Notifications ? Suppose a client applications wants to know when the load of a server drops below 50% Option A:
What is Notifications ? Option B:
WS-Notifications n n The WS-Notifications family of specifications, although not a part of WSRF, has strong ties to it. It provides a set of standard interfaces to use the notification design pattern with Web Services. WS-Notifications is divided into three specifications: ¨ WS-Topics, ¨ WS-Base. Notification, and ¨ WS-Brokered. Notification.
WS-Topics n n Topics, which are used by the other two specifications in WS-Notifications to present a set of "items of interest for subscription". A service can publish a set of topics that clients can subscribe to, and receive a notification whenever the topic changes It is possible to create topic trees, where a topic can have a set of child topics. By subscribing to a topic, a client automatically receives notifications from all the descendant topics.
WS-Base. Notification
WS-Brokered. Notification Not supported in current Globus Toolkit 4 implementation
Secure communication – 3 pillars n n n Privacy Only the sender and the receiver should be able to understand the conversation Integrity Receiving end must be able to know for sure that the message he is receiving is exactly the one that the transmitting end sent him. Authentication Should ensure that the parties involved in the communication are who they claim to be
Authorization Mechanisms that decide when a user is authorized to perform a certain task. Authorization is related to authentication because we generally need to make sure that a user is who he claims to be (authentication) before we can make a decision on whether he can (or cannot) perform a certain task (authorization).
A bit of cryptography
Digital signatures: Integrity in public-key systems n Text is not encrypted, only the Digest
Authentication - Certificates n A digital certificate is a digital document that certifies that a certain public key is owned by a particular user.
It's all about trust You have to trust the CA (Certificate Authority) that signs the certificate n The public-key system you use will generally have a list of 'trusted CAs' n
X. 509 certificate format n n Subject: This is the 'name' of the user. It is encoded as a distinguished name (the format for distinguished names will be explained next) Subject's public key: This includes not only the key itself, but information such as the algorithm used to generate the public key. Issuer's Subject: CA's distinguished name. Digital signature: The certificate includes a digital signature of all the information in the certificate. This digital signature is generated using the CA's private key. To verify the digital signature, we need the CA's public key (which can be found in the CA's certificate).
Distinguish Names The names are encoded as distinguished names, which are a comma-separated list of name-value pairs. O=University of Chicago, OU=Department of Computer Science, CN=Borja Sotomayor n. O : Organization n. OU : Organizational Unit n. CN : Common Name (generally, the user's name) n. C : Country
GSI: Grid Security Infrastructure GSI implementation in GT 4 is composed of a set of command-line tools to manage certificates, and a set of Java classes to easily integrate security into our web services. GSI offers programmers the following features: ¨ Transport-level and message-level security ¨ Authentication through X. 509 digital certificates ¨ Several authorization schemes ¨ Credential delegation and single sign-on ¨ Different levels of security: container, service, and resource
Transport-level vs. message-level security Both transport-level and message-level security in GSI are based on public-key cryptography and, therefore, can guarantee privacy, integrity, and authentication.
Transport-level vs. message-level security n n n GSI Secure Conversation: Provides message-level security and is based on the WS-Secure. Conversation specification. When this method is chosen, a secure context is first established between the client and the server. After an initial exchange of messages to establish the context, all the following messages can reuse that context, resulting in a better performance than GSI Secure Message (if the overhead of setting up the context is acceptable). Furthermore, GSI Secure Conversation is the only scheme that supports credential delegation (explained further on). GSI Secure Message: Provides message-level security and is based on the proposed WS-Security standard. GSI Transport: Provides transport-level security by using TLS (formerly known as SSL). It provides the best performance and is used by default in GT 4.
Authentication n X. 509 certificates: All three protection schemes seen above can be used along with X. 509 certificated to provide strong authentication. n Username and password: A more rudimentary form of authentication, using usernames and passwords, can also be used. However, when using usernames and password, we will not be able to use features like privacy, integrity, and delegation. n Anonymous authentication: We can request that a communication be anonymous, or unauthenticated.
Server-side authorization n None: This is the simplest type of authorization. No authorization will be performed. n Self: A client will be allowed to use a service if the client's identity is the same as the service's identity. n Gridmap: A gridmap is a list of 'authorized users' akin to an ACL (Access Control List). . When this type of authorization is used, only the users that are listed in the service's gridmap may invoke it. n Identity authorization: A client will be allowed to access a service if the client's identity matches a specified identity. In a sense, this is like having a one-user gridmap (except that identity authorization is configured programmatically, whereas the gridmap is represented as a file in our system). n Host authorization: A client will be allowed to access a service if it presents a host credential that matches a specified hostname. In other words, we will only allow requests coming from one particular host. n SAML Callout authorization: We can delegate the authorization decision to an OGSA Authorization-compliant authorization service. OGSA-Authz (http: //forge. gridforum. org/projects/ogsa-authz) is a GGF working group whose goal is to specify standard authorization components. One of the main technologies used in these components is SAML (Security Assertion Markup Language).
Delegation and single sign-on (proxy certificates) n The problem:
Delegation and single sign-on (proxy certificates) If Charlie does not trust Bob, but trusts Alice he can: n Turn down Bob's request. Charlie doesn't trust Bob, and that's that n Accept Bob's request. The 'original' requester is Alice so, although Charlie is answering a request from Bob, it will actually be carrying out a job for Alice.
Delegation and single sign-on (proxy certificates) n Bob should ask Charlie to perform the request on behalf of Alice. n Do you see any problem here? Greedy Bob will enslave naive Charlie with his work…
The solution: proxy certificates n Proxy certificates extend ordinary X. 509 certificates with extra security features to limit their functionality even more (for example, by specifying that a proxy certificate can only be used for certain tasks).
The solution achieves: Delegation and single sign-on n Proxy certificates allow a user to effectively delegate a set of credentials (the user's identity) to another user Using proxy certificates, the user only has to sign in once to create the proxy certificate. The proxy certificate is then used for all subsequent authentications. Reduces the risk of having my conversations compromised because an attacker would only have a chance to crack the proxy's key pair, and not my personal one (which would only be used to generate the proxy certificate).
The End…
Скачать презентацию Introduction to Grid programming with Globus Toolkit 4
b740350f78966b0cdbaee49dba511dd7.ppt