I tried to look up the www on how to load test our application across the technology stack we have: GWT - RPC - Services. Turned out not many tools - in the open source - that provide this functionality and JMeter lacks proper support for GWT RPC protocol.
A couple of options occured to me.
Option 1: Hack GWT generators
GWT is all opensource. And the problem is only with the client side of the RPC. All we need is the ClientSerializationStreamWriter to construct the RPCRequest and ClientSerializationStreamReader to handle service responses. Since GWT generates the client serializers via deferred binding at compile time, I started with the assumption that I could hack the GWT proxy generators to remove / stub out JSNI references from the generated service proxies and type Serializers and use these as part of my load test client. After a day of walking through the GWT implementation, I understood this was not a good idea. Though theoretically possible, the hack was not worth the couple of weeks of effort for multiple reasons.
And I decided to evaluate Option 2: Implement the client side of the RPC protocol and plug this into JMeter. This did not turn out to be as difficult as it seemed first up. Some help and atleast one instance of this attempt to start with. And within a week I have a primitive POC version of GWT RPC plugged into JMeter. I am in the process of implementing a proper GWTRPC Sampler for JMeter. Details I will publish as soon as I am done.
Friday, December 9, 2011
Raising the level of abstraction for Rich UI development
At Planetsoft we have been trying to build a framework that greatly simplifies enterprise product development. For the last couple of years my work has been mostly concerned with User Interface part of the framework we call PICF.
We perceive the world as an abstraction of reality. Abstraction is the mind's way of managing complexity and the key to software computing.
The key to simplifying application development and improving productivity is by raising the level of abstraction to the level at which we think and design. That is what we attempted to do to Rich UI development. Traditionally there have been a number of frameworks and tools that simplify UI development by providing WYSIWIG editors. XForms is an example of an attempt to capture UI spec in a platform independent fashion.
In the process, we evolved and XML based DSL, that we call View Metadata, for capturing UI behavior along with the visual elements and their layout. In addition, the framework provides a set of business use case oriented user interface patterns out of the box. The idea of coarse grained UI patterns encapsulates the complexity of Rich UIs and also provides a consistent user experience across a suite of products.
We perceive the world as an abstraction of reality. Abstraction is the mind's way of managing complexity and the key to software computing.
The key to simplifying application development and improving productivity is by raising the level of abstraction to the level at which we think and design. That is what we attempted to do to Rich UI development. Traditionally there have been a number of frameworks and tools that simplify UI development by providing WYSIWIG editors. XForms is an example of an attempt to capture UI spec in a platform independent fashion.
In the process, we evolved and XML based DSL, that we call View Metadata, for capturing UI behavior along with the visual elements and their layout. In addition, the framework provides a set of business use case oriented user interface patterns out of the box. The idea of coarse grained UI patterns encapsulates the complexity of Rich UIs and also provides a consistent user experience across a suite of products.
Wednesday, September 14, 2011
Service Orientation: What it means to me
SOA this, SOA that. Some SOA fun!
To me, service orientation is all about identifying the right abstraction and achieving the right kind of system decomposition.
A bit of history. Object Orientation was the silver bullet to overcome the software crisis. The objective of this methodology was to hide complexity and promote reuse - creating the software industry.
In the object oriented world there are objects. Objects that possess an Id, encapsulate data and provide some behavior. The system is decomposed into a set of objects. OO enables the software industry overcoming the limitation of procedural programming. The concept of object being an abstraction of a real world entity allows managing complexity. Along with that, inheritance and polymorphism enable reuse ultimately enabling apps to grow large.
But still system boundaries are more or less defined by the host process. Inter Process Communication helps move the boundaries to include multiple processes or threads but has its own limitations and complexities for the developer. It is the object oriented RPC that is the primary enabler of distributed systems. CORBA is the industrial standard in heterogeneous OO RPC. Given the wide spread acceptance, there are lots of great distributed systems built using it. Still, CORBA is not for the weak-hearted and invariably results in tight coupling and inflexible systems.
A couple of points with wrong projections of oo.
First: Consider the case of a homogeneous system that needs to scale; take the Java EE model. I see this as basically an object oriented architecture and its accompanying fine grained interaction between objects. A location transparency model that really leaks. This in fact results in more complexity, more interfaces and more glue layers like the session facade, Business delegate etc. All these layers are bound by object oriented contracts with the resultant tight coupling and inflexibility. Coming to EJB, though greatly simplified from the first version but still complicated, tried to address horizontal scaling for transactional systems and intends to provide transparent persistence, transactions and security with object orientation. The EJB component model directly follows design patterns from the CORBA world and its resultant accidental complexity. None of the intended transparency models really hide complexity. Real world applications have other NFR concerns that the application containers try to address. That's an additional black box. Add to this, the need to manage and replicate state on the server cluster. Achieving a cluster configuration to scale specific desired functionality can be quite tricky. But can be solved by a combination of hardware and software. The real difficulty is in evolving the system. Any change requires a wave of refactoring across the layers. The number of layers, tight coupling, complex fine grained interactions and ineffective separation of concerns from a functional abstraction point make the system less agile from a business stand point.
Second: Heterogeneity and diversity needs to be addressed within and out of the enterprise for business agility. When it comes to integrating the enterprise within and out, object oriented RPC is too tightly coupled and too complicated and a real misfit.
What is a Service?
A service is a relatively coarse grained abstraction and exposes a well defined behavior, backed by an OO implementation. And unlike an object, does not hold state. Services are essentially stateless and loosely coupled and does not depend on the context of other services (and a lot more). In the service oriented world there are services: just behavior on request. A system composed of service abstractions addresses the technical and functional separation of concerns well. Service orientation is the way to address the above OO rooted shortcomings.
A very useful article on service orientation by a distributed computing specialist, Steve Vinoski.
Inversion of control, dependency injection, Aspect oriented programming and the service abstraction enable building a Service Oriented system. A good introduction on these by Rod Johnson. The first one I looked at was the jboss server implementation. These principles enable loose coupling. Services are broadly classified as technical and business services. These re-purposed abstractions and with the above mentioned SOA enablers make building flexible systems possible. Functionalities are achieved by composing loosely coupled services and individual services can be scaled separately. With a flexible system that is easier to evolve and extend helps achieve business goals.
To me, service orientation is all about identifying the right abstraction and achieving the right kind of system decomposition.
A bit of history. Object Orientation was the silver bullet to overcome the software crisis. The objective of this methodology was to hide complexity and promote reuse - creating the software industry.
In the object oriented world there are objects. Objects that possess an Id, encapsulate data and provide some behavior. The system is decomposed into a set of objects. OO enables the software industry overcoming the limitation of procedural programming. The concept of object being an abstraction of a real world entity allows managing complexity. Along with that, inheritance and polymorphism enable reuse ultimately enabling apps to grow large.
But still system boundaries are more or less defined by the host process. Inter Process Communication helps move the boundaries to include multiple processes or threads but has its own limitations and complexities for the developer. It is the object oriented RPC that is the primary enabler of distributed systems. CORBA is the industrial standard in heterogeneous OO RPC. Given the wide spread acceptance, there are lots of great distributed systems built using it. Still, CORBA is not for the weak-hearted and invariably results in tight coupling and inflexible systems.
A couple of points with wrong projections of oo.
First: Consider the case of a homogeneous system that needs to scale; take the Java EE model. I see this as basically an object oriented architecture and its accompanying fine grained interaction between objects. A location transparency model that really leaks. This in fact results in more complexity, more interfaces and more glue layers like the session facade, Business delegate etc. All these layers are bound by object oriented contracts with the resultant tight coupling and inflexibility. Coming to EJB, though greatly simplified from the first version but still complicated, tried to address horizontal scaling for transactional systems and intends to provide transparent persistence, transactions and security with object orientation. The EJB component model directly follows design patterns from the CORBA world and its resultant accidental complexity. None of the intended transparency models really hide complexity. Real world applications have other NFR concerns that the application containers try to address. That's an additional black box. Add to this, the need to manage and replicate state on the server cluster. Achieving a cluster configuration to scale specific desired functionality can be quite tricky. But can be solved by a combination of hardware and software. The real difficulty is in evolving the system. Any change requires a wave of refactoring across the layers. The number of layers, tight coupling, complex fine grained interactions and ineffective separation of concerns from a functional abstraction point make the system less agile from a business stand point.
Second: Heterogeneity and diversity needs to be addressed within and out of the enterprise for business agility. When it comes to integrating the enterprise within and out, object oriented RPC is too tightly coupled and too complicated and a real misfit.
What is a Service?
A service is a relatively coarse grained abstraction and exposes a well defined behavior, backed by an OO implementation. And unlike an object, does not hold state. Services are essentially stateless and loosely coupled and does not depend on the context of other services (and a lot more). In the service oriented world there are services: just behavior on request. A system composed of service abstractions addresses the technical and functional separation of concerns well. Service orientation is the way to address the above OO rooted shortcomings.
A very useful article on service orientation by a distributed computing specialist, Steve Vinoski.
Inversion of control, dependency injection, Aspect oriented programming and the service abstraction enable building a Service Oriented system. A good introduction on these by Rod Johnson. The first one I looked at was the jboss server implementation. These principles enable loose coupling. Services are broadly classified as technical and business services. These re-purposed abstractions and with the above mentioned SOA enablers make building flexible systems possible. Functionalities are achieved by composing loosely coupled services and individual services can be scaled separately. With a flexible system that is easier to evolve and extend helps achieve business goals.
Subscribe to:
Posts (Atom)