SOA Life Cycle SOA design principles
{"Image DocumentName": "SOA Life Cycle SOA design principles", "Image ImageDescription": "The guidelines in this section are concerned with the overall SOA system, representing decision points for establishing your system. What prescriptions and guidelines will you give the service designers and implementers? What capabilities will your SOA infrastructure offer? We give a number of suggested design principles, but each represents an engineering trade-off. Your enterprise may have specific requirements that lead you to make different choices from our general recommendations. Our intention in setting out our design principles is to identify the decision points; the responsibility for those decisions lies with the architects. We do not claim that our set of design principles is exhaustive; it is very likely that as you implement an SOA in your enterprise you will adopt additional principles, and we would be very interested to hear about them. SOA requires consistency. There are many candidate technologies for creating, publishing, discovering, and invoking services. An SOA should provide a reference architecture specifying particular mechanisms that service providers and consumers will use; we should aim for consistency across all participants in the SOA. Such consistency should reduce development, integration, and maintenance effort. If there are needs for exceptions to the reference architecture, we prefer a complementary approach. For example, suppose that UDDI were the chosen mechanism for service publication and discovery, but a particular development team had a well-established development process based on some other repository technology? We would choose to invest effort in publishing that team s services to both repositories. Hence existing consumers of the service could use their familiar -- if nonstandard -- repository. Consumers operating in the common SOA infrastructure would be able to use the standard --perhaps UDDI -- repository for all services. SOA simplifies development. We would expect any enterprise-scale SOA infrastructure to be both scalable and resilient; it should also include industrial-strength Enterprise Service Bus (ESB) and security technologies. Or, to put that another way, developers of services and processes targeted at the SOA infrastructure exploit sophisticated middleware, relying on the SOA infrastructure to provide solutions to problems such as authentication, message transformation, and reliable message delivery. One important principle should underlie the provision of these middleware capabilities: service and process developers should be insulated from the complexities of the middleware implementation. Our idealized goal is that developers working in our SOA environment should need only business domain knowledge and basic programming language skills. We can work towards this goal in a number of ways, as follows: Declarative techniques: The J2EE programming model is an example of using declarative techniques to provide separation of concerns between the application logic and the configuration of middleware. For example, an application assembler applies security authorization of roles for EJB methods by adding entries in deployment descriptors rather than in code; then a deployer will map the roles to users and groups. Note that the developer need write no authorization code. Abstractions: In some cases the SOA infrastructure may offer APIs for particular purposes. For example, the SOA infrastructure may have error reporting or auditing facilities. We should take considerable care in designing these APIs, paying attention to ease of use. We should favor declarative techniques over programmatic configuration of these facilities. Also, where standard APIs are available, for example the Java logging APIs, we should expose the SOA infrastructure capabilities via those standard APIs rather than devise our own. Code generation: Where some complexity of code is unavoidable it may be possible to use code generation techniques. As an example, consider Web Services Definition Language (WSDL), which can be used to hide complexities of SOAP, HTTP and JMS from the developer. This is accomplished through the combination of machine-readable interface definitions expressed in WSDL and tooling that can generate language-specific implementations of the relevant invocation code from the WSDL. Tooling: In cases where details of the SOA infrastructure unavoidably intrude into the developer s code, we can reduce complexity for the developer by extending the development environment with suitable tooling. An Eclipse-based environment offered by the IBM Rational\u00ae Software Development Platform products is readily extensible with custom plug-ins, code snippets, and user guides. Model-driven development: Model-driven development techniques can be seen as a particularly sophisticated combination of the previous two approaches, exploiting both tooling and code generation capabilities to simplify the development experience. The developer produces Unified Modeling Language (UML) models that can be transformed to code that includes the code necessary to exploit the SOA infrastructure. In summary, in defining a Service-Oriented Architecture and its infrastructure, we must pay careful attention to the needs of developers. Where we offer developers guidelines for how they should develop or use services we should seek mechanisms to encourage adherence to those guidelines. A general principle should be Doing the easy thing is doing the right thing. In other words, adherence to the guidelines should be perceived as taking the line of least resistance. Governance within the SOA becomes a crucial element to its success. From the developer s perspective there is a responsibility to understand the SOA infrastructure and guidelines and to work with the guidelines rather than seek to avoid them. Services have standard, formally defined, machine-readable interfaces. Having established that tooling and code generation can play a significant role in SOA implementation, we can now emphasize the importance of using machine-readable interfaces. When we describe interfaces using a well defined machine-readable language, we enable a broad range of tooling capabilities. Remembering that we wish to promote decoupling, we strongly favor the use of formally-defined open standard languages such as WSDL over a proprietary format. The concept of a machine readable approach should be expanded from the description of service interface, such as WSDL, to all other forms of declarative information or meta-data. This twin emphasis on declarative techniques and machine-readable metadata is what pushes the complexity away from the business application developer into the standards-based middleware. Technologies such as the emerging WS-Policy are an important enabler of this approach. Services are designed for reuse. Service designers should keep in mind that any service they product can potentially become a reusable asset. The designers should not exclusively focus on requirements of the initial consumers of a service, but rather should undertake more extensive business analysis in order to determine more complete requirements. We recommend that designers consider the potential evolution of a service: The design must accommodate increasing throughput; if a service is successful then the number of consuming services may well increase and hence usage may well increase by orders of magnitude. If the number of consuming services increases then both data volumes and concurrent data access patterns may be significantly different from the initial situation. We must anticipate that there will be requests for extensions to the service; new consumers may well need additional functionality and modifications to existing functionality. Many of the design principles we discuss in the remainder of this article are particularly relevant to ensuring the scalability and maintainability of services. We offer one word of caution: it is possible to spend undue effort in designing services for potential reuse and hence to over-engineer implementations. We would encourage an initial focus on the design of the service interface, ensuring that it enables scalability; our design principles should help with that. Then produce a tactical implementation of that interface sufficient to meet current, known requirements. Provided that the interface is well-designed it should be possible to substitute a more scalable implementation when the need arises.", "Image XResolution": "37", "Image YResolution": "37", "Image ResolutionUnit": "Pixels/Centimeter", "Image Software": "SlidePlayer", "Image YCbCrPositioning": "Centered"}