Attendees
25 people attended the session, filling the room to capacity.
The first question raised was "what is SOA?"
One way of approaching the question is to list principal characteristics of SOA service components. They should:
- be reusable
- be loosely coupled
- present contracts for interaction
- represent abstract logic
- be composable
- be autonomous
- be stateless
- be discoverable
Examining this list of properties invites the question: How do we design software this way?
SOA can be seen as a philosophy.
Another question is: What is the role of a portal in an SOA infrastructure? One response is that the portal is a loosely-coupled presentation layer which can display content generated by services. A portal may be just a front end. It appears, however, that JSR-168 doesn't provide all the mechanisms a portal should have for interacting with diverse services.
In moving toward SOA, an institution may either create a lot of atomic services out of which to compose business applications, or they may simply push down the web servics layer into the applications – decomposing them from the top down within the operational service.
Using a "language binding" approach to SOA has resulted in a lack of interoperability. This is a reason for looking at WS-*.
SOA is not equal to Web Services. (We take this to mean that just implementing Web Services does not result in a Service-Oriented Architecture.)
It appears that SOA is still not mature. Web services standards are observed to be diverse, in flux, and in competition with each other. WS-I has a basic profile for interoperability, but it is still early days.
Thomas Erl (a well-known SOA consultant and author), states that SOA is all around analysis, and not around implementation. Current technology is not as far advanced as peoples' expectations – this is a challenge.
Looking at the architectural priniciples of SOA has a great deal of value, e.g. going from a business process to a set of services.
There is a human element to all of this – people are not satisfied with being "trained to an interface". SOA should enable agility for people through a cultural shift.
SOA doesn't present any new or unfamiliar basic principles – they are all sound and well understood precepts from software engineering. They are applied in two new domains, however. Our mind set must change for both the operation of the network and in how we view application development. These are new challenges, although we observe that the principles have already been tried and proven through OOD.
Business analysis is a vital aspect of the SOA approach. A recent project spent 9 months on business analysis, resulting in a rapid implementation accomplished in only 3 months.
It has been observed that we have been dominated by our (applications) software for so long that we often don't even know what our processes are.
A valuable tool in an SOA implementation is a rules engine. Business rules can be abstracted from processes, and then re-expressed through a rules engine. Rather than create a service that works for everyone, we can create a service that will work for anyone – if they configure their own rules. This enables processes to change their behaviour as policies change, without the need for re-programming.
The question was asked: How are people driving business analysis? Really, the business analysts should be driving, but few universities have business analysts on staff. It is necessary to find others to take on this role. If we follow this course, SOA becomes attractive. The opportunity to do something arises when something needs to be fixed. It is up to the IT people to say, "here's a new way to do it that gives us more".
We need an empowering way of trying it out, without committing huge resources. A piecemeal approach is very attractive.
There are two schools of thought, covering a spectrum with widely separated endpoints:
- Map the entire enterprise before writing one line of code.
- Just start writing web services.
An intermediate position is to write web services with a high-level approach always kept in mind.
We need to have ongoing discussion on this. Ways to get into SOA, ideas, stories.
Finding a senior staff member (e.g. a new appointment) who wants things to happen can be a good way of getting executive support.
There are good sources of documentation from IBM (see the Wikipedia entry), and the Burton Group.