- physical connections - via mediator instead of point-to-point communication style - asynchronous instead of synchronous
- data model - simple common types instead of complex common types
- type system - weak type checking instead of strong type checking
- control of process logic - distributed control instead of central control
- binding - late(dynamic) binding instead of early(static) binding
- platfrom - platform independent instead of strong platfrom dependency
- transactionality - compensation instead of 2 phase commit
- deployment - independent instead of simaltaneous
- versioning - independent upgrades instead of simultaneous upgrades
Wednesday, December 10, 2008
topics for considering loose coupling in SOA
Monday, July 14, 2008
Web applications Security Check List
Following a list of web security related functionalities that need to be implemented in a typical web application
- channel processing checks - redirect certain requests automatically to https and vice versa.
- maintain a list of urls which will automatically redirect to https
- concurrent session checks - user is not logged in more than once
- Http Session Integration processing - populate security context using http session, remembers prev authentication stored in session
- Logout checks
- Exception Translation checks - handles authentication and access denied exceptions
- Authenication processing - delegates to authentication entry point, filter and finally manager
- Authentication entry points and filters - http basic auth, http form based, http digest, X509 certificates, SiteMinder based
- login form url ; force use of https ; auth failure url ; default url if target url is blank
- Remember me checks - no need to relogin if revisiting website within http session timeout
- Anonymous processing checks - no need to login at all for accessing some resources
- Filter Security Interceptor - delegates to authentication manager and access decision manager
- access decision manager associates url / resources with roles
- Associates url / resources with roles
- authentication manager -> Authentication Providers
- Anonymous DAO based ; LDAP based ; Jaas based ; Remote ; X509 based
SOA Design - Service Coupling
Following figure depicts less-than-ideal service coupling. Service coupling can occur at various levels including at the persistence layer, where we can have services "being aware of each others data models, through query joins
Following figure depicts ideal services coupling. Services should be decoupled and should inteact with each other through "formal service interfaces"
Following figure depicts ideal services coupling. Services should be decoupled and should inteact with each other through "formal service interfaces"
A common problem in SOA deals with deciding data access with respect to services. Should each service have its own data model?Should one service be allowed to access another service data tables at cost of increased coupling?Should a common data access service be modelled?What about interaction / coupling between such a data access service and other functional services?
The following is one proposed approach for data access in context of SOA service design
The challenge here is to try and reduce:the common data model size and keep it to minimal
the amount of access to common data model, instead prefering formal interfaces
the extent of access to common data model, prefer giving read access as compared to write access
Subscribe to:
Posts (Atom)