|
|
aCube è una metodologia utilizzata da mondora, è applicabile a qualsiasi prodotto software e permette di adattare un’applicazione già esistente, oppure una nuova applicazione, a nuove tecnologie.
aCube è disponibile per l’ambiente Java e per tutte le sue derivazioni, includendo J2EE e CORBA ed è applicabile in tutti i tier delle applicazioni distribuite.
Acube significa:
- Aspetti
Per la definizione di aspetti, caratteristiche applicative trasversali, per ottimizzazioni e migliorie.
- Adattabile
Può adattarsi a ogni sistema e tecnologia. L’adattamento si ottiene abilitando o disabilitando alcuni aspetti.
- Architettura
Gli aspetti e l’adattamento sono applicati a livello architetturale, attraverso una metodologia e un processo.
Ogni aspetto Acube che viene applicato integra le proprie funzionalità, migliorando le performance e modificando il codice in fase di deploy.
I test assicurano che ogni rilascio venga effettuato con un sistema stabile e che i risultati previsti siano rispettati. Acube è quindi anche uno strumento per migliorare la stabilità e le performance del sistema.
I professionisti di mondora sono in grado di continuare lo sviluppo tradizionale delle nuove funzionalità dell’applicazione e nel contempo sviluppare l’infrastruttura per garantire performance elevate.
 Design has become popular in several context, and it is applied in applied arts, engineering, architecture, and other creative endeavors. Design is something cross to all the things around, and a good design is simply perceived without too much understanding going straight through the final objective.
Last years I did lot of things spacing from developing, architect, designing software to put customer ideas to market and I’ve learned lot of things about each activity I performed: for an excellent result every activity should have a good style and a good design. But, what a good style and a good result? To fast figure it out, if we think a picture of a car from a kid and from a designer like Giugiaro, they’re, both, drawing a car with four wheels, and engine, some seats etc., but the main difference is that Giugiaro’s car will seem more accurate and beautiful that the kid one. That’s only because Giugiaro is a professional designer and the kid is just playing with a pencil and a sheet. Now, switching the metaphor back to everything we delivered in the past we can focus on the result and on the next improvement in term of style. Here is a list of key point when I’m doing things trying to figure out “a style”:
- Build only what is absolutely necessary
There is lot to do and if we do more than our potential, maybe we’ll reach the goals, but lacking on style and quality. So, one of the first statement, when I approach something is to find out what cannot be done to stay focused on small portion and put all the energies there. This trend is notable in 2.0 where services focuses only on small things giving an idea of lightness and the refinement process improves iteration over iteration.
- Quickly turn beginning users into intermediate
Think about a sexy girl! She creates interest without telling things; the viewer is not reading papers, documentation or watching podcast to be attracted by the girl. She is turning a beginner user to an intermediate fast creating the correct interest in doing things and maintaining the learning curve small. This is what in Agile Development, we call self documenting software: if it is sexy and appealing for developers can be learned fast without too much archetypes around: like a sexy girl.
- Prevent errors whenever possible and handle the errors we cannot prevent gracefully
Good style is something appreciable outside the designer and style should be perceived rapidly. You can get wrong while designing, this is why on every small increment the heart of design should pulse to his target to check if it is good for it or not. It is not a way to pre-sell, it’s a way to anticipate problems gracefully. Shouting every small iteration makes a good style growing.
- Reduce and refine interactions and task flows until even the most complicated applications are clear and understandable
Refinement focuses on making things implicitly clear, in the way just watching them for few times, they’re understandable. This is what I do, when I seek what cannot be done. This is not a technique to postpone work; it is a method to check if something is still available and need to emerge from the already available resources. Good style is made of few things because the huge variety of things is gone implicitly inside the design itself and is easily discoverable and understandable.
- Adopt metaphors, better visual metaphors to explain the complexity and bring it to a human comprehensible level
Metaphors are the key to find out what is implicit in a context, and only with metaphors you can focus on what is really not clear. When thinking an archetypes a metaphor is a good statement to better understands, picture or diagram the archetype itself.
- Ignore the demand of users and stick to a vision
Improvements are done through brainstorming and brainstorming should be stick to a vision, a common vision. It’s important to stay focused on the purpose, and not to switch over ideas every user express.
These are only a bunch of rules; I’m learning from my experience. Surely some new rule can come in the next future.
Having a website today is producing some value and not having it, is creating lot of penalties. Traditional enterprise web modeling has lost the concept of static websites for a more dynamic approach where the life of the company is perceived through the web too. Different navigation from the old fashioned menus is needed, user should move on the web site and interact with the website directly by categorizing and commenting all the contents on the website. Blogs are a good way to implement all those functionality in a modern way. Visitors should be able to browse content thought their interests and not through what company want to tell. That’s why content’s tagging is more important than categories and menu.
A blog entry can be seen as a content, with several information linked; hyperlinks are a good example on the power of linking things and menus are good samples on how contents can be organized.
But, this in direction and through the monopoly of the corporate. Thinking 2.0, contents are coming out from who work and even better can come out from the visitors too. External services like delicious or technoraty enable people to link pages and shares them across the net by tagging them. Thinking of contents as blog entries from the editor community, and tagging as an empirical way of organizing content lets a 2.0 start up company to find what is really important and how visitor are identifying it through the tagsonomy related. A user can browse the site, thought as a set of entries, in different ways starting from the old one through category moving to an editor tag browsing and facing it at the end to the visitor’s tag apposed.
This is only because web site’s fragments can be referenced with some tag. This can glues either an old fashioned web page, and a dynamic new page where fragment are linked by tags more significantly for the current visitor.
Blog engines like wordpress are fully customizable and have dozen of plugin to interact with entries, tags and outside services like delicious or technoraty.
The next move on the corporate website’s chessboard will be to migrate the standard website to a custom blog having some of the blogging featured customized and having the community to work on it editing and tagging content’s fragments.
There’s lot of misunderstanding between Components and Services: components are something that aggregates a product for a business behavior while Service is what is doing real business and it’s remotely usable from who is really interested in the value added the service is producing.
Nowadays the term service is in every modern acronym (SOA, SAAS, SLA, etc.), and there is non clarification on what is a service and how it differentiate from old fashioned terms like Components.
The term Components come from the manufacture’s industry where all those modules are used to build things. It doesn’t matter if a car engine is manufactured by Ford or by Subaru, it is produced reusing some of the same components and it is not implemented from the scratch.
During the last years, the Information Technology approach has been to watch other industries and to try to implement all that has succeeded into software. Like in the manufacture, software components are a unit of software that provides business or technical functionality.
Typically they’re self-contained and independently deployable. Thinking about a software component we’re used to think to:
- a specification (analysis and design) that defines the scope of the component;
- an implementation with any invokable interfaces;
- a module to be deployed (an EJB, a WAR, an EAR, a DLL, etc.).
A component offers its implementation through an interface, that’s the unique way a component should be used.
Differently services are focused on satisfying business needs, on a consumer/producer paradigm where the service is producing something valuable for the business. A service can be thought as a set of components and differently from components. A service can be something else than a component. Instead of having an interface service allow the concept of API on different protocol and they can act synchronously or as event’s agents.
Another big difference between Services and Components is the way they’re reused. Going back to manufacture Components is stored on the shelf and is taken and deployed when necessarily.
Service, in an opposite direction, lives somewhere and is addressed to be used.
It’s like going to the post office to send something instead of creating a post office in house.
An approach with components requires a new deployment, new hardware dimensioning and integration while a service approach is only focusing on integration.
What is making the difference?
The way the architectures are thought is making the difference, thinking SOA is benefiting the reuse of value added services and is accelerating the way software is implemented. Every architect is implementing a system, should think a way to make the application addressable and callable by other Service around the network promoting Service Reusability. In terms of business, Service reusability creates a new approach of doing business where specialized companies are providing something that produces real value as a service and is offering a large scale the service at a low price. Google, or salesforce.com or Amazon is again an example of the power of thinking SOA.
 Architectures are following the way to be extensible, flexible, and easy to be maintained. A 2.0 scenario makes things growing on demand, starting with a small set of features and growing to a huge application with lots of other integrated application (mashup) and complex business logic. Everything shall evolve and redesigned time over time, feature over feature.
The best approach in delivering a modern application is to consider the application itself as a big mashup of the application. This implies, again, a multi-tier approach where there is something in the middle tier that executes something valuable and there’s something in the presentation tier that orchestrates business behavior.
Thinking in the way we thought with Enterprise architecture based on EJB and other complex solution, the separation was into the presentation tier, the business tier, and the integration tier.
All the components should be divided into one of the above tears, depending on their roles, and responsibility inside the architecture. Why the separation of roles? Separation of roles can tune the architecture in several point with lots of combination. By implementing modern architecture on social communities, I’ve found important in differentiating the business tier from the presentation tier: as I do in enterprise architecture with high available technologies. Things and names changes, but the result from the architecture should be the same: having and extendable and flexible system.
 The key concept in modern thinking is to separate services their API from their “social interaction” promoting a Widget as a visual coordinator of something is happening backward.
This brings out a reusable API, a first use of the API that is the Social Application and the versatility of the architecture. Having modern API exposed in several formats including JSON restful services, this enabled the idea on having the integration tier as the “presentation tier” or on the old fashioned presentation tier. The modern presentation tier is called Mash up and is really adaptable depending on the needs. If it is required that a machine should do something on the integrated platform (viz. flickr), it can be done at server-side as a restful service. If it is required to operate with some integrated platform visually, it can be called directly from the presentation tier. Yes, this is the first example of how flexible can be an architecture: I can choose to do integration on throttling on the service platform or to choose to go strike through the integrated platform directly from the client interface. This is gained only because, the integrated platform has been tough having the concept of API and that the Social Application is itself a big mash up of those interfaces. Making an API public or private is a tremendous business decision, and should be accurately agreed after heavy consideration. Having a public API makes other the reuse idea instead of the feature copy idea; this requires the company, should also have a clear policy on how integrators can use its API for their mash up. This will be a next big opportunity that 2.0 will create. Stay tuned.
 Usability has evolved in practices like interaction design, social design an others. An architecture should evolve with the system letting mash up to be easily created, managed and removed. This is a way when thinking architecture an architect should take care that one principle of the architecture should be hackable. By hackable I mean do things in a “informal” way, where mash up or enterprise’s mash up are activating architecture blocks.
Internet has become a great place where people exchange data and interact to evolving work in an efficient way. Interaction design, usability, and other disciplines are discovering a pattern to make applications people centered. This kind of approach is even more driving software conception having people in mind instead of technology and technology is the facilitator tool to address this kind of approach.
Software architecture and Interaction design fits together and melt as needs. Re-usability is required not only thinking on architectures even thinking on people that are using the system too.
Architecture and component interaction is typically forced by Use Cases and is not so flexible to adapt different evolving usages of the system. Architectures should be hackable to adapt user needs.
Hackability of a components includes several point of view:
- business view: what business feature can be reused by a component;
- calling view: which protocol is exposed by this component, and how can be called by mash up
- context living: how do a component fits in a context while collaborating and in other context when reused, who declares it and how?
Sense is promoting the concept that a Service is everything inside a physical and logical architecture: components, frameworks, machines, application server etc. are services.
Sense’s services can be exposed over several protocols including http (xml-rpc), http (json), iiop, jms. From the protocol point of view, Sense lets services to be in some mash up; it doesn’t matter whether the mash up is at client side or server side. Service’s context before and after invocation is updated in Sense by the application of crosscutting concern that is intercepting a call to a service in a particular context and are enriching the incoming and out coming call with context specific information. This is gotten through the definition and the application of Emotions that are though as aspect that crosscut in an architecture.
 I’m just back from Almens (Swiss) after a day of talking about stuff on several things in mine interests with a good friend Tim Mackinnon. After some talks that gave me a better understanding on how architecture are changing, they’re ready to be dumped on a blog entry.
Before start describing the 2.0 I need to go more in depth about the evolution of an Architect form 1.0 to 2.0
In 1.0 he is responsible for:
- the architecture of the system including component reuse (logical and physical reuse),
- finding patterns for problem solution, - driving the philosophy in separating concerns between core component.
Meanwhile, Developer 1.0 requires analysis and designs before writing a line of code, the 2.0 approach is starting from a business feature and instantly writing it. A 2.0 architecture emerges as the code’s soul, like when a voice comes from the soul of kid. The soul must be educated, and the role of the architect should be as educator to an architectural approach by iterating over all the development content and all the developers while they’re under pressure in releasing line of code. In this way, architects facilitate the emerge of an architecture thought as the Software Personality. With their new approach in linking developer 2.0 contents (code, documentation, feature, etc.) they’re are creating those links that enforce the soul of software. Personality increases day by day, line by line, and architecture emerges with it and consolidates with it. Modern architects linking code snippets with tags of a specific context (architecture for example) are implicitly educating code with a personality. Code behavior is the feature implemented, and the old fashioned architecture diagram is an outcome of what is implicitly related inside the code by architects; both the logical and physical statement. The analysis of those links between things produces different graph of related things, and those graphs can be drilled down by following all the tags.
 – architecture cloud -
The above diagram can be derived by analyzing tags and relationship between tags: architecture is a derivation by the tag graph inside the system. By having it expressed as a graph from the analysis of the system, it can be thought as an architecture cloud, where the most important component is bigger than the others and when dependencies between component are inherited from tagging. An architect 2.0 is responsible for creating the culture of tagging components to create the 1.0 hidden relationship between logical and physical components. This constitutes the soul of the application that must grow with the system day by day in a pragmatic way by adopting feature to code (as the voice) to the soul. I would like to go more in dept in a future post about the tool. An architect 2.0 should use for maintain upstanding a soul of a system.
I’m just back after a weekend on the snow, and I’m happy to know that Oblique Scaling is producing the correct result in mondora.com. Mondora’s engineers thought Hardware could be thought as Software, like Virtualization does. Having Sense as a common infrastructure, they’ve just released a component called Scent that meets Hardware availability and Software suffering. During last past 2 weeks they stressed the Sense Workshop on a 4 core HP starting with 1 core switched on and the rest switched off. An endurance test of 12 hours has been run, to check how Sense self regulate having Hardware considered as an High Available Service with an identified Service Level Agreement.
When system increased in suffering by switching from good Service status to worst, Sense has anticipated lack of performance by working with the Hardware Virtualization Platform and asking to Scale Up.
In terms of Business, benefits gained are:
- This approach that Predict system performances and do some actions to make the system surviving.
- This approach let to Scale when unpredictable things occurs. This is the case of a Campaign that is producing more than the expectation and if the system is not adaptive, Campaign is loosing all the Customer, both the predicted and the unpredicted.
In terms of Manageability, benefits gained are:
- Vertical Scaling is predicted by Application Constraints and matched with Hardware Service Status
- Policy can be configured (ex. switch a CPU after a 15 minutes of suffering)
- Scaling policies are described as Algorithms and implements different strategy. This let to configure a strategy where network latency is compared with Service metrics. By comparing Sense can avoid Horizontal Scaling versus Vertical Scaling
In terms of Development, Hardware is saw as a Service itself and can be allocated runtime when business constraints need it, like another Service on the Net.
By having this building block certified, Sense is becoming a real implementation of a Future SOA where Services:
- are available over the network in a cluster environment
- are self federating
- are balancing on SLA policies
- are balancing on Business Constraints by flocking
- can balance on most productive in terms of ROI
- are multi protocol invokable
- can be perceived from the outside environment as inside components
- are physical resources
This is a really implementation of what SOA can be.
|
|
|
