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
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
- 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)
- 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
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.
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.
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.
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
- 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
- logical view; orchestration
- security view
- authentication variability
- 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.