CSC/ECE 517 Fall 2009/wiki2 17 f1

Service Oriented Architecture provides another view of providing functionality based upon services offered in terms of protocols and a specific API. To provide services, platforms rely upon principles and the power that can be expressed through reflection and meta programming. Research and report how these critical concepts relate to and support SOA.

Service Oriented Architectures

Service Oriented Architecture is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations.

This makes it easier for software integration of different modules developed by different people. Rather than defining an API, SOA defines the interface in terms of protocols and functionality such that modules following these protocols can easily be integrated together. The main characteristics of SOA are:

• Based on open standards - The governing principles are free for all to use and not protected by intellectual property.
• Interoperable - Diverse systems should be able to work together (inter-operate)
• Autonomous - Services have control over the logic they encapsulate.
• Reusable - Logic is divided into services with the intention of promoting reuse.
• Reliable - It should not have many flaws
• Discoverable - Services are designed to be outwardly descriptive so that they can be found and assessed via available discovery mechanisms
• Loosely-Coupled - Loose coupling occurs when the dependent class contains a pointer only to an interface, which can then be implemented by one or many concrete classes.
• Stateless - Should exhibit the same behaviour and yield the same result whether called once, or 100 times
• Composable - Collections of services can be coordinated and assembled to form composite services.
• Manageable - It should be easy to maintain it
• Secure - It should not be easily hackable

Core Components of SOA

• SOAP: Simple Object Access Protocol - As a layman's example of how SOAP procedures can be used, a SOAP message could be sent to a web service enabled web site (for example, a house price database) with the parameters needed for a search. The site would then return an XML-formatted document with the resulting data (prices, location, features, etc). Because the data is returned in a standardized machine-parseable format, it could then be integrated directly into a third-party site.
• WSDL: Web Services Description Language - Its an XML-based language that provides a model for describing Web Services.
• UDDI: Universal Discovery, Definition and Integration - Its an XML-based database for companies world-wide to list themselves on the internet
• BPEL: Business Process Execution Language - Its a language for specifying interaction with web services.
• ESB: Enterprise Service Bus
• WS-*: Web Services Standards - a collection of protocols and standards used for exchanging data between applications

Benefits of SOA

• Improve long-term value of software assets
• Improve quality through modularity and testability
• Reduce development time with composition and reusability
• Leverage heterogeneous development environments
• Avoid vendor and platform lock-in
• Integrate with ERPs and Enterprise infrastructure software

Use cases for SOA with Ruby

Ruby can be a productive way to:

• Build web applications over web services
• Write web services tests with minimal code
• Write custom web services monitoring and management
• Integrate ERPs, COTS and custom applications
• Write SOA glue-code, e.g. custom transformation
• Perform programmatic web services orchestration
• Develop basic web services

Reflection in Ruby

One of the many advantages of dynamic languages such as Ruby is the ability to introspect—to examine aspects of the program from within the program itself. This is called reflection. At runtime, we can discover the following things about our ruby program -

• what objects it contains,
• the class hierarchy,
• the attributes and methods of objects, and
• information on methods.

Ruby provide a module called "ObjectSpace" that lets you to use reflection and see all the above mentioned information. So if you say,

ObjectSpace.each_object { |x| puts x }

will print all living, nonimmediate objects in Ruby process.

ObjectSpace.each_object(Class) { |x| puts x}

will print all classes in Ruby process.

The following code iterates over all the classes, compares their name. If name matches then create object and execute whichever function you like.

    class ClassFromString
    @@counter = 0
    def initialize
    @@counter += 1
    end
    def getCounterValue
    puts @@counter
    end
    end


    def createClassFromString(classname)
    ObjectSpace.each_object(Class) do |x|
    if x.name == classname
    object = x.new
    object.getCounterValue
    object = x.new
    object.getCounterValue
    end
    end
    end
    createClassFromString("ClassFromString")

Once you get the object you can use any method of that object. For e.g. you can use superclass method to get the name of the parent class and so on and can build complete hierarchy dynamically. You can get the information about methods of a given class using methods like private_methods(), protected_methods() which are defined in Object class which is base class for each object.

Distributed Ruby and Marshalling are two reflection-based technologies that let us send objects around the world and through time, which enables use of Service Oriented Architectures.

Marshalling

Java features the ability to serialize objects, letting you store them somewhere and reconstitute them when needed. To "serialize" an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object. You can use this facility, for instance, to save a tree of objects that represent some portion of application state—a document, a CAD drawing, a piece of music, and so on. Ruby calls this kind of serialization marshaling (think of railroad marshaling yards where individual cars are assembled in sequence into a complete train, which is then dispatched somewhere). Saving an object and some or all of its components is done using the method Marshal.dump. Typically, you will dump an entire object tree starting with some given object. Later, you can reconstitute the object using Marshal.load.

Example -

We have a class Chord that holds a collection of musical notes. We’d like to save away a particularly wonderful chord so we can e-mail it to friends. They can then load it into their copy of Ruby and savor it too. Let’s start with the classes for Note and Chord.

Note = Struct.new(:value)
class Note
def to_s
value.to_s
end
end

class Chord
def initialize(arr)
@arr = arr
end
def play
@arr.join('')
end
end

Now we’ll create our masterpiece and use Marshal.dump to save a serialized version of it to disk.

c = Chord.new( [ Note.new("G"),
Note.new("Bb"),
Note.new("Db"),
Note.new("E") ] )
File.open("posterity", "w+") do |f|
Marshal.dump(c, f)
end

Finally, it can be read by our friends.

File.open("posterity") do |f|
chord = Marshal.load(f)
end
chord.play ! "GBbDbE"

Distributed Ruby

Distributed Ruby or DRb allows Ruby programs to communicate with each other on the same machine or over a network. DRb uses remote method invocation (RMI) to pass commands and data between processes. Since we can serialize an object or a set of objects into a form suitable for out-ofprocess storage, we can use this capability for the transmission of objects from one process to another. Using drb, a Ruby process may act as a server, as a client, or as both. A drb server acts as a source of objects, while a client is a user of those objects. To the client, it appears that the objects are local, but in reality the code is still being executed remotely. This can be found in the SOAP implementation of RUBY libraries.