SATURN 2011 Session: Service-Oriented Architecture (afternoon session, May 18, 2011)

Notes by Jack Chen

Experimentation in the Use of Service Orientation in Resource-Constrained Environments
Soumya Simanta, Software Engineering Institute
Edwin Morris, Software Engineering Institute
Daniel Plakosh, Software Engineering Institute
Joe Seibel, Software Engineering Institute
Bill Anderson, Software Engineering Institute

Abstract and presentation slides

Building a situational-awareness application

  • real-time data transfer
  • mobile, in the field (Android)

Tactical environment; “last mile” users, individual infantry trooper that requires situational awareness

Related work

  • mobile computing in the military environment
  • general dynamics, wearable computer based on Android; also has developed TIGER mobile; uses historical data (recording and retrieving)
  • situational awareness development on iPhones and iPads (related work)

Key design decisions

  • transport layer protocol, reliability is stressed
    • wireless bandwidth changes unpredictably
    • connectivity changes unpredictably
    • TCP caused significant delay during network-adverse situations
    • we were more interested in getting the most up-to-date, not every packet, choose UDP
    • messaging protocols. Choose a SOAP format hoping to take advantage of well-defined specs. Special flavors of gSOAP and kSOAP (this did not support UDP out of the box)
    • security
      • looked at WS-Security, but this was incompatible with the kSOAP format
      • considered implementing security on top of kSOAP, but decided it was not cost-effective
      • chose instead to encrypt the entire serialized SOAP message using AES-256
      • on the other end, the phones would decrypt this data

Conducted a video experiment over TCP and UDP

  • the video format used is taken from UAV’s motion jpeg (MJPEG). No information about frame rate, or other meta data
  • UDP got a much more consistent frame rate than TCP

UAV video and tracking

  • test had a rental card driven with GPS relay
  • this information was then sent to the servers and forwarded to PC displays as well as mobile displays

Prototype 1

The mobile aspect of the demonstration was well received by field testers.

Suggestions for improvements was to have coordination between all mobile units.

Wanted the ability to mark and annotate a shared map

Mobile devices are hard to use in bright sunlight, and touchscreen has problems when gloves are used.

Noticed certain issues, performance on the mobile device was greatly degraded.

The soap format was base-64; the decoding process was expensive.

Multiple video feeds degrade mobile performance as well.

kSOAP had limitations on how the message was parsed, an attempt to partially parse the message did not work.

Prototype 2

Encryption was enabled (done in C for performance reasons).

Mobile-peer tracking was enabled.

The mapping facility was changed to allow the usage of cached maps (do not require connectivity).

The most expensive aspect of the project was XML parsing.

Prototype 4

Moving from wifi to GPRS data network.

Bandwidth was 12 kbps.

Converted the message format to a binary representation.

  • Used Google protocol buffers instead of writing own binary format
  • some issues – Google protocol buffers uses C++ templates which is not compatible across different compilers

Video was not plausible, still images were used instead.

Security overhead

Interoperability overhead of using soap/xml was the most costly

SOA can be used, but requires some coaxing to deal with performance.

UDP had a maximum packet size, thus was a constraint enforced on the video frame size.

Non-software issues with respect to visibility and radio interference.

Current research areas

  • processor & battery concerns. Computationally intensive operations should be off-loaded to a small cloud that exists in a Humvee (for instance)
  • edge-enabled systems

Question: why Android?

  • considered primarily Android and iPhone, chosen because of familiary with Java
  • in some cases an iPhone may be a better choice, with respect to performance

Dealing with Complexities of a Global Service-Oriented Architecture
Tarmo Ploom, Credit Suisse
Claudio Jossen, Credit Suisse
Roberto Di Paolo, Credit Suisse

Abstract and presentation slides
How to build global SOA

Key message

  • to build up global SOA is difficult
  • focus on simplifying SOA systems
  • decision trees help identify design rules

Makeup of Credit Suisse, one bank, three business lines

  • private banking
  • corporate & investment banking
  • asset management

Credit Suisse is truly global.

Large scale: > 6000 applications; > 100 MLOC

High complexity: large number of tightly coupled components

Aging: obsolete systems

High change rate: > 3000 product changes per week

Demanding operational quality: high reliability, availability, security

Answer: SOA to manage complexity of the landscape

> 12,000 people

Various managed services handled by SOA infrastructure

3 main dimensions of SOA

7 sub-dimensions

  • logical view; orchestration
  • security view
    • authentication
    • authentication variability
    • authorization
    • trust zone
    • infrastructure view
      • middleware variability
      • executable distribution variability

Migrating from local to global SOA increases design dimensions by 3 and They are all interdependent.

Complexity explosion when migrating from local SOA to global SOA.

Solution space overview

  • define a “set” of valid solutions instead of “the” solution
  • shape the solution space with assumptions and constraints

Cumulative component dependency (CCD)

  • defines system entropy
  • favor a design rule that reduces the cost of overall complexity

A decision tree helps guide the design process.

  • business constraints serve as the root of the decision tree
  • these are provided by the business
  • design rulesdefine the detailed subtrees
  • these are defined by the IT architecture

A concrete example can be visualized by how a layering system is used

  • a complex layering system that allows the top layers to call every layer below it has a very high complexity rating
  • if a design rule is introduced that requires that only the immediate child can be called will drastically reduce this rating

Question: what is a service?

Some abstraction, a logical construct (independent of technology)

Question: cardinality of the relationship between consumers and services?


Question: how to maintain a consistent global decision process?

Question: can you relate complexity calculation to $$?

Question: who owns the decision trees and updates them?

We are responsible, but a dedicated architectural group needs to take this over.

Question: how does this SOA scale?

The design rules are critical to help with this.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s