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.