| home / programming / soa2 / 1 | [previous][next] |
|
|
Especially when developing second-generation Web services, incorporating a sound security model is a key part of your design process.
Application A is replaced without affecting application B.
Security requirements define boundaries, real boundaries “The functional application design needs to be built upon the security model, (not the other way around).”
Putting together a design, and perhaps even building a preliminary version of your application without serious consideration for the underlying security model is a common mistake. It’s like going out on stage for your performance, and then, before you can finish, getting pulled back with one of those long hooks. (It’s the security requirements pulling that hook, in case you didn’t get that.)
Web services security models are unique, complex, and multi-dimensional. There are many factors to consider that will result in firm boundaries that will shape and scope the remaining part of your application design.
Define the scope of the security model “A key part of a standardized service-oriented enterprise is a service-oriented security (SOS) model.”
When we talk about a Web services security model, it can mean a number of different things. A model can represent the security rules and technologies that apply to an application. It also, however, can be standardized within the enterprise.
\The enterprise SOS model displayed in Figure 13.5 establishes a standard security platform that includes policies and the technologies that enforce them. As shown in Figure 13.6, this model can be implemented within a dedicated security services layer that also becomes an application architecture standard. (For more information, see Chapter 11.)
Figure 13.5
The service-oriented security (SOS) model.

A separate security layer can implement the SOS model.
The required use of a SOS model can impose significant restrictions upon application designs. This is offset, however, by the fact that its use also alleviates application development projects from having to deal with many of the issues relating to security. Most of the decisions will have already been made; all the project team has to deliver is an application that conforms to SOS standards.
“Group development teams around logical business tasks.”
A common mistake in development projects that incorporate a limited SOA is to have one team deliver the Web services, and the remaining team(s) develop the balance of the application. From a resourcing perspective this approach makes sense, because you have each team working with technologies that match their respective skill set. It can, however, create a disconnect between developers responsible for building parts of an application that deliver a logical unit of business functionality.
When you break an application down into its primary (or even secondary) business functions, you end up with the equivalent of a series of subprojects that collectively make up the application’s feature set. Each of these subprojects will typically require the creation of a number of application components, some of which may be encapsulated within Web services. Development teams need to be grouped in accordance with these subprojects, so that the performance and functionality of individual business tasks can be streamlined.
If you have only one or two developers qualified to build Web services, then you should consider sharing them across more than one development team. As long as they are actively participating with their respective teams, they will be able to optimize the Web services to best accommodate each business task.
| home / programming / soa2 / 1 | [previous][next] |
Created: March 27, 2003
Revised: February 21, 2004
URL: http://webreference.com/programming/soa2/1