InfoQ has gathered a virtual panel of Enterprise Architects who have lived and implemented SOA for most of this decade to better understand what SOA means to IT in 2009.
The Open Group's SOA Source Book is a collection of source material for use by enterprise architects working with Service-Oriented Architecture.
It consists of material that has been considered and in part developed by The Open Group's SOA Working Group. The SOA Working Group is engaged in a work program to produce definitions, analyses, recommendations, reference models, and standards to assist business and information technology professionals within and outside of the Open Group to understand and adopt SOA. The source book does not represent the final output of that work program, which will be published as a collection of Open Group Standards and Guides. It is an interim publication, and its content will not necessarily be reflected in the final output.
The material reflects input from a large number of people from a wide range of Open Group member companies, including product vendors, consultancies, and users of SOA. In some cases, these people have brought concepts developed, not just by themselves, but by groups of people within their organizations. The input has been refined and further developed through discussion within the Working Group. The value in the result is due to the ideas and efforts of the Working Group members.
The material is now published in its current form to make that value available to the wider architecture community.
Olio is a is a web2.0 toolkit to help evaluate the suitability, functionality and performance of web technologies. Olio defines an example web2.0 application ( an events site somewhat like yahoo.com/upcoming) and provides three initial implementations : PHP, Java EE and RubyOnRails (ROR). The toolkit also defines ways to drive load against the application in order to measure performance.
We encourage alternate implementations of the application by either completely re-writing the application using a different language (say python), higher-level frameworks (such as CakePHP)
Macker is a build-time architectural rule checking utility for Java developers. It's meant to model the architectural ideals programmers always dream up for their projects, and then break -- it helps keep code clean and consistent. You can tailor a rules file to suit a specific project's structure, or write some general "good practice" rules for your code. Macker doesn't try to shove anybody else's rules down your throat; it's flexible, and writing a rules file is part of the development process for each unique project.
Read more about what it does and what it's for in the very exciting FAQ. If your curiousity's piqued, skim the guide, or inspect a few simple examples.
It's free (GPL). You can download it and try it out.
Questions or suggestions? Feel free to share them.
Lattix has pioneered an award-winning approach using system interdependencies to create an accurate blueprint of software applications, databases and systems. Architects and developers can analyze their systems in detail, edit the structure to create what-if scenarios, and specify design rules, allowing them to formalize and communicate the architecture to the entire organization. The result is higher quality, improved reliability, and much easier maintenance.
JDepend sorgt für gute Beziehungen
Author: dbt23
11 Mai
Irgendwie spuckt jDepend interessante Werte aus, aber was so richtig damit anfangen? Nur eine Zahl um so etwas wie Paket-Instabilität auszudrücken? Wieso soll ich mich überhaupt um zyklische Abhängigkeiten kümmern, wenn mein System doch prima läuft? Und was um alles in der Welt ist ein dot in der Graphenvisualisierung?
Team spirit for objects Building complex systems from isolated objects often yields poor structure which readily decays during system evolution. Objects should team-up in order to co-operate and jointly deliver complex behaviors. Objects play specific roles within a given Team.
line
Context based dispatch Object behavior is controled by the currently active context of execution. Contexts are reified into Team instances, which may be used to mediate between roles and maintain state of the collaboration.
line
Modules larger than classes On the road to re-use of modules larger than classes two approaches compete: frameworks and components. For many applications white box frameworks are too fragile and black box components to rigid. Object Teams provide a middle road which balances encapsulation and adaptability.
line
Key Features of Object Teams
*
Weaving of aspect code into existing classes (no source code needed).
*
Teams are modules that encapsulate the interaction of a set of role objects.
o
Teams can be type-checked in a modular way.
o
Roles are automatically managed by their enclosing Team instance.
*
Teams can be refined using inheritance.
o
Collective refinement of role classes.
o
Team refinement realizes type-safe covariance of role signatures.
*
Teams are instantiable first class entities.
o
Teams are aspects that can be activated/deactivated at run-time.
o
Roles may refer to their enclosing Team.
*
Explicit connectors bind an abstract Team definition to a base package.
o
Binding happens a-posteriori, i.e., no modification in the base package is required.
o
Team binding is specified in a declarative style.
o
Bindings may specify different kinds of adaptations.
*
Object Teams require a minimal number of new language constructs to be learned for a maximum of modularity and composability.
A rich visual environment helps you to understand structure, control complexity and define architecture. Your reward is a simpler, well-understood architecture and a more agile code-base, development team and business.