WICSA 2009 WS4 -- 21st Century Architectural Styles

From WICSA Conference Wiki

This page was written around the time of WICSA 2009.

Session Chairs: Liming Zhu and Chris Cooper-Bland

Tuesday, 15th September, 13:30 - 17:30

Contents 1 Participants (Tentative) 2 Papers 3 Contributions 4 Working Session Details 4.1 Goal 4.2 Strategy 4.3 Results

Participants (Tentative)

Please sign your name here if you are thinking of attending this BoF. (Click the signature button in the editor). Tell us something about your background. Add a few sentences about the working session topic such as your position, questions you would like to see discussed, etc.

• (example) --Bob Schwanke, Siemens Corporate Research. Architecture styles should be subjected to architecture analysis, early and often.
• --Shaun Laurens, E.ON Energy Trading SE.
• About 20-25 participants.

Papers

• "An Architecting Method for Distributed Process-Intensive Systems", by Xiwei Xu, Liming Zhu, Mark Staples and Yan Liu

  This paper introduces an architecting method for distributed process-intensive systems. Traditional methods (e.g. object-orientation, structured analysis or component/service-based designs) decompose a process-intensive system into entities with attached domain-specific operations (process constituents). This results in fine-grained Remote Procedure Calls in distributed systems which are often detrimental to quality attributes such as performance, loose-coupling, adaptability and interoperability. Our method tailors the REpresentational State Transfer (REST) principles used for hypermedia data transfer to process-intensive systems by making process constituents into resources, and attaching a set of standard operations. Distributed processes interoperate by adhering to these operations and exchanging process information. In our method, process information exchange contains not only typical meta-information about a process, but also process fragments that indicate possible next-steps and interconnectedness for process coordination purposes. We have implemented our method in a Web environment and conducted a case study providing initial validation of its benefits.

• "Self-Optimizing Architecture for Ensuring Quality Attributes in the Cloud", by Vivek Nallur, Rami Bahsoon, Xin Yao

  We describe various challenges in ensuring Quality Attributes (QA) of applications hosted in the cloud and hence the perceived quality of service of the cloud as a whole. We advocate a self-management/optimization architecturedriven approach to ensure that Quality Attributes are met. We discuss the limitations of current approaches to self-managing architecture. We propose a novel approach, which exploits the El Farol problem as a modelling mechanism for QAs in architectures of applications in the cloud. The approach uses Service Level Agreements (SLA) and Utility Theory to direct the self-optimization. We conclude by looking at directions for further work.

• "On Service-Oriented Architectural Concerns and Viewpoints", by Qing Gu and Patricia Lago

  Despite the many publications around the innovation and challenges introduced by SOSE and SOA, the 'real' differences with traditional software engineering and software architecture are still very fuzzy. To better understand the innovative points (if any), in this work we identified seven fundamental differences by conducting a literature review, linked them to some service relevant aspects and mapped the differences & service aspects on the well-known architecture-related concepts of 'architectural concerns' & 'architectural viewpoints'. As such, we were able to identify an initial set of requirements for service-oriented viewpoints. If specialized in industrial contexts, we would be able to exemplify innovative points by capturing service relevant aspects. In perspective, this work seems to scale down 'innovation' of SOSE and SOA, to 'relevance' of service aspects to engineering and architecture.

Contributions

If you have relevant materials or references, please add here:

Working Session Details

From the official working session structure page:

Working sessions are two hours. Each working session contains three or four short papers about related subjects, and starts with 10-minute presentations of each short paper. The remaining time of the working session will be spent discussing the session's topic with the paper authors and other workshop participants. The working sessions will be facilitated by two working session chairs: one from industry (Chris Cooper-Bland) and one from academia(Liming Zhu). Sessions will use the conference wiki to provide paper preprints and other information to participants, formulate issues to discuss, and coordinate and capture session outcomes. Follow the links below to each working session's wiki page... (check website for rest of the info).

Draft Agenda

• 4 x (10-min presentations + 10-min question time)
• Participants nominate the topics they want to discuss. Presented papers are already candidate topics. If there are too many topics or similar topics (usually they do), they will be grouped or voted.
• The two chairs will facilitate the discussion and take notes.
• By the end of the session, chairs and participants will contribute their notes and ideas to this wiki page.

Goal

• Do we need any new styles? Why?
• How to capture and document styles?

Strategy

• Identify new trends which may or may not demand new styles
• Identify ways of discovering/inventing and documenting styles

Results

• Standard ways of describing architecture styles
  • Granularity of styles
  • Just use existing architecture documentation methods
  • REST as an example:
    • Was trying to use "type" initially and a formal way; very difficult to formalize
    • But came down to 6 short informal points. It took a long time to get down to these simple but deep points. Styles are something people pay attention to.
    • REST was already addressing many of the current trends: increasing computing power, scalability, multiple people want to participate, connectedness.
    • Web is different now and Browser is highly powerful today (e.g. mashup) .. Wasn't planned in the original REST
    • HTTP1.1 deviates from REST, for example cookies
  • Use patterns template; pattern archtypes
  • Styles/Patterns are discovered or invented? REST is certainly not discovered but deliberately designed.
  • Definition of architecture styles: a set of constraints
  • Having semantic components in styles? Ontology embedded styles?
  • patterns vs. styles; designs vs. architecture
  • Styles should be kept deliberately vague and all-encompassing?
  • SOA style is difficult to define
  • Viewpoints driven managing of architecture styles?

• 21 century architecture styles
  • Any new major trends demanding new styles?
    • Huge increase in computing power
    • Massively distributed systems including embedded devices; but always there is need for standalone systems (security, reliability)
    • A mix of old and new. Evolving old applications to new environment; integrating new parts into old system
    • Trust is needed to: allow parts of systems to run in the cloud; share information; opening up the organization (Regulation: opposite of trust?)
    • Need low unbundling cost for cloud-sourcing and outsourcing
    • Open source, closed source and commodity software
    • Green ICT ; resource-aware/centric architecture
    • Concurrency and multi-core
    • New development environment; user-driven programming; mashups; edge programming; mass programming
    • More and more legacy systems
    • A lot of more small applications; small compositional applications
    • Self-* systems; autonomic computing
    • Domain specific languages
  • 20th century architecture styles? New technology benefiting from existing styles?
  • New styles: SOA, Cloud, SaaS (Software as a Service), Event driven SOA, CREST, RESTful Business Process

• Other Issues
  • Need to identify underlying principles of architecture styles to overcome unlimited number of styles
    • SEI's architecture tactics?
  • Difficult to introduce a new style to an organization?
  • Styles can be designed into middleware? Many quality attributes are constrained by the middlewares that are available in the market.
  • Exposing process/computation means tight coupling? No.
    • CREST: sending complete program to be used to compute locally
    • Loose and looser; it is a degree of coupling; a completely decoupled system means no communication among parts at all.
  • Error resolution and exception handling in cloud? How to trace responsibility? Prof. Anna Liu's (UNSW) survey on cloud monitoring.
  • Green IT: how to handle inter-disciplinary aspects? Is it a matter of styles? How to illustrate "soft" aspects with computer science?
  • Social networking: opinion/trend mining . CEP (complex event processing) can be used to implement. Many inexpensive CEP technologies exist.