The ActiveBPEL™ engine is a robust runtime environment that is capable of executing process definitions created for the Business Process Execution Language (BPEL) standard.
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.
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.
Welcome to the ArchStudio 3 homepage! ArchStudio 3 is an open-source software architecture-based development environment developed by the Institute for Software Research at the University of California, Irvine.
ztest
ztest is a small classlibrary based on java 1.5 intended to be used in junit tests.
The main purpose of ztest is to put constraints on the code structure of java programs.
It can and should be used to specify an architecure by putting constraints on class dependencies. The architecture can be reused by reusing the test.
ztest scans the bytecode of class files in directories, jars, wars, ears and computes a dependency graph. You can query this dependency graph and define the architecure by specifying valid dependencies and rejecting invalid ones.
ztest comes with a dependency-test (ZDependencyTest) with which you can define sets of classes and the allowed dependencies between them.
The class sets are defined by filtering the nodes of the dependeny graph.
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.
IAwiki is a collaborative knowledge base for the topic of InformationArchitecture. Anyone can contribute, and there are no pre-registration hoops to jump thru ... just click the "Edit This Page" link at the bottom of any page.