Service oriented Open Standards

What are Service oriented open standards

The key enabler of service orientated strategy is to define the standards for encapsulation that enable decoupling of the services. This leads to business benefits of flexibility (improved choice and reuse) and total cost of ownership reduction opportunities ( configure rather than rebuild, compose and develop faster).

Open standards means that they are either:

• Supportive of industry standards for Aerospace

• Supportive of standards bodies (e,g. OMG, W3C, OASIS..)

• Supportive of specific Vendor standards that enable common exchange with Web servers intra and extra organisation based on shared service contracts for the service (service specifications defining the schema and use of the service)

Service oriented standards need to operate at a number of levels of the logical technology stack and importantly this then needs a governance framework to preserve these services.

This involves not just technological components but also organisation and skills to manage and deliver these services with new behaviours.

Service oriented Open Standards: the key dimensions

The development of standards for service orientation needs to cover a number of aspects. The following diagram illustrates the key topics for standards to enable service oriented architecture solutions and governance.

Service oriented open standards are defined for these three areas and are used in the web server exchange to manage the services lifecycle.

Service oriented open standards contribute to the solution in these three areas by

• Establishing services as open standards schema and contracts that are reusable design patterns.

• Establishing open standards that alternative vendor technologies can work towards and configure consumption and reuse of. Through design principles and open standards references we ask vendors to support these. WebMethods supports a wide variety of these Open standards for example.

• Establishing the common definition of services that enable a shared view of the services that can be governed as capabilities. Without this today’s SOA artefacts become tomorrows legacy

Specific Service oriented Open Standards

Examples of Service oriented Open standards are:

Presentation Tier

• JSR 168 (Java Spec Request) for interoperability of portlets across different platforms

• XML (Data)

• XSLT (Structure)

• CSS (Design)

• JAVAScript / ECMA (Behaviour)

Data / Content

• W3C's XML Schema (XML, XSL, XSD)

• ebXML Collaboration Protocol Profile (CPP) references schema for instance data being used in a service or collaboration of services

• Complex schemas - OASIS

Web services

• WS*I - WS-I Simple SOAP Binding Profile.

• WSDL (W3C) used to express related schema fragments constrain XML instance data being passed in and out of services

• W3C's XML Schema

Policy

• WS Policy

• See registry

Connectivity protocols

• HTTP/S

• HTML

• JavaScript

• .NET

• JDBC

• MQ

• FTP (not typically open by a protocol supported)

Registry

• ISO/IEC 11179 Part 3 (ISO standard for metadata registries)

• OASIS ebXML Registry-Repository Technical Specifications

• OASIS UDDI Technical Specification

• UDDI version 2 (supports external UDDI) future moving to v3

Workflow/Process management

• BPEL 1.1, BPEL 2.0

Frameworks

• J2EE Framework

• .NET Framework

• DotNET

• COBRA

• WSDL (W3C)

• ASP.NET

Security

• Federated ID using Liberty / SAML standard

• Support external access directories e.g. RAD NS and LDAP

• Netlogin (Activity Directory and LDAP

• X.509 Digital certificates and OCES Certificates

• Act 404

How do we help adoption of the service oriented open standards

The following diagram illustrates how we would develop a practical roadmap to building an Enterprise services Platform using service oriented standards:

Service Governance adoption process.

1. Establish SOA standards as described in the previous section covering XML, Web services, orchestration and protocols

2. Develop a current view of the architecture (This is already been developed in EARS – Troux- a strategic tool for BAESystems) This is to identify candidate system platforms and enterprise service platforms

3. Develop a SOA infrastructure framework (such as Infravio WebMethods) to establish and repository of design time and registry of run time models and objects

4. Develop the service portfolio process to define what services will be made into reuseable and flexible services (IT services (Web services) and Business Process Services (executable processes)).

5. Prioritise and business and economic priorities

6. Develop services for new platforms

7. Develop services for legacy / heritage platforms

8. Develop a procurement program and project management process to plan the construction and reuse of services. Establishment of the organisational architectural office and design authority processes.

9. Develop service policy model (e.g. how different organisations/ BUs will use services

10. Develop and cultivate the services into the registry and repository framework. Manage versions and configurations.

#SOA #Standards #ArchitectureGovernance #EnterpriseArchitecture