Section 9.5. Conclusion


9.5. Conclusion

In this chapter, we looked at the different elements that constitute an SOA-enabling infrastructure, which we refer to as a service bus. Based on our conviction that middleware heterogeneity is an enterprise reality that can't be solved by introducing yet another set of interfaces and communication protocols, we described an approach which is based on loose coupling on the infrastructure level, effectively allowing the co-existence of multiple, heterogeneous middle ware platforms within a higher-ranking meta bus which is designed to tie together these different platforms. We also stressed the fact that this meta bus should not be developed in isolation from concrete application projects in order to avoid working on an overly abstract level. Practical experience has shown that one can work for many years on the perfect enterprise infrastructure, without ever reaching a truly stable result. Consequently, a pragmatic, project driven approach should be taken.

The different application execution containers that we find in an enterprise represent the basis for building services in an SOA. We discussed the general nature of these containers, specific implementations, and how to integrate across multiple containers.

To maximize the robustness of our SOA, we discussed dealing with system failures with the main objective of gathering as much knowledge as possible about critical parts of the service. This enables recovery from a service failure to be as seamless as possible, both automatically and manually.

To minimize such failures in the first place, we discussed concepts for scalability and availability. Both can be addressed using standard products and procedures and sometimes hardware components such as balancers are a good option. On the other hand, most frameworks for distributed objects such as EJB and CORBA support the basic building blocks needed.

Proper planning is essential for providing an available and scalable system. This holds true for the initial definition of the SLAs up to any subsequent exercise to scale a system by adding additional hardware and software.

It is fairly easy to accomplish availability at the system level and between individual requests. Guaranteeing in-request availability is considerably harder. It is not required nor appropriate for a vast number of application scenarios, and it introduces a significant overhead into system performance, very much comparable to the problems of distributed transactions. For practical reasons, the easiest way to accomplish availability is to maintain request cycles and transactions that are as short as possible. If anything goes wrong at these points, then using the strategies from the previous sectioncoping with failureswill usually be sufficient for controlled recovery.

Always consider the weak points in your application first. Keep in mind that the application is only as strong as its weakest link, both for availability and scalability.

Finally, note how much easier it becomes to cope not only with availability and scalability but also with service failures if your business logic becomes stateless or even idempotent. The strategies that deal with stateful systems are more complex and tend to impact on the overall system performance and ultimately on scalability and availability.

On top of providing reliability and availability, any IT infrastructure must support certain security features. Although technologies and tools are available that can be used to provide transparent, enterprise-wide authentication and authorization for an SOA, it is very likely that a first step will provide only authentication as part of the SOA framework itself. The reasons are mainly rooted in the fact that authentication can be introduced in most legacy systems with very little effort, while refactoring the authorization aspects of an application requires more effort. Also, it will be far easier to implement from an organizational perspective. Legacy applications are likely to be placed within trusted domains to allow for integration into the SOA without disturbing the ongoing operation of the application.

SOAs are often introduced together with a single sign-on framework. Shifting more and more aspects of application security, such as authorization, encryption, and PKI, to use the framework over time, an SOA can employ and foster the implementation of a true enterprise end-to-end security infrastructure.

References

[DC2004] Chappell, Dave . Enterprise Service Bus. O'Reilly, 2004.

[GS1996] Garfinkel, Simson , et al. Practical UNIX and Internet Security. O'Reilly, 1996.

[GS1997] Garfinkel, Simson , et al. Web Security and Commerce. O'Reilly, 1997.

[GS2003] Gupta, Samudra . Logging in Java with the JDK 1.4 Logging API and Apache log4j. Apress, 2003.

[H2003] Hartman, Bret , et al. Mastering Web Services Security. Wiley, 2003.

[PT2001] Peltier, Thomas R. Information Security Risk Analysis. Auerbach Pub, 2001.

[PH2000] Piedad, Floyd and Michael Hawkins . High Availability: Design, Techniques and Processes. Prentice Hall, 2000.

[TDM2000] Tardugno, Anthony , Thomas DiPasquale, and Robert Matthews . IT Services Costs, Metrics, Benchmarking and Marketing. Prentice Hall, 2000.

[SK2003] Schmeh, Klaus . Cryptography and Public Key Infrastructure on the Internet. Wiley & Sons, 2003.

URLs

http://www.redbooks.ibm.com/redbooks/SG242234.html

http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=security

http://www.w3.org/Encryption/2001/

http://www.omg.org/technology/documents/formal/corba_2.htm



    Enterprise SOA. Service-Oriented Architecture Best Practices
    Enterprise SOA: Service-Oriented Architecture Best Practices
    ISBN: 0131465759
    EAN: 2147483647
    Year: 2003
    Pages: 142

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net