Write your app, not billing code: collect and share Experiences!

Nowadays, development is done following a bottom-up direction where development focuses on writing, or better rewriting sub-systems and even more systems without leveraging experiences.

An experience is a practical contact with and observation of fact or events. The culture of thinking in the direction of Software As A Service, let development to be - ideally - committed and packaged in an Experience where all the behaviors of the implemented scenario are collected, stored and executed.

Experience is a sense's feature that relies on the SOA paradigm and collects in a single point all the information about what a system or a sub-system does.
Relying on the SOA paradigm this, in a sense scenario, means:

• they are thought as a Service;
• they declare a Service Level Agreement contract;
• they declare what to do when there's no capacity to perform more requests
• they are manageable through customizable web 2.0 console in terms of operational management and business management

Experiences let developers to focus on what primarily an application is doing: revenues. An experience must be described by a SLA contract that declares the different suffering algorithms of the experience and the logic on balancing on different experiences instance of the same experience family.

Suppose a company would like to sell goods on a target customer. They would like to try several different campaigns on the target proposition without loosing to much money.

Loosing money is for the Experience a SLA status and reflect a good wellness status of Gaining Money. The experience packages itself all the service, components and objects needed to provide the service. It declares the SLA status and some hooks that collect all the KPI (Key Performance Indicator) of the application that is evaluated by a business algorithm.
The business algorithm correlates of all the KPIs and instructs the platform the experience status.

Once installed and assimilated the experience starts pooled as an instance of the same family, and starts working having its status associated. When sense allocates it by thinking it is a valid experience for the current session calls, the Experience starts to collect KPIs associated to it and correlates them by pulsing the result in the Experience status grid.

KPI are real time propagated to console too.

Endnotes

What is inside an Experience is almost all, can be a Service or an external application that turns in a business service level agreement scenario. Experiences are portions of knowledge that satisfies a custom business behavior in a SOA oriented fashion.
Experiences can be identified like ACID portions of knowledge. They are Atomics, Consistent, Isolated, and the providing business is Durable.

Sense Virtual Appliance on Amazon EC2

Sense is a platform that can deploy Software having the Service Level Agreement between object calls. It doesn't matter if objects are locally, distributed on a grid or are outside the system. Sense implements the pure concept of SaaS (Software As A Service). We moved straightforward, and we have demonstrated that Hardware should be considered as Software. We've created a Scent that attaches Virtual Hardware on a Sense Federation and use Hardware as a Service by letting the system scaling on hardware if hardware is more available under a certain business constraint.

Now mondora's engineers have a new concept in Sense Packaging; they're thinking to provide a package that is a ready for production Sense Instance or Federation deployable as a Virtual Appliance on Amazon EC2 Services.

The main feature of the Sense Virtual Appliance, over the already available feature in Sense, is the perception of the hosting platform (in the case EC2), and then the capability to scale on that platform when Business Service Level Agreement are violated. This let to spend money only when they need to be spent, and to configure each business policy for each application.

The feature will be released in the next month, and will be available as a Package Option of Sense.

Google Sense Toolkit: reliable client side application

The integration of Google Web Toolkit is done in sense by implementing a communication layer with JSON. This let that all the incoming request now can be response not only with XML-RPC, HTTP, Web Services, IIOP or JMS but can be done via JSON. This feature enables all the AJAX platform that would become reliable; both on the client having a client doing things asynchronous and having a high available Service infrastructure managed by sense. By implementing an offline technology such as Google Gears, lets to manage Service Level on network connection too, having an operational environment every time ready and when occasionally available (due to network instability) works with Server System such as the sense Infrastructure. Google Web Toolkit enable developers to write Client Application in Java and the to post compile them by producing Javascript. When developing with GWT, the mindset is similar to the AWT’s one; developers work only with java object and the Google post compiler generates the right code for browsers. sense is implementing the infrastructure to work with Google Web Toolkit and can generate a set of object representing the hosted Services to run at the client Side. A developer writes a Service, declares its SLA policy, and generates the corresponding code invokable in the GWT domain. sense GWT implementation bridge the communication gaps between sense and the corresponding objects on the client.


Standard Asynchronous Calls
Asynchronous Calls as AJAX identifies where the client is sending a request to sense and receive a response near-time. On the client side is easy to develop a system that uses generated sense’s stub services and use them, delegating to the system to make the call. This is normal, as GWT does; sense’s services are extended for being called from the front end and Google sense Toolkit extension provides the feature of Marshall and un-marshall calls between sense and the client. In sense each service, bizflow or Feeling has a small family of helper interfaces and classes. Some of these classes, such as the service proxy, are automatically generated behind the scenes and you generally will never realize they exist on the Client. Just bring their source while developing the client and start using it letting sense’s calls invisible. Differently than GWT requirements, sense not requires for each implementation a service implementation, just use the sense’s created service stub on the client and delegate it to the sense client library compiled as Javascript for in-browser elaboration.

Event Driven Calls
Comet like calls, where client subscribes for receiving a set of notification when available on the Server and sense notifies to the Client the proper data. Having a comet approach is easy to implements, for example, a dynamic graph that changes when something on the server changes. sense graph implementation is based on Chronoscope. The data is delivered by sense over a single, previously-opened connection. This approach reduces the latency for data delivery significantly. The architecture relies on a view of data which is event driven on both sides of the HTTP connection. It suites really well in SOA architecture where the only substantive change is that the endpoint is the browser. While Comet is similar to Ajax in that it’s asynchronous, applications that implement the Comet style can communicate the state changes with almost negligible latency. This makes it suitable for many types of monitoring and multi-user collaboration applications which would otherwise be difficult or impossible to handle in a browser without plug-ins. sense provides a Comet-ready module available to developers on the bleeding edge implementing all the best IO Patterns and Practice making Application HI Scalable. sense is making the event-driven future a present reality.

Endnotes
Adopting sense as High Performance Computing environment, let to be sure that everything on the server side is addressed and performance is realtime monitored. The marriage between sense and GWT and Google Gears alike technologies, shifts to another paradigm in software computing where network availability is considered as a possible system fault and managed.

BEYOND SOA IS SPOA

IT market in general - and software vendors in particular – have emphasized SOA paradigm (Service Oriented Architecture) being the silver bullet for actual and future software developments. Recent studies (e.g.: “SOA and BPM for Enterprise Applications: A Dose of Reality”, AMR Research Inc, May 2007), show how SOA is perceived/applied within enterprises, and what directions enterprises themselves should take in order to gain advantages from its adoption. Whether an enterprise is going to plan for SOA design or not, there are three major difficulties they have to deal with:

• Roles involved. Even when designing simple business services, many company roles are involved, therefore many skills play on the same ground using possibly different tools
• Implementation model. Being it either Waterfall, Synchronized or Single, a certain number of tools is required to support it. Even if marked with the same brand, platforms for implementing SOA are often a collection of different tools, sometimes not well integrated
• Organizational issues. They are much more complex than technical ones, and they often require a cultural change in order to be addressed

Sense software platform leverages on its SPOA (Single Point Of Accountability) key concept to go one step beyond SOA and address the above points. This paper illustrates how Sense implements SOA paradigm and how SPOA model offers a way to facilitate the cultural change needed to better exploit technology benefits.

A real-life scenario
The complexity underneath the development of a business service does not depend on the service itself. It depends rather on the complexity (organizational, cultural) of the company. Incredibly simple requests may require long time and a great amount of money to be accomplished.

Roles involved
Within a big company, many distinct roles have to participate to the entire process, from inception (business modelling) to the execution (operation). All roles belong to three major areas:

• Business. Basically the business owner and the business analyst refer to this area. They are responsible for high level description of business goals and for detailed description of business flow, data flow and user interaction
• Architecture. The technical architect translates business concepts into executable units with algorithms to be developed and/or systems to be used
• Operation. One or more professionals are required to develop, test and deploy the service designed by the architects. An additional role is required to monitor service execution and ensure its performances

From 3 to 7 (or even more) different roles are required to implement a business service. The number cannot be smaller and in a normal situation this results in delays, misunderstandings, different (sometimes incompatible) point of views. SPOA model (as described later) does not allow to decrease the number of roles, rather it offers an approach to service development that avoids most of the problems mentioned above.

Implementation model

There are three major models that companies use to control service lifecycle. Namely, they are the Waterfall Model, the Synchronized Model and the Single Model, as depicted in the picture below.

The Waterfall Model is a one way process (from business to operation) where every role uses its own tool/repository. The constructs of each phase are passed to the following one. Any change in any phase has to be manually managed.









In the Synchronized Model all roles belonging to Business and Architecture share a common part of the model, thus allowing a lot of information to be consistently maintained through the lifecycle. Actual benefits of this approach do depend on tool features.











The Single Model is the best one in terms of simplicity. One single model is shared among roles, and each one of them may use specialized tools, without affecting the model itself.





Organizational issues
The bigger the company, the bigger the number of roles/groups involved in the development lifecycle. It is not infrequent to bump into difficulties like misunderstandings and delays. In other words, different perspective or different processes that take part in the overall design may contrast one another.

BEYOND SOA IS SPOA!

The actual implementation of SOA within enterprises has to face the above problems, making it difficult to achieve the benefits of SOA. Sense – SENsitive Services Environment fully implements SOA and goes beyond it, with the concept of SPOA – Single Point Of Accountability.

The major concern of SOA is the architecture.
It has to deal with services in a technical perspective. Services, in IT world, are merely responses to invocations. No more than results of algorithms. Or, from a higher point of view, they are objects running on an underlying middleware. This has little to do with clients and customers, who think of services as real answers to real requests.

The major concern of SPOA is the business service. Whatever middleware is responsible for making objects running, in customer perspective the service is (for example) his/her balance displayed on his/her mobile phone, at any hour, with a good response time.
It is the business service (that is, the customer) to set the rules that will drive development, and those rules will live inside the service as long as it is running.

With Sense the service is a single point of accountability, from business design to operation execution. The more the design proceeds, the bigger the number of perspectives that converge on the service. Every perspective “added” on top of the service will result in a new Service Level Agreement (SLA) that represents and guarantees the goals of that particular perspective.

Sense implements the Single Model of development, letting every role involved in the entire process add its own information and set its own constraints. Even if a certain role uses its own tool (not integrated with the others), this will result in adding a SLA (Service Level Agreement) on the service, and that SLA will affect service execution over its life.

Sense and SPOA help companies solve their organizational issues. Software platforms, including Sense, will never be the answer to the organizational issues described, that mainly depend on the behaviour of individuals.

Nevertheless, Sense and its SPOA key concept bring a really new approach to development.
It focuses on cooperation: multiple roles converge on the same object, everyone of them being responsible (accountable) for its own perspective (SLA), while the object remains the same. It is a cultural change, that leads to improvement and higher awareness.

CONCLUSION

Looking at future plans for software developments, companies think of SOA as the paradigm to protect IT investments and exploit all the potential of information systems. When approaching SOA at enterprise level, three categories a problems arise: the number of roles involved, the development model and the organizational issues. All these seem to weaken SOA potential.

Sense - SENsitive Services Environment platform and its SPOA key concept, offer a way to build SOA applications and realize the promises of the paradigm. Instead of adding a new set of tools, SPOA redefines the concept of service, allowing it to escape from the cages of technical issues and go closer to who is the source of company profits, that is the customer. Once redefined, the business service collects perspectives over its design process, each one reflecting the point of view of the role that set it.

The task of redefining the service is both technical and cultural. In this way Sense introduces a different approach, that brings a decrease in development time, a more effective process and a better understanding of company goals. In Sense environment, it is called Enterprise Common Sense.