Planning_and_Impleme.. - didier beck weblog

More documents

Recommendations

Info

Planning and Implementing SOA www.butlergroup.com It is clear that different organisations will have different needs, but Butler Group would recommend that governance roles are considered during the planning process for SOA projects, identifying what is the most relevant for the organisation, and then empowering (and skilling up) the relevant people. Standards for SOA governance are beginning to emerge. One of the key areas that will support management and governance is the emergence of standards that will allow interoperability across heterogeneous platforms. Web Services Distributed Management (WSDM) is the main standard for management information for Web services. It is an Organisation for the Advancement of Structured Information Standards (OASIS) standard, with version 1.0 approved in March 2005, and a revised version 1.1 delivered in August 2006. It incorporates two elements; Management Using Web Services (MUWS) – which covers the use of Web services as a means to manage distributed infrastructures, and Management Of Web Services (MOWS). As such, the standard is highly focused around Web services issues, and may well need to evolve with the growth of SOA embracing rather more than just Web services – although the use of Web services to provide interoperability is of value. Java Management Extensions (JMX) technology is a Sun-sponsored Application Program Interface (API) that provides the tools for building distributed, Web-based, modular solutions for managing and monitoring devices, applications, and service-driven networks. It is suitable for adapting legacy systems, as well as implementing new management and monitoring solutions, and has been designed to support future management issues as far as possible. The various registry standards to date include Universal Description, Discovery, and Integration (UDDI), ebXML Registry Repository interfaces for Repository (an OASIS standard again), and Java API for XML Registries (JAXR), which provides an API for reconciling UDDI and other XML registries. The latter can be used to allow registry client programs to be portable across different registry types. SOA Link (www.soalink.com) is a body working on end-to-end SOA governance, to ensure interoperability of different offerings on the market. Its members agree to use standards wherever possible (for example those from the World Wide Web Consortium (W3C), OASIS, International Organization for Standardization (ISO), Internet Engineering Task Force (IETF), and ECMA), and by joining, the various technology vendors indicate a willingness to interoperate with one another. SOA Link members include AmberPoint, Composite Software, Forum Systems, HP, Infravio, Intalio, IONA, iTKO, JBoss, Layer 7 Technologies, LogicBlaze, Mindreef, NetIQ, Parasoft, Reactivity, SOA Software, Solstice Software, SymphonySoft, and webMethods. Butler Group Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages, and a model for assembling service components into a business solution... applauds the setting up of such a body, but wonders whether the competitive nature of the industry (and ongoing consolidation) will allow it to remain active, especially since the initiator, Infravio, has since been acquired by webMethods. OpenSOA (www.osoa.org) is an informal alliance including vendors and end-user organisations. It does not regard itself as a standards body, but is looking to define a language-neutral programming model that meets the needs of developers of SOA-style software. It is working on two main projects, Service Component Architecture (SCA) and Service Data Objects (SDO). Service Component Architecture aims to provide a model for the creation of service components in a wide range of languages, and a model for assembling service components into a business solution – activities which are at the heart of building applications using a SOA. SDO aims to provide consistent means of handling data within applications, whatever its source or format may be. SDO provides a way of unifying data handling for databases and for services. SDO also has mechanisms for the handling of data while detached from its source. SCA and SDO can each be used on their own – there is no requirement to use both of them in the same application. SCA and SDO used together provide a powerful and flexible way of building applications around a SOA. As with many of these vendor groupings, it appears that the world is still divided into two camps – the Java world and Microsoft. Although Microsoft is actively involved in many of the interoperability issues, it still appears to have the objective of providing the most flexibility by using the .NET framework as the overarching governing infrastructure for its customers. 18 Section 1: SOA Deployment December 2006
www.butlergroup.com Planning and Implementing SOA POLICY AND SECURITY IN A SOA ENVIRONMENT CATALYST As the concept of services becomes more widely accepted, it will become increasingly important to consider some of the security requirements surrounding them – especially to gain wider acceptance of SOA. Simply restricting access to authorised personnel via standard access control mechanisms becomes impossible in a service-oriented environment, and new standards are starting to evolve here. SUMMARY The use of policies allows abstraction of concepts to a higher level, simplifying creation and maintenance. Security issues for SOA are more complex than in older architectures. Standards for SOA security and policy are starting to mature, and interoperability is improving. ANALYSIS In static architectures and application development, one of the key aspects is that it is possible to hard-wire the security. In creating a SOA with loosely-coupled components, it will be necessary to look at how security needs to be defined and managed for that type of architecture. The same applies for other policies – in the older architectural styles, there is the ability to implement policy at the design level. That ability is not there within a SOA. Here it will be necessary to ensure that the message flows that pass through those architectures actually access and interact with the declared policies at the right points within the architecture. This is a far more complex management infrastructure, but one that is balanced by a far more usable and far more relevant application infrastructure. The use of policies allows abstraction of concepts such as security to a higher level, simplifying creation and maintenance. Policies help to ensure compliance with organisational objectives; at the highest level these are likely to be highly business-related, and tend to cover people-related issues such as “projects must comply with internal design and architecture guidelines”, or generically, that all IT projects are subject to reviews for security and regulatory compliance. Today, policies are already there in most computing infrastructures, it is just that, where relevant, they tend to be hard coded and explicitly defined. An example of a security-related policy is ‘passwords must be eight characters long’ – this implies that there must be code embedded in each application to check that this is the case. This is not practical in SOA – policies must be specified and managed at the infrastructure level. Policies can relate to other areas including management and monitoring. Policies could represent more specific regulatory compliance issues; for example, in the healthcare industry patient’s personal identifiable information must be communicated and stored securely (in order to comply with the US Health Insurance Portability and Accountability Act (HIPAA) legislation). In the business sector, all financial transactions must provide traceability and tamper-proof mechanisms for mandatory audit records (to meet with Sarbanes-Oxley and Basel II regulations). Policies could represent more specific regulatory compliance issues; for example, in the healthcare industry patient’s personal identifiable information must be communicated and stored securely... December 2006 Section 1: SOA Deployment 19
Page 1 and 2: Technology Management and Strategy
Page 3 and 4: www.butlergroup.com Planning and Im
Page 17: www.butlergroup.com Planning and Im
Page 31 and 32: www.butlergroup.com Technology Mana

Planning_and_Impleme.. - didier beck weblog

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?