CSC/ECE 517 Fall 2009/wiki2 17 va: Difference between revisions
Line 77: | Line 77: | ||
Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible. | Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible. | ||
The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' | The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine was is available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times. | ||
The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages. | |||
A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message. | A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message. |
Revision as of 01:12, 10 October 2009
Service Oriented Architecture 3 (or SOA) describes how to design a software system and connect the separate components using services. Reflection and metaprogramming are two powerful concepts that directly support the principles of SOA. This article covers the following three goals:
- Provides a simple understanding of reflection, metaprogramming, and SOA's.
- Explains how these concepts are interrelated.
- Examines how reflection and metaprogramming supports SOA's.
Service Oriented Architecture (SOA), Reflection, and Metaprogramming
An overview of the concepts
Service Oriented Architecture
Service Oriented Architecture (or SOA) is a concept in computing that defines the interaction of different software in terms of protocols and functionality. A SOA can be viewed as containing multiple services which may be linked as desired by protocols. SOA is designed so that each functional unit of software in a system is isolated from each other and provides a service without directly making subroutine calls to each other. This is generally accomplished by passing messages 3
SOA offers the following technical advantages:
- Offers services across platforms
- Allows services to be split across systems and networks
- Allows services to be location independent and close to their business units
- Provides a bridge between incompatible technologies
- Leverages existing technologies
- Reduces dependency on custom systems
The information being used to communicate between services must contain sufficient detail about the characteristic of the data and the data itself and must remain independent of the underlying platform and programming language. Although SOA does not specify the format to transfer data, programmers have generally used XML for this purpose. However, Metadata (data that describes the actual data) 6 in the SOA must: 3
- Be easy to configure
- Provide an easy way to discover services
- Provide an easy way to incorporate services
- Remain coherent
- Preserve data integrity
- Be easy to manage
A simple example of metadata is a README file that specifies the inputs and outputs to a program. The inputs and outputs of the program would be the data, and the README file is metadata that describes this data.
SOA also does not limit the protocol used to transfer the data and a wide variety of technologies can be used including SOAP, REST and RPC. This is generally left for the programmer of the system.
We created this simplified image to illustrate the basic principles of service oriented architectures.
- Services may be used by multiple applications.
- Services do not call on each other.
- Services communicate via protocols.
- An example protocol is provided, in which the application passes x to the Sin function, and Sin(x) is returned.
- Because of the protocol link, services may be written in different programming languages, or even be hosted on different computers with different operating systems, which allows for great flexibility.
Metaprogramming
Metaprogramming is the writing of computer programs that write other computer programs. This allows the programmer to complete tasks faster than if (s)he had to code everything manually. A compiler is an excellent example of a metaprogram. It allows the programmer to code in a higher level language and then the compiler will convert that program into machine language. 7
- Example: Metaprogramming in Ruby [2]
class Person attr_accessor :name end
In the example above, attr_accessor is used to create 'setters' and 'getters' for the name attribute via metaprogramming. From this statement, code is automatically generated that provides a function to write the name (setter) and a function to read the name (getter).
Reflection
Reflection is a specific type of meta-programming and emphasizes on dynamic program modification. It is the ability of a programming language to inspect its own code and can therefore be used to extend the language beyond its usual capabilities. For example, it is possible to use reflection to inspect an object for a desired function and execute it dynamically.
- Example: Reflection in Perl 5
# without reflection my $foo = Foo->new(); $foo->hello(); # with reflection my $class = "Foo"; my $method = "hello"; my $object = $class->new(); $object->$method();
In the example with reflection, $object and $method can be determined and even changed at run time. This allows the program to change its own behavior.
Service-oriented Architecture is enhanced when the underlying programs are able to dynamically adapt to the data received. Metaprogramming and Reflection make this possible.
The services in a Service-oriented Architecture make use of the data passed around between them. When the data passed around represents code, for example 'print "Hello World"' in a language independent way, the receiving service would use metaprogramming to write code to just that. The service would then use reflection to determine was is available, in our case 'print', and would perform that task. If the service logic was to "repeat 3 times", then the code would ultimately print "Hello World" that number of times.
The application would pass the line saying to print "Hello World" to the service, would then print Hello World three times. Another more practical example would be a service that examines the code passed to it for security holes. These examples both make use of metaprogramming and reflection. One limitation to this concept, however, is that it would limit the code to a specific language. For example, if a Ruby line: puts "Hello World" is passed into a service written to accept Java code, it will not work properly. Services and applications would need to talk in the same language in this case, which would, for these applications, take away the benefit that services may be written in different languages.
A second thought we came up with is to send data that reperesents code. For example, we could pass a message that says print Hello World, and then the service would do that in whatever language it is written in. The first word could be read, and then the service could call the proper code within itself to meet that request. This could be accomplished with metaprogramming and reflection. The message could be analyzed and the method called could be changed based on what function is requested in the message.
The concept of reflection and metaprogramming can be used to extend the services and dynamically modify their behavior.
Example: An XML metadata schema is extended to include a new tag/value. This data is now passed around between services, and each service can be extended dynamically to use it.
References
1. http://www.service-architecture.com/web-services/articles/service-oriented_architecture_soa_definition.html - Brief explanation of SOA
2. Thomas, Dave (2006). Programming Ruby, The Pragmatic Programmers' Guide.
3. http://en.wikipedia.org/wiki/Service_oriented_architecture - A very detailed explanation of SOA
4. http://www.javaworld.com/javaworld/jw-06-2005/jw-0613-soa.html - A more easy to understand explanation of SOA
5. http://en.wikipedia.org/wiki/Reflection_(computer_science) - Explanation of reflection
6. http://en.wikipedia.org/wiki/Metadata - Explanation of metadata
7. http://en.wikipedia.org/wiki/Metaprogramming - Explanation of metaprogramming