On Utilization of Grid Computing and SOA in 3D Rendering: A Case on POV-Ray

On Utilization of Grid Computing and SOA in 3D Rendering: A Case on POV-Ray

*1 Qusay. F. Hassan, 2Alaa. M. Riad, 3Ahmed. E. Hassan

1, Faculty of Computers and Information Systems, Mansoura University, Egypt, [email protected]

2, Faculty of Computers and Information Systems, Mansoura University, Egypt, [email protected]

3, Faculty of Engineering, Mansoura University, Egypt, [email protected]

Abstract Researchers and organizations opt to use supercomputers and parallelism to process slow and

computationally-intensive tasks faster. 3D rendering is one of the typical scenarios where high-performance computing resources are used to complete the job fast and efficiently. Grid computing is one of the parallelism techniques that enable adopters to combine and use available resources to utilize them in the processing of computationally-expensive processes and simulations. Integrating Service-Oriented Architecture (SOA) into grid computing provides better accessibility for the available resources. This paper demonstrates how SOA and grid computing can be integrated to perfect the rendering of POV-Ray 3D models.

Keyword: Grid Computing, SOA, Ray Tracing, POV-Ray, 3D Rendering, Integration between SOA

and Grid Computing, REST, Web Services

1. Introduction Computer graphics is one of the most challenging and exciting branches in the field of computer

science. Both researchers and professionals work towards making the best use of computing resources to produce high-quality outputs that they can directly or indirectly use. Visual effects and movies are examples of direct applications of computer graphics, whereas 3D simulations and representations of protein folding, during the design of new drugs, are just a few examples of the indirect use.

As is known, 3D rendering is a slow and compute-intensive process that usually comprises a large number of complex calculations. These calculations aim at defining the features that will be included in the final output such as lighting, shading, fogging, shadows, reflection, illumination, transparency and many other features.

This limitation has challenged 3D animation companies to search for solutions that would decrease the rendering time. For example, some companies had to invest in hardware like supercomputers and accelerated graphics processing units (GPUs) to save rendering time. Other companies outsource the rendering process to commercial rendering services online (such as RenderFlow, RebusFarm and ResPower). These services deploy powerful farms that are composed of hundreds of computers solely dedicated to the rendering process. Usually, companies with limited budgets cannot meet the costs of these solutions, resulting in artists to work overtime to render their models.

Ray tracing is a computer graphics technique meant for generating high-quality, photorealistic images by tracing the path of light through the image plane and simulating the optical effects of the objects in the scene [1]. A wide range of software products (open source, freeware and commercial) that support the ray tracing are available on the market, including Autodesk Maya, Autodesk 3ds max, Blender and POV-Ray. Each of these products comes with a set of features, platform support and licensing terms. POV-Ray sits on top of applications that render 3D models using the ray tracing technique.

Researchers opt to utilize the parallel computing model to harness the power of multiple cores, processors and standalone machines to reduce the execution time. Parallelism technique, mainly by means of multi-processors and multi-cores and recently specialized GPUs is heavily studied, to question its applicability to computer graphics. In theory, the option to concurrently render different slides of complex 3D models on different processors/cores would generate the final images and scenes much faster.

Advances in information Sciences and Service Sciences(AISS) Volume6, Number4, August 2014

On Utilization of Grid Computing and SOA in 3D Rendering : A Case on POV-Ray Qusay. F. Hassan, Alaa. M. Riad, Ahmed. E. Hassan

15

Grid computing is a form of parallelization that can be utilized to make 3D images and films in less time [2]. This goal can be achieved by networking a number of machines to produce different images of a complete scene(s), simultaneously. Building grids from traditional desktops/ laptops at enterprises is known as Desktop Grids or Enterprise Grids [3]. Offices, departments, subsidiaries, universities and laboratories have a set of computers that are used by their members to accomplish the work-related tasks.

Service-Oriented Architecture (SOA) is a software design model that offers software functionality as a collection of accessible, abstracted and loosely-coupled services [4]. Due to the high level of abstraction, transparency and loose-coupling offered by SOA, IT professional and researchers have shown a keen interest in the integration into grid computing over the past decade [5].

This paper proposes a framework that utilizes desktop grids to speed up the rendering phase of the 3D image using POV-Ray. On top of the grid resources, a set of RESTful web services will be built to abstract these resources to obtain easy access. The remainder of this paper is organized as follows: Introduction to Grid Computing, SOA and the integration between them is presented in section 2. Section 3 introduces the ray tracing technique and POV-Ray tool. Section 4 briefly discusses the technologies used to implement the demonstrated SOA-enabled desktop grid. In section 5, the authors present a framework for rendering 3D models. Section 6 is dedicated to performance evaluation of the proposed model versus both the non-grid-enabled and non-SOA-grid-enabled models. Finally, section 7 concludes.

2. Grid Computing and SOA

3.1. Grid Computing

Often, supercomputers are utilized when enormous resources are needed to solve computationally-

intensive problems fast and efficiently. However, in many enterprises, especially small-to-medium enterprises (SMEs), universities and non-profit organizations, it is difficult to afford such solutions. Here, they can deploy grid computing to solve complex problems. This model is usually referred to as Enterprise Grids [6].

Grid computing allows organizations to have supercomputer-like performance at a lower cost. This goal is accomplished by networking these resources in a way, enabling end users to use them autonomously as if they are all coming from a single powerful computer [2]. Examples to the fields that utilize grid computing include urban planning, risk analysis, financial pricing/modeling, pharmaceutical engineering, forecasting and 3D rendering.

As mentioned earlier, grid computing is a form of the parallel computing models, where processing takes place concurrently on a number of nodes (aka hosts). These nodes can combination or one of the following: be standalone machines, servers, clusters or even supercomputers. Interaction between the grid nodes can take different forms. Master/Worker parallel model is one of the commonly followed paradigms in grid computing. As its name denotes, this model is composed of two constituent parts: 1) Master, which is a central node (or cluster of nodes) that is responsible for scheduling and dispatching the work units, and receiving the results; 2) Workers, which work together to process the assigned jobs. Grid workers can be either dedicated or non-dedicated. Dedicated workers are always available to complete the incoming jobs; whereas, non-dedicated workers only join the grid when they are idle to voluntarily run the jobs, and then exit when needed to perform traditional tasks.

In the grid computing model, the user sends a complex and computationally-expensive job to the master node via grid-enabled client application. This client application is responsible for breaking each complex task into a number of smaller and simpler sub-jobs (aka sub-tasks). Then, the master node allocates workers in order to assign the queued sub-jobs to them. The result of every completed sub-job is sent back to the master, which forwards back to the client. According to the client application logic, it can decide whether to use the received results "as is" or to execute some post-processing operations such as formatting the results or combining them into a single output.

Grids can take different topologies depending on the scope of the problem that it is designed to solve and the size of resources that it is designated to manage [6]. The main grid topologies are: 1) Infra-grid, which is the simplest form of grid computing, as it is composed of a few machines to enable sharing of the resources within a single division of an organization. 2) Intra-grid (aka enterprise grid), which allows the sharing of resources within an enterprise by linking different infra-grids together. 3) Extra-grid,


16

which allows two or more groups to work together by sharing their intra-grids. 4) Inter-grid, which allows multiple groups to share and access their grids through WANs or the Internet.

3.2. Service-Oriented Architecture (SOA)

SOA is a design and programming model that offers software functionality as a collection of

accessible and loosely-coupled services [4]. The goal of SOA is to offer software solutions that enable adopters to flexibly build and integrate software applications in an agile form. This includes the ability to use legacy applications, change implementation logic without affecting the clients, and integrate with other systems regardless of the used technologies.

Services are the building blocks of the SOA model, where they can communicate, pass information and coordinate business workflows, whilst abstracting technical details. A service is a well-defined, self-contained block composed of a set of operations and components, built in a way that allows them to be dynamically integrated to cover technical/business needs or both [4]. The functionality of the service may range from simple tasks to complete business workflows. Each service is composed of three constituent elements: 1) Service Contract: Provides the definition of the service scope, purpose, functionality, as well as formal specifications such as the programming language, middleware, network protocols and run-time environment. 2) Service Interface: A proxy class that exposes public operations to the users. 3) Service Implementation: The actual implementation of the service. Service makers guarantee the separation between these elements to offer agility in meeting changing requirements, without affecting the users, and making maintenance tasks easier.

In SOA model, there are there key players: 1) Service Provider: This is responsible for managing all aspects of the provided services. These aspects include the creation, hosting, publishing of the services, purchasing/leasing, deploying the hardware to maintenance, and the update of the services as well as the administration of the underlying components. 2) Service Client: Finds and uses services that meet its requirements. Request/reply model, where the user requests a function from the provider and the provider, in return, replies with the relevant response is a typical interaction form between the service clients and providers. 3) Service Broker: Enables the provider to publish and register his/her services with all information that allows the clients to find and use them.

Various tools and environments can be used to implement SOA-based applications such as Message Queues, COM, EJB, Jini and CORBA. XML web services are at the top of the implementation technologies list of SOA-based applications. XML web services are the most preferred technology because they are standard-based with great support from big software players in the market such as Microsoft and IBM. Standardization guarantees interoperability between service providers and clients. Implementations are lowered in cost when compared with those based on proprietary technologies. Furthermore, XML web services are easy to use with the ability to create different services for different modules.

3.3. Integration between SOA and Grid Computing

Due to the advantages of the SOA model, utilization of SOA in grid computing has been of interest

to both IT professionals and researchers since its emergence [5]. Open Grid Services Infrastructure (OGSI) [7] and Open Grid Services Architecture (OGSA) [8] are

some typical examples to the standards yielded to enable an efficient integration between SOA and grid computing. The movement from OGSI to WS-Resource Framework (WSRF) was the next big step towards building stateful and reliable grid services [9].

Exposing the grid resources through a set of web services can help in abstracting the complexities of the underlying resources (both hardware and software), with more transparency. This results in a higher degree of loose-coupling between the service providers and callers. In other words, in the SOA model, the developers of one party can flexibly change the structure/logic/data format of their applications or services without affecting any other party. On the front-end layer, any client application can be programmed and integrated with the back-end to send tasks to the underlying grid and receive the results. Grid client applications can take different forms such as console, desktop, web or even mobile applications.


17

3. Ray Tracing The idea of ray tracing is simply to simulate the light source as it emits a light beam that eventually

hits physical objects existing in its path to becoming visible [1]. In reality, when an object interrupts the path of a light ray, one or more of the following scenarios may occur: 1) The object may absorb a portion of that light ray, resulting in the loss of the light intensity. 2) The object may reflect part or all of the light. 3) If the surface is transparent, it refracts some of the light beam into itself in different directions. 4) The surface may absorb a portion of the light and fluorescently re-emits it at a longer wavelength color in a random direction.

In ray tracing, the quality of the generated images solely depends on the number of emitted light rays. In other words, the higher number of light rays emitted generates higher quality and photo-realistic images. That is why in many cases, designers shoot multiple light rays for each single pixel in the image.

The ray tracing technique can efficiently and effectively simulate reflections and shadows that are difficult to simulate with other conventional techniques. However, the ray tracing technique is slow and computationally expensive due to the extensive generation of light rays. This limitation makes ray tracing more suitable for rendering images and films that usually take long periods of time, and are less suitable for real-time applications like video games.

POV-Ray is one of the popular and widely used ray tracing programs [10]. POV-Ray is a freeware program that is distributed under the POV-Ray license, which allows the distribution of the program and its source code. Though, it restricts commercial use and the creation of derivative works. The current available release of POV-Ray is 3.7, which is distributed in compiled formats for Windows, Linux and Macintosh. POV-Ray has a number of excellent features including support for textures, reflections, refractions, radiosity, fog, smoke, clouds, bump mapping, various types of light sources, a library of ready-made objects, scenes and textures.

The creation of POV-Ray scenes can be made by writing scripts using the Scene Description Language (SDL), which comes as a core component of the program. SDL has a number of constructs that enables the programmers and the art designers to build complex scenes. These capabilities include support for background colors, camera and lights. Scene files are saved in ".pov" format which may refer to external libraries (".inc") and animation initialization files (".ini").

Interactions with POV-Ray usually occur through the provided graphical user interface (GUI) editor. In addition, command-line options are available so that users can write scripts and batches that can either be manually launched or automatically executed from within other programs.

4. Used Technologies

4.1. .NET

Since most organizations use Windows as an operating system for their computers, the demonstrated

implementation will target Windows environment. .NET Framework (pronounced as "dot net") is a cutting-edge development technology offered by Microsoft for Windows environment. A number of .NET-based technologies are now available in the market for grid computing. This work uses an open-source grid-enabling technology known as Alchemi, which can be downloaded from [11].

.NET framework enables developers to create web services with ease, both WS-* and RESTful web services, through the Windows Communication Foundation (WCF). WCF is like a service bus that would enable interoperability and integration between different systems through a set of secured and accessible services [12]. Namely, WCF framework offers a set of libraries, classes and tools that allow .NET developers to build SOA-based applications and expose the functions of their systems through a set of web services.

4.2. Alchemi

In this paper, the authors have used Alchemi to implement our grid. Alchemi is a grid-enabling middleware with a set of Application Programmable Interfaces (APIs) developed by the GRIDS research team at Melbourne University [11]. Alchemi is composed of three main components: 1) Manager, which is responsible for managing the available grid nodes. 2) Executor, which acts like a grid worker that


18

processes tasks. 3) Dashboard, which enables implementers to monitor the state and utilization of their grid(s), and the number of running applications and executors.

Alchemi deploys a thread-like programming model that enables subdivision of the targeted computational process into a set of smaller units so that it can distribute them over the available number of executors [13]. The manager queues the created jobs that are scheduled according to the availability of executors. If the number of queued jobs is higher than the available executors, the manager assigns a number of jobs for those executors. When an assigned job has been completed, the manager then sends a new job to the returning executor, and so forth.

4.3. Representational State Transfer (REST)

REST has gained global acceptance in the Web design and development community as an architecture

model for developing web applications [14]. Being an architectural style means that there is no official standard for building RESTful services; however, recommendations and best practices are available [15]. Some modern SOA-based implementations use REST style to return (representation) information responsively in different data format such as HTML, MIME, and plain-text. Typically, as in the Web, anything in REST is a resource with a unique resource identifier (URI) that can be easily accessed via HTTP protocol from traditional browsers. These resources (or services) are seen as a set of directory-like URIs.

Requests, responses and objects can be transferred in XML, JSON, or both via XHTML. MIME types are used to control data formats being used by the RESTful services. Clients choose the data format that best fits his/her needs by using built-in HTTP Accept headers, namely application/xml (for XML), application/json (for JSON), or application/xhtml+xml (XHTML).

In RESTful web service, a service provider is responsible for providing one or more resource representations that reflect the state of the resource when the client requests it [14]. All these details are controlled and managed by the implementation code written by the providers. On the other side, the client can access the offered web services through four verbs (operations): POST (to create a new resource); GET (to retrieve a resource); PUT (to replace a resource or change its state); and Delete (to remove a resource). The service providers implement these verbs, mainly to build a Web API that establishes a mapping between CREATE, READ, UPDATE, and DELETE (CRUD) operations and HTTP verbs.

Access to RESTful services occurs in a stateless form where the server (or a cluster of servers) does not store any state or context between requests. Thus, every request must embody, in HTTP headers, all information needed by the service in order to process it. This statelessness, of course, improves the scalability and performance of the designed services, and simplifies the design of the implemented services as well [16].

Lack of events and notifications is a limitation of the RESTful model. This issue can be easily resolved by enabling the client to check the service/function status. Selecting the right frequency of client polling is crucial for a successful and responsive implementation.

Famous websites offer access to their resources through a set of web APIs that are built using the RESTful web services, including Amazon, Yahoo, YouTube, Facebook, Google, Twitter and PayPal.

5. Methodology 5.1. Grid-Enabling the Rendering Process

3D rendering of a large, high-resolution, deep image, which contains many details and visual effects

can take several hours to execute on a single computer. Similarly, 3D rendering of one short, high-resolution scene might take days to complete on a single computer. The ability to aggregate the computing power of the underutilized computers existing at enterprises can reduce the time taken in the rendering phase significantly, while also increasing the return on investment (ROI) of these resources [17].

As illustrated in Figure 1, the prposed framework is simple in which: 1. A user (programmer or artist) submits the created ".pov" file (and any supplementary files

such as libraries ".inc" or animation scenario ".ini") to the desktop grid either through the GUI layer laid on top of the grid-enabled application or by manually copying it to a known


19

path. Regardless of whether the ".pov" file is passed to the grid by the grid-enabled application or manually copied, it must be set in a location that can be accessed by all grid nodes (e.g., network folder or database).

2. The grid-enabled application creates the grid jobs according to the settings specified by the user and then forwards them to the grid.

3. The manager schedules the jobs and sends them to the free executors. 4. POV-Ray must be installed on each executor prior to the implementation of this model.

When an executor receives a rendering job from the manager, it launches POV-Ray in a separate process and passes the arguments accompanied by the job.

5. POV-Ray renders the job, and when the output result is ready, the launched process exits itself and the executor returns the results back to the manager.

6. The manager then forwards back the rendered outputs to the grid-enabled application and fires "ThreadFinished" event if successfully completed or "ThreadFailed" event if an error has occurred. The implementers should save the rendered jobs on shared media that all executors can access.

7. When all jobs are completed, the manager fires the "ApplicationFinished" event. This event enables programmers to post-process results and release resources when the whole application completes.

Each image is composed of a set of rows and columns containing pixels –this is what is known as image resolution. The ability to slice an image into a set of meaningful segments (e.g., of rows, columns or rectangular tiles), leads to rendering them on different computers and can drastically decrease the time needed to generate the final output.

During the implementation of this work, the authors decided to subdivide the rendering task of one image into a number of subtasks where each subtask encompasses a set of rows. Thus, this algorithm has three consequent phases: Render, Crop and Combine (RCC). Figure 2, illustrates the stages of the RCC algorithm.

As listed below, the proposed algorithm is simple to understand and implement: 1. The end user specifies the height and width of the target image along with the passed ".pov"

file. In addition, the user can optionally define the number of rows per job and pass it to the client application.

2. The client application creates the grid jobs and submits them to the manager node. Each job has a rendering command for a portion of the targeted image.

3. The manager node passes the queued jobs to the connected executors. 4. Each executor launches the POV-Ray application by starting an external process in Windows

using the "Process" class provided by .NET Framework. 5. POV-Ray generates the (partial) image according to the particular options, and then stores it

on the specified output path. Implementers should note that all grid nodes are required to have a shared output path so that all executors can save the rendered outputs. Implementers achieve this by using a network drive or a database accessible to all nodes.

6. Each completed job generates a full-sized image which has an empty (black) portion in addition to the segment that contains the rendered data.

7. After the completion of a job, the client application crops the rendered image to create a smaller version, in order to keep the non-empty segment.

8. If any of the jobs fail, the client application will queue them on a temporary list to re-process again, either on the grid or the client machine.

9. After the successful completion of all jobs, the client application merges the cropped images according to their original arrangement to produce the final image.


20

Figure 1. Framework of POV-Ray on a Desktop Grid

Figure 2. Image rendering phases using the RCC algorithm


21

5.2. Architecture

As shown in Figure 3, the architecture of the demonstrated application is composed of four layers: User Interface: This layer enables the end user to pass the rendering parameters (e.g., the ".pov" file,

output resolution, and the output path) and to display the list of rendered images. ASP.NET along with JavaScript and AJAX technologies are used to create a user interface layer. JavaScript and AJAX are used to enable client-side processing for end user requests and partial page rendering, respectively. The readers should remember that the user interface layer, in the presented scenario, is complementary. That is to say, end users can still use the grid resources and pass their rendering parameters by building their interface (such as Windows forms, web applications or mobile applications) using any platform/language on top of the offered web service(s).

Web Service: ASP.NET and WCF are used to build a web service layer. A RESTful web service is responsible for accepting the rendering parameters and giving them to the rendering APIs. The actual rendering APIs are C# classes that are grid-enabled using Alchemi APIs. This layer is a major component in this scenario as it enables authorized users to access the grid re-sources from any location, simply by invoking the right operation and passing the relevant parameters. Message to and from the RESTful web services can be transmitted in different formats such as XML, POX (plain old XML), JSON or even plain text. Selecting the data format depends on the integration requirements and scenarios. In this scenario, JSON format has been used since the GUI layer was developed using AJAX and JavaScript. In addition to the RESTful web service, an Atom (the standard version of RSS) service is developed to enable end users to get a list of rendered images. As shown in Figure 4, the web service will return a list of rendered images.

Grid Resources: This layer includes the computational power that will be used for parallel rendering

of the images. Grid resources may include dedicated (or idle) desktop machines, laptops and servers. In this scenario, an Ethernet network was created using a traditional 100 Mbps switch to connect the nodes. Only one computer is configured to manage the grid resources, and the rest of the nodes are configured as executors. Alchemi manager and executor components have been installed, configured and started on the manager and executors, respectively.

Storage: This is where the rendered images (and any related information) will be stored. Storage layer may include databases, file servers, or both.


22

Figure 3. Integrating REST into Grid Computing

Figure 4. Image rendering phases using the RCC algorithm


23

Table 1. Hardware Specifications

Node Processor RAM OS

Node 1 (Manager + Executor)

Node 2

(Executor + Output Storage)

Node 3 (Executor)

Intel Core i5 2.3 GHz

Intel Core i3 2.53 GHz

Intel Core 2 Due 2.26 GHz

4.00 GB

4.00 GB

4.00 GB

Windows 7 (64-bit)

Windows 7 (64-bit)

Windows 7 (64-bit)

6. Performance Evaluation

The authors evaluated our architecture using a test-bed composed of three laptops with different

hardware specifications. We rendered the "stackerday.pov" at different resolutions (800 x 600, 1024 x 768, 1366 x 768 and 1600 x 1200 pixels) separately on each node and then we connected the three nodes together to test the grid-enabled framework.

An Ethernet network was created using a traditional 100mbps switch to connect the nodes. Table 1 lists the hardware specifications of the used test-bed.

The authors have installed both the grid manager and executor components on Node 1 (to play both roles), as it is the most powerful node in this test-bed nodes, and the client application was also hosted on Node 1.

The authors evaluated the design before and after integrating the services layer (aka servicetization process). Firstly, the authors evaluated the use of grid computing for 3D rendering on its own; and secondly, we evaluated the design with consumable web services on top of the grid resources.

In this scenario, the authors found that the size of 50 - 100 rows per rendered job was most efficient for the exampled implementation. This number should increase or decrease according to the total number of grid nodes and image rows. When tested, we configured each job to include 80 rows.

6.1. Before Servicetization

As illustrated in Fig. 5 and 6, the total rendering time of the "stackerday.pov" image is drastically

reduced when rendered on the grid:

10. The rendering at resolution of 800 x 600 pixels on the grid is 205%, ~247% and 440% faster than the serial rendering on Node1, Node 2 and Node 3, respectively.

11. The rendering at resolution of 1024 x 768 pixels on the grid is 225%, ~329% and ~478% faster than the serial rendering on Node 1, Node 2 and Node 3, respectively.

12. The rendering at resolution of 1366 x 768 pixels on the grid is ~217%, ~320% and ~410% faster than the serial rendering on Node 1, Node 2 and Node 3, respectively.

13. The rendering at resolution of 1600 x 1200 pixels on the grid is ~226%, ~304% and ~530% faster than the serial rendering on Node 1, Node 2 and Node 3, respectively.


24

Figure 5. Serial image rendering on a single node

Figure 6. Parallel rendering on a grid of three nodes

0

1000

2000

3000

4000

5000

6000

7000

8000

Node 1 Node 2 Node 3

Time (seconds)

800 x 600

1024 x 768

1366 x 768

1600 x 1200

0

200

400

600

800

1000

1200

1400

1600

1800

2000

800 x 600 1024 x 768 1366 x 768 1600 x 1200

Time (seconds)


25

Figure 7. After servicetization vs. before servicetization

6.2. After Servicetization

As illustrated in Figure 7, building web services on top of the grid resources slightly affected the

performance of the rendering process. However, total rendering time is still much faster than the serial rendering of the "stackerday.pov" image. This change was due to: 1) adding an extra layer on top of the actual resources that accept requests in particular formats (i.e., plain text, XML and JSON), and generate results in the targeted form. This mandates clients to convert the actual request into the expected format, and then re-format the returned results before presenting them on the user interface layer. 2) Since REST model has no built-in events or notifications, the clients will be required to set the frequency at which they can handle events and check the service/function status. This means that even if the request is processed and the results are ready, the client may wait for some time (as set in the client application) before the end results can be displayed. In the presented scenario, the client is configured to monitor the service events and check the results every five seconds.

Although adding a service layer made the total rendering time somewhat slower than the non-servicetized implementation, it offers a great level of flexibility, integration and adjustability. Namely, with a set of RESTful web services on top of the grid resources, clients can efficiently send ".POV" scripts to be rendered, and then receive the generated 3D images (or videos). Likewise, wrapping grid resources would enable implementers to change the implementation/configuration of the underlying resources without affecting the clients. This would also allow other grids (either complete grid implementations or just additional grid resources) to be easily integrated with the grid application in hand. An example of this scenario is a university/organization that offers its grid to be remotely accessed by external users or to be integrated with remote grids.

7. CONCLUSION

Results show that the speed of the 3D rendering task of images increases proportionally with the

number of connected workers. This results in the implementers gaining the ability to render the presented images (and animation frames) in a few seconds if implementers can build a grid of 50 or 100 computers. Building such a grid is trivial since most organizations, universities and research labs usually have more than 50 computers. With a semi-real time rendering for complex models, organizations can do more work in much less time, and without increasing costs.

It is worth mentioning that the utilization of desktop grids for 3D rendering is not only limited to ray tracing or POV-Ray. Implementers can harness the power of grid computing with other 3D graphics and modeling software like Autodesk Maya and Blender.

0

500

1000

1500

2000

2500

800 x 600 1027 x 768 1366 x 768 1600 x 1200

After Servicetization

Before Servicetization


26

SOA is a set of design and development methodologies that are being widely embraced by software implementers to enable an easy and effective integration between different systems –both modern and legacy. With SOA, grid resources can be represented and accessed as a set of functionalities/applications/services rather than individual resources.

The authors have demonstrated how SOA can offer flexible access to the enterprise grids. By integrating SOA into grid computing, clients are platform-independent, allowing the use of or integration with the available resources. A client may only need to use a tool that enables them to call RESTful services; almost all modern programming languages and platforms will suffice. Likewise, the synergy between SOA and grid computing helps the implementers to abstract the underlying resources, which in turn exempts the clients from delving into enormous technical details.

Finally, the readers should note that the methodology presented in this paper is not limited to 3D graphics, as it can be applied to other areas that require extensive use of computation resources. Financial analysis, weather forecasting and protein folding are a just few examples of the areas that can integrate SOA, in general, and REST model, in particular, into grid computing.

8. References

[1] K. Suffern, H. H. Hu, "Ray Tracing from the Ground Up", 2007. [2] I. Foster & C. Kesselman, “The Grid 2: Blueprint for a new computing infrastructure”, 2003,

Elsevier. [3] P. Strong, "Enterprise Grid Computing", Queue 3.6, ACM, pp 50-59, 2005. [4] M. P. Papazoglou, "Service-Oriented Computing: Concepts, Characteristics and Directions",

Proceeding of the Fourth International Conference on Web Information Systems Engineering (WISE'03), 2003.

[5] Z. Mahmood, “Synergies between SOA and Grid Computing”, Communications of the IBIMA, Volume 8, pp 164-169, 2009.

[6] E. Kourpas, "Grid computing: Past, present and future. An innovation perspective", IBM white paper, 2006

[7] S. Tuecke, K. Czajkowski, I. Foster, J. Frey, S. Graham, C. Kesselman, T. Maquire, T. Sandholm, D. Snelling, P. Vanderbilt, "Open Grid Services Infrastructure (OGSI) Version 1.0 ", 2003.

[8] I. Foster, H. Kishimoto, A. Savva, D. Berry, A. Djaoui, A. Grimshaw, B. Horn, F. Maciel, F. Siebenlist, R. Subramaniam, J. Treadwell, J. Von Reich, "GFD. 80 The Open Grid Services Architecture, Version 1.5." Open Grid Forum. Vol. 5. 2006.

[9] D. Snelling, I. Robinson, and T. Banks. "OASIS web services resource framework (WSRF) TC." OASIS, 2006.

[10] http://www.povray.org/ [11] http://www.cloudbus.org/~alchemi/ [12] S. Klein, Professional WCF Programming: .NET Development with the Windows Communication

Foundation, John Wiley & Sons, 2007. [13] A. Luther, R. Buyya, R. Ranjan, S. Venugopal, “Alchemi: A .NET-Based Enterprise Grid

Computing System”, Proceedings of the 6th International Conference on Internet Computing (ICOMP'05), 2005, Las Vegas, USA.

[14] R. T. Fielding, “Architectural Styles and the Design of Network-based Software Architectures”, Chapter 5, Representational State Transfer (REST)”, PhD dissertation, 2000, University of California, Irvine.

[15] H. Hao, "Implementing REST Web services: Best Practices and Guidelines", XML.COM, Vol. 11. [16] A. Rodriguez, “RESTful Web Services: The Basics”, IBM developerWorks, 2008. [17] A. M. Riad, A. E. Hassan, and Q. F. Hassan, "Implementation and Evaluation of POV-Ray on

Desktop Grids: Parallel Rendering of 3D Images and Animations", Annals. Computer Science Series 9.2, 2011.

Acknowledge

The authors would like to thank Mandeep Kaur for her generous assistance in editing and proofreading this work.


27

On Utilization of Grid Computing and SOA in 3D Rendering: A Case on POV-Ray

Documents

Transcript of On Utilization of Grid Computing and SOA in 3D Rendering: A Case on POV-Ray