soa for web services pattern 2012

ARCHITECTURE MANAGEMENT PUBLICATION

SOA for Web Services Pattern – 2012

This guide defines the current status position for the SOA for Web Services Pattern.

Authors: SOA Center of Excellence / Application Developent SolutionsContact: [email protected]

*For current version, see: https://www.tc.ford.com/ts/ampo/publications/default.aspx

SOA COE ADS / DNARANJ2 Date Issued: 03/31/2012GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Released

4th Quarter

2012

https://www.tc.ford.com/ts/ampo/publications/default.aspx

mailto:[email protected]

S O A F O R W E B S E R V I C E S P A T T E R N 2 0 1 2

Revision HistoryThis page is used to record changes/modifications made to SOA for Web Services Pattern. Use this page to record significant changes to the document's content or format. Grammatical/spelling corrections, minor format changes, and slight content changes need not be documented.

Use the table below to record pertinent details about the changes/modifications:

Date Change Description Initiated By:

03/31/07 Initial SOA for Web Services Pattern 2007 Enterprise Technology Team

08/31/07 Second Edition of SOA, included updates to Section 3 on the inclusion of DataPower, updates to the SOA for Web Services Bill of Material, and other minor updates

Enterprise Technology Team

03/31/08 Draft of 2009 pattern. Major updates include DataPower implementation, introduction to ESB and design practices, and future state on all components


08/30/08 Published 3rd Edition of SOA, taking out ESB and SOA COE (replaced with SOA Consulting Group); updated BOM to reflect changes from 2008 ETCP audit; moved R-R research and emerging states back 2 quarters; updated versions on WS-I standards;


11/18/11 Updates Web Services Usage scenarios in Chapter 2; updated Service registration process; added sections on Service architecture and Service Versioning

SOA Center of Excellence

10/18/12 Various updates: service registry repository component, governance process, SOA for Web Services standards, roadmap and logical architecture, service mediation, and reference links.

Denis Naranjo -Application Developent / SOA Center of Excellence

11/26/12 Some of the contents, which are time-sensitive and require frequent updates, have also been kept as Wiki pages stored at SharePoint site. The Wiki pages are linked from this document so viewers can get to the updated contents.

Denis Naranjo -Application Developent / SOA Center of Excellence

SOA COE ADS / DNARANJ2 Page i of 59 Date Issued: 03/31/2007GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Chapter

1


SOA FOR WEB SERVICES PATTERN 2012

Table of Contents

1 PREFACE ......................................................................................................................................................................... 6

About this Version.............................................................................................................................................................6What You Will Find in this Guide......................................................................................................................................6

Service..........................................................................................................................................................................7Service Oriented Architecture (SOA)..............................................................................................................................7For the SOA for Web Services Pattern 2012...................................................................................................................8Web Services in the Pattern...........................................................................................................................................9

2 WEB SERVICES PATTERN OVERVIEW .................................................................................................................. 10

Benefits, Features and Usage............................................................................................................................................10SOA for Web Services Pattern Benefits and Features ...................................................................................................10Benefits.......................................................................................................................................................................10Implementation Methodology.......................................................................................................................................11Communication Style...................................................................................................................................................11

Standards.........................................................................................................................................................................12Usages.............................................................................................................................................................................13

3 SOA ROADMAP/BILL OF MATERIAL ..................................................................................................................... 18

4 PATTERN ARCHITECTURE DETAILS .................................................................................................................... 21

Logical Architecture........................................................................................................................................................21Logical Architecture Walkthrough...................................................................................................................................22DataPower Logical Architecture.......................................................................................................................................27

5 WEB SERVICES DESIGN GUIDELINES ................................................................................................................... 29

Ford Service Architecture.................................................................................................................................................29Service Design Principles.................................................................................................................................................30

Boundaries Are Explicit...............................................................................................................................................30Services are Autonomous.............................................................................................................................................30Share Interface, Not Implementation............................................................................................................................30Interfaces are Resilient................................................................................................................................................30Design for Reuse.........................................................................................................................................................30Standards First............................................................................................................................................................31Metadata is a First-Class Citizen.................................................................................................................................31Exploit Intermediation When Appropriate....................................................................................................................31

Service Modeling.............................................................................................................................................................32Service Model .............................................................................................................................................................32

Metadata – XML Schema and WSDL..............................................................................................................................33XML Schema...............................................................................................................................................................33Web Services Description Language (WSDL)...............................................................................................................33

SOA COE ADS / DNARANJ2 Page ii of 59 Date Issued: 03/31/2007GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Chapter

1


Exception Handling.........................................................................................................................................................38SOAP Faults...............................................................................................................................................................38WSDL Faults...............................................................................................................................................................38

Orchestration...................................................................................................................................................................38Service Orchestration..................................................................................................................................................38Process Orchestration.................................................................................................................................................38

Service Mediation............................................................................................................................................................39Protocol Mediation......................................................................................................................................................39Message Mediation.....................................................................................................................................................39

WS-I Compliance............................................................................................................................................................39What are WS-I Profiles?..............................................................................................................................................39Current WS-I Profiles..................................................................................................................................................39WS-I Profile Compliance.............................................................................................................................................40

Versioning, Loose Coupling & Open Content Models.......................................................................................................40Service Versioning.......................................................................................................................................................40

Security...........................................................................................................................................................................41Internal Authentication................................................................................................................................................41External Authentication...............................................................................................................................................41Other Security Considerations.....................................................................................................................................43

Service Hosting in SharePoint..........................................................................................................................................43Services and Service Metadata.........................................................................................................................................43

6 SOA WEB SERVICES GOVERNANCE ...................................................................................................................... 44

What is SOA Web Services Governance?.........................................................................................................................44Why Ford needs Web Services Governance......................................................................................................................44Summary of Lifecycle Process for Web Services..............................................................................................................44Roles and Responsibilities ...............................................................................................................................................46Highlight of Key Process Steps........................................................................................................................................46

Service Identification and Architecture Assessment.......................................................................................................47Service Registration.....................................................................................................................................................47Service Interface Review and Approval........................................................................................................................47Service Certification and Rating...................................................................................................................................47

SOA Governance Checkpoints.........................................................................................................................................48Touch Points with SEER Estimation.............................................................................................................................48Touch Points with EAA................................................................................................................................................48Touch Points with SDM...............................................................................................................................................48Mediation Process.......................................................................................................................................................49

Governance Artifacts.......................................................................................................................................................49Service Registry Entry Data.........................................................................................................................................49XML Schema and XML Schema Specification..............................................................................................................50WSDL.........................................................................................................................................................................50UML Models...............................................................................................................................................................50Process Models...........................................................................................................................................................51Service Level Agreement (SLA) ...................................................................................................................................51

Governance Technologies................................................................................................................................................51Service Registry Repository.........................................................................................................................................52Integration of the RR and DataPower..........................................................................................................................53

SOA COE ADS / DNARANJ2 Page iii of 59 Date Issued: 03/31/2007GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Chapter

1


Monitoring..................................................................................................................................................................53Future State.................................................................................................................................................................54

7 REFERENCES .............................................................................................................................................................. 55

8 CONTACTS .................................................................................................................................................................. 59

SOA COE ADS / DNARANJ2 Page iv of 59 Date Issued: 03/31/2007GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Chapter

1


1 Preface

About this Version

This is the fourth version of the Service Oriented Architecture (SOA) for Web Services Pattern. This pattern documents products and components that are standard for 2012, as well as the latest design standards and guidelines.

The governance process has final authority of appropriate use of this and other patterns. Refer to the parent document, Architecture Patterns, for more information on principles, releasing strategy, and governance for Architecture Patterns. Please refer to the "References" section of this document when looking for the location of documents referenced in this pattern.

What You Will Find in this Guide• A general description of SOA and its uses in this pattern.• Logical application architecture supported by the pattern.• Components and product standards that make up the pattern.• Design principles, guidelines, and best practices for building SOA enabled systems.• A description of SOA governance and the process for registering SOA Web services.

For Information About: Refer to:

Architecture Management Architecture Management Guidebook

Transaction Pattern Guide to Transaction Pattern 2011

Information Architecture Architecture Strategy for Information

Interoperability Guide to Interoperability

Service Architecture Specification for Ford Enterprise API

Creating Web services for the Transaction Pattern

Java Center of Excellence website

Glossary of Terms Architecture Management Glossary

Table 1 – Further Information

SOA COE ADS / DNARANJ2 of 59 Date Issued: 03/31/2007GIS1 Item Number: 25.01 Date Revised: 11/26/2012GIS2 Classification: Proprietary Retention Start Date: 12/01/2012

Chapter

1


Audience

This document is for Information Technology and Business professionals responsible for identifying, specifying and implementing projects containing SOA concepts and Web services technology components.

Service

A Service, or Software Service, is a set of related capabilities that exist as physically independent software and can be used by applications via remote access.

Service Oriented Architecture (SOA)

An SOA is a software architecture design that uses loosely coupled software services to support business processes and software user requirements. Resources on a network in an SOA environment are made available as independent services that can be accessed without knowledge of their underlying platform implementation.

The architecture is not technology specific. It may be implemented using a range of technologies including Plain Old Java Object (POJO), Representational State Transfer (REST), Remote Procedure Call (RPC), Distributed Component Object Model (DCOM), Common Object Request Broker Architecture (CORBA), Enterprise Application Integration (EAI)) Adaptors, or Web services. SOA can utilize one of these protocols and, for example, might use a file system mechanism to communicate data conforming to a defined interface specification between processes conforming to the SOA concept. The key is independent services with defined interfaces that can be called to perform their tasks in a standard way, without the service having foreknowledge of the calling application, and without the application requiring knowledge of how the service actually performs its tasks.

Jorge Cardosa et al broaden the definition to include SOA as "a style of information systems architecture that enables the creation of applications that are built by combining loosely coupled and interoperable services."1 To interoperate, these services use a formal "contract", or WSDL file, which are platform and programming language independent because their interface definition abstracts the implementation details of the service. Services written in C# running on .NET platforms and services written in Java running on J2EE platforms, for example, can be consumed by a common composite application. Applications running on either platform can consume services running on the other as Web services, which facilitates reuse.

1 Cardoso, Jorge; Sheth, Amit P., Eds., "Foreword", Semantic Web Services, Processes and Applications, Springer Science + Business Media, 2006


Chapter

1


The Organization for the Advancement of Structured Information Standards (OASIS), an international consortium with more 5,000 participants from 600 companies worldwide, drives development and adoption of e-business standards, defines SOA as:

"SOA is a paradigm for organizing and utilizing distributed capabilities that may be under the control of different ownership domains. It provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations."

To enhance the definition for Web services we must clarify the context of discovery, interaction, capabilities and expectations.

For the SOA for Web Services Pattern 2012

Discovery – Identifying a Web service. Either by publishing or consuming a Web service, the discovery phase is invoked. The method for discovering Web services is via Ford Re-usable Asset Registry Repository (RR), whose underlying implementation is the IBM WebSphere Service Registry and Repository (WSRR). The RR identifies services and their respective Web Services Description Language (WSDL) file.

Interaction – Means of invoking the Web service and receiving the response. The Web service's messaging parameters are described within the WSDL file. The interaction is made possible by adhering to the eXtensible Markup Language (XML) message format and then encapsulating that message within a Simple Object Access Protocol (SOAP) Message (also XML). The SOAP Message is used as the message transport over HTTP/HTTPS.

Capabilities – Description of what the Web services can perform and provide. This is again described by the WSDL file and the XML Message Schema required for both sending and receiving messages. The Schema identifies inputs and outputs for the Web services.

Expectations – Description of the type of Web service that will be exposed or consumed via HTTP/HTTPS. The WSDL in conjunction with the XML Message Schema describe the Web service. Web services are inherently synchronous in behavior, which ultimately results in a request-response paradigm. This paradigm can be broken into two units of interaction.

1. The Web service can accept the request and reply back with a formatted XML message as defined in the WSDL and associated XML Schema (Synchronous Request-Response Message).

2. The Web service can just send back an acknowledgement (HTTP 200 OK) that it received the XML Message (Synchronous Request) and it will process it later. Service Level Agreements (SLA's) can also be used to meet certain expectations, but SLA's are at the application level and not the actual service itself.

To summarize the concepts:

Discovery – Re-usable Asset Registry Repository (RR) exposes Web services and their interfaces, also known as WSDLs.


Chapter

1


Interaction – The SOAP Message sends and receives the XML Message to the Web service.

Capabilities – The XML Schemas define the XML Messages for use within the SOAP Messages.

Expectations – The response from the Web service – either an XML Message with data or just an acknowledgement that the services were consumed.

Web Services in the Pattern

Identifying a Web service. Either by publishing or consuming a Web service,


Chapter

1


2 Web Services Pattern Overview

Benefits, Features and Usage

This section gives an introduction and a high-level overview of features and benefits of the SOA for Web Services Pattern.

SOA for Web Services Pattern Benefits and Features

SOA Web services are a stack of Industry standards that describe service-oriented, component-based application architectures. They provide a distributed computing technology for revealing application business services on the Internet or Intranet using open and standards-based XML protocols and formats. XML protocols make Web services platform-, language-, and vendor-independent, and are ideal as enterprise solutions.

Web services eliminate the interoperability issues of existing solutions, such as CORBA and DCOM, by leveraging open Internet standards - Web Services Description Language (WSDL - to describe), Universal Description, Discovery and Integration (UDDI - to advertise and syndicate), Simple Object Access Protocol (SOAP - to communicate).

This pattern's architecture is based upon changing current implementations of IT projects for the business. This implementation evolution allows the business to expose processes or rules to be consumed by others, without the consumer having to understand the actual implementation of the provider's business service.

Benefits

Reduce Integration Expense - implementing loosely-coupled integration approaches can reduce complexity and cost of integrating and managing distributed computing environments. Moving to standards-based interfaces, such as Web services, reduces integration costs, but the real win is replacing multiple function calls at a fine level of granularity with coarser-grained, loosely coupled services that handle a wider range of interactions more flexibly than Application Program Interface (API)-based integration.

Increase Asset Reuse - one of the most important benefits of SOA is that Ford can create new business processes and composite applications from existing services. As Ford and its suppliers create new services they can in turn reuse these services for new composite applications. Ford can realize significant return on investment (ROI) from their composite application development investment. As a result, as Ford builds and reuses an increasing number of services, the economics of composite application development that leverages SOA improve over time.

Increase Business Agility - increasing business agility is a compelling benefit of SOA, and the most difficult to quantify. Integration simplification and reuse improvements are technology-centric benefits, but business users also demand greater flexibility from IT.


Chapter

2


Rather than creating requirements that may take IT months to develop, business users want immediate control over their operations so that they can make rapid changes to their businesses as market forces change. The resulting business return from an SOA investment will be dramatic improvements in business efficiencies, as well as the ability for Ford to embed supplier business processes inside their operations, or embed Ford business processes into their suppliers' or business partners' operations.

Reduce Business Risk - implementing SOA to control Ford and its suppliers' business processes allows business process and data reuse. By eliminating duplicate services and utilizing well defined business service interfaces, Ford can reduce application integration complexity, which also reduces business risks associated with data privacy, incorrect usage of data, and inappropriate access to data.

Implementation Methodology

SOA for Web Services Pattern ranges across a concise set of implementation methods:

Context Pattern ApplicabilityB2B (Business to

Business)Point to Point Exposure

or viaEnterprise Service Bus (ESB)

Exposes functionality outside of Ford Domain

A2A (Application to Application)

Point to Point Exposureor via

Enterprise Service Bus (ESB)

Exposes functionality inside of Ford Domain

SaaS (Software as a Service)

Point to Point Exposureor via ESB?

Exposes externally hosted functionality inside the Ford

Domain

Table 2 – SOA Implementation Methods

Communication Style

The mode or style of Web service communication is a way in which service provider and consumer communicates. There are two distinguished communication styles for Web services: synchronous and asynchronous.

With synchronous services, a consumer invokes a request on a service and then suspends its processing while it waits for a response from the service.

With asynchronous services, a consumer initiates a request on a service, the service provider receives the request and recognizes the receipt by sending an acknowledgement back, and the consumer then resumes its processing without waiting for the processing result from the service. The service provider processes the request asynchronously. When it fulfills the request, the service provider can send its response to the consumer via callback mechanism. The consumer can also periodically check the status of its request via polling mechanism. Once the consumer retrieves the response, it proceeds with its processing.


Chapter

2


Publish-Subscribe and Store-Forward are two common messaging patterns that provide unique, distinguished features in message exchanging. Publish-Subscribe enables a sender to publish its data (notification, event, etc.) once and multiple subscribers to receive the published data. Store-Forward helps improve messaging reliability by storing the request first and then forwarding it to the final destination for processing. When used with Web services, the messaging patterns result in asynchronous Web service communication.

The communication styles and their applicability are summarized in the following table.

Style ApplicabilitySynchronous Request,

Request-ResponseAsynchronous Request-Acknowledgement, with Asynchronous Response,

Publish-Subscribe,Store-Forward

Table 3 – Web Services Communication Styles

StandardsFord SOA for Web Services Pattern 2012 is built on the following standards and their implementations:

WS-I Basic Profile 1.1/1.2

http://www.ws-i.org/Profiles/BasicProfile-1.1.htmlhttp://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html

WS-I Basic Security Profile 1.0/1.1

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.htmlhttp://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html

SOAP 1.1 http://www.w3.org/TR/2000/NOTE-SOAP-20000508/WSDL 1.1 http://www.w3.org/TR/2001/NOTE-wsdl-20010315WS-I Reliable Secure Profile 1.0

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=reliablesecure

WS-Addressing http://www.w3.org/Submission/ws-addressing/Message Transfer Optimization Mechanism (MTOM) v1.2

http://www.w3.org/TR/soap12-mtom/

WS-ReliableMessaging v1.1

http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf

WS-SecureConversation http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-spec-cd-01.pdf

WS-AtomicTransaction v1.0

http://www.oasis-open.org/committees/download.php/15719/WS-AT%20Working%20Draft.pdf


Chapter

2




http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/ws-secureconversation-1.3-spec-cd-01.pdf





http://www.w3.org/TR/soap12-mtom/

http://www.w3.org/Submission/ws-addressing/



http://www.w3.org/TR/2001/NOTE-wsdl-20010315

http://www.w3.org/TR/2000/NOTE-SOAP-20000508/

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.1.html

http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html

http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html

http://www.ws-i.org/Profiles/BasicProfile-1.2-2010-11-09.html

http://www.ws-i.org/Profiles/BasicProfile-1.1.html


WS-Policy v1.2 http://www.w3.org/Submission/WS-Policy/

Table 4 – SOA Web Services Standards

The following is a list of industry specifications that are supplemental to the standards listed above. Some of the applications or use cases are built on the following standards and their implementations.

SOAP 1.2 http://www.w3.org/TR/soap12-part1/UDDI 3.0 http://uddi.org/pubs/uddi_v3.htmWS-BPEL v2.0 http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-

OS.htmlSAML v1.1/2.0 token format aspect; federated identity (supplemental standards)

http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.ziphttp://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

XACML v1.0 for authorization (aps)

http://www.oasis-open.org/committees/download.php/2406/oasis-xacml-1.0.pdf

WS-Trust v1.3 http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.pdf

WS-Federation v1.1 http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf

WS-MetadataExchange v1.1

http://specs.xmlsoap.org/ws/2004/09/mex/WS-MetadataExchange.pdf

Table 5 – Supplemental Specifications

UsagesSOA Web Implementation Methodology usage is explained in more detail.

Business to Business (B2B) – A Web service that consumes or exposes functionality outside of the Enterprise Domain.

• Characteristics: B2B is the process of coordination of information among businesses and their information systems, enabling cross-enterprise business applications such as collaborative e-commerce, collaborative networks, supply chain management (SCM), and customer relationship management (CRM) across the Internet. The service requires a high level of security, which may involve digital signatures and encryption as described within the WS-Basic Security Profile 1.0 standard.

• Key differentiators from other patterns: It exposes or consumes Web services


Chapter

2



http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf

http://specs.xmlsoap.org/ws/2006/12/federation/ws-federation.pdf

http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.pdf

http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust-1.3-spec-cd-01.pdf




http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip

http://www.oasis-open.org/committees/download.php/3400/oasis-sstc-saml-1.1-pdf-xsd.zip



http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html

http://uddi.org/pubs/uddi_v3.htm

http://www.w3.org/TR/soap12-part1/

http://www.w3.org/Submission/WS-Policy/


to applications outside of the Ford Enterprise Domain.

• B2B example: an external partner processes payroll. The data is packaged in a SOAP message with a digital signature, and is then encrypted for secure Web service consumption. The service responds back with a response that the message was scheduled for processing on the next business day. The response is signed and encrypted.

Application to Application (A2A) – A Web service that exposes functionality within the Application and/or Enterprise Domain.

• Characteristics: A2A Web services expose or consume atomic business processes, OR expose or consume composite business services, which are multiple atomic services. A2A space may require the same high level of security as the B2B Pattern. This may occur if the services are exposed or consumed across internal domains within Ford.

• Key differentiators from other patterns: It exposes or consumes a Web service to other applications within the domain or the enterprise.

• A2A example: A common routine used repeatedly throughout multiple applications of the Domain or the Enterprise. A VIN Number Lookup Service which translates the 17 Character VIN Number into Region, Country, Manufacturer, Model Specific, Check Digit, Year, Assembly Plant and Serial number.


Chapter

2


Web service communication styles are explained in more detail.


Software as a Service (SaaS) – A Web service that exposes external functionality Inside the Enterprise Domain.

Software as a Service (SaaS) is an alternate form of IT services delivery. The generally accepted definition of SaaS is software that is owned, delivered, and managed remotely by an external provider(s). The SaaS vendor has responsibility for the infrastructure and application. key attributes include:

• Vendor responsibilities for infrastructure and application plan, build, and operate.

• Customer accesses the service over the Internet, typically via a web browser.• Cost structure is usually a subscription model (pay per use.)• It is an alternative IT services delivery model that can be beneficial in the right

applications, possibly providing lower costs and quicker time-to-launch.

Chapter

2


Synchronous – A consumer sends a request and receives the response synchronously.

• Characteristics: Synchronous messaging can be accomplished in two fashions. The service can be consumed and the calling application, i.e. service consumer, may wait for the response message and its contents, OR the response may be an immediate HTTP 200 OK response, without a message being sent back to the consumer.

• Key differentiators from other patterns: The characteristics of being synchronous are that the service consumer blocks and waits for the response or acknowledgement. This is a basic foundation for building Web service interactions between applications.

• Synchronous example – wait for message reply: A credit card client - e-commerce application at checkout time - invokes a credit card service with credit card details and then waits for approval or denial of the credit card transaction. The client cannot continue its processing until the transaction completes, and obtaining credit approval is a prerequisite to completing the transaction.


Chapter

2


Asynchronous – A consumer sends a request. The consumer receives the response when the request is fulfilled at a later time.

• Characteristics: Asynchronous messaging can be accomplished by using callback method implementation of Web services. The service will recognize a request with acknowledgement back to the consumer and the caller proceeds through its process. When response is available, a consumer callback method will be invoked with a response message for the original request.

• Key differentiators from other patterns: With this communication style, consumer and provider agree upon the callback method, which is defined in the service contract. For instance, use of "ReplyTo" and "FaultTo" of WS-Addressing to specify callback endpoints in service requests; or implementing callback as a Web service hosted on the consumer side. The callback will be called upon by the service provider when response is available. Request and response are often mapped through some form of correlation ID defined by the service interface specification.

Another way for a consumer to get its result back is to use the polling mechanism. The consumer can periodically check the status of its request by calling a different service operation or using a different interface.

• Asynchronous example: BOM Search service takes search criteria and queries back systems to return information about Part and Part Usage to service consumers. The service has been implemented as asynchronous Web service. A service consumer does not wait for its request to complete. Service provider processes the request asynchronously. Once it completes the processing, the provider invokes the specified callback method to inform the consumer with processing result.


Chapter

2


3 SOA Roadmap/Bill of MaterialThe roadmap describes our current technology state and future direction for SOA Web services components and technologies. See the legend at the bottom of the roadmap to understand the coloring and lifecycle status of each component. This is a current best assessment for future direction. The roadmap assessment is dependent upon available funding, business alignment, and technology maturity.

Starting in 2011, SOA Web Services Roadmap has also been kept as a Wiki page stored at SharePoint site. Please click SOA BOM Roadmap to view the current version roadmap.

Figure 1 – SOA Web Services Roadmap

Components and technology of the SOA Web Services Roadmap are grouped into four sections: Governance, Modeling and Design, Implementation and Testing, and Run Time.


Chapter

3

https://comm.sp.ford.com/sites/soa/SOA_WebServicesPattern/Wiki%20Pages/SOA%20BOM%20Roadmap%202011.aspx


• Governance covers SOA service governance components and technology, which are grouped as two subsections: Registry and Repository, and Standards.

o Registry and Repository covers tools that are used in SOA Web services governance.

o Standards covers Web services related industry standards that are to be complied with at Ford.

• Modeling and Design covers service modeling and design tools and design time guides and processes. It contains three subsections: Modeling and Design Guides, Modeling and Design Tools, and Portfolio Modeling.

o Modeling and Design Guides covers best practices in or related to service modeling and design.

o Modeling and Design Tools covers integration-centric BPM tools and general services especially Web services tools in the design time.

o Portfolio Modeling covers Business Process Analysis (BPA) tooling for Ford enterprise application portfolio management.

• Implementation and Testing covers guides and tools in service implementation and testing. It contains two subsections: Guides and Tools.

o Guides covers best practices in application architecture and service realization that are used to guide project teams in service implementation and testing.

o Tools cover various implementation and testing tools that are used in service implementation and testing.

• Run Time covers guides and environment for services in the runtime, which are grouped as five subsections: Guides, Mediation Layer, Execution Layer, Service Security and Service Management.

o Guides covers the standards and best practices that are applicable to Web services execution and runtime infrastructure.

o Mediation Layer covers service mediation infrastructure in the runtime, which provides service virtualization, messaging transformation, and routing.

o Execution Layer covers service orchestration and integration infrastructure and Web services underlying runtime infrastructure pattern for Web services.

o Service Security covers Web services authentication and authorization tools, XML messaging threat protection, and cryptographic acceleration appliance.


Chapter

3


o Service Management covers Web services monitoring and management tools.


Chapter

3


4 Pattern Architecture DetailsThe following diagram and narrative represent the overall logical architecture view of the SOA for Web Services Pattern. It is intended to separate the standards-based Web services interface from services implementation, which is based upon the Ford Transaction Pattern. The SOA for Web Services Pattern also leverages Transaction Pattern's WAS legacy integration capability. Please refer to Transaction Pattern 2011 for more details.

Logical Architecture

Starting in 2011, the logical architecture diagram has also been kept as a Wiki page stored at SharePoint site. Please click Pattern Logical Architecture to view the current version diagram.

Figure 2 – SOA for Web Services Pattern 2012 Logical Architecture


Chapter

4

https://comm.sp.ford.com/sites/soa/SOA_WebServicesPattern/Wiki%20Pages/Logical%20Architecture.aspx


Logical Architecture WalkthroughThis architecture walkthrough corresponds to the numbering in the linked diagram above:

1. Web Services Consumer/Provider – A software module that requires or responds to request/response or one-way Web services functionality over the Internet/Intranet. At design time, the provider publishes the service description and the consumer looks up the published service description in the service registry repository, following the registration and governance process (See the "SOA Web Services Governance Process" section for details). At runtime, the consumer requests the service, and the provider responds to the request based upon information contained in the WSDL. The consumer and the provider will comply with appropriate Web services standards. Please refer to the "Web Services Design Guidelines" section for details.

There are three different scenarios where a Web service consumer accesses a Web service provider depending on where the consumer and provider reside in the network.

• Ford internal service consumers accessing external service providers

This scenario is characterized as outbound Web service invocation (or outbound messaging).

• External service consumers accessing Ford internal service providers

This scenario is characterized as inbound Web service invocation (or inbound messaging). The internally provided Web services are often called external facing Web services.

• Ford internal service consumers accessing Ford internal service providers

This access can be referred to as internal service invocation or messaging, and is the most common scenario for service invocation at Ford. The services are sometimes called internal facing Web services.

The three different service accessing methods imply different security handling requirements and solutions to authenticate service requests and secure message exchanges. Please refer to “XML Gateway: DataPower” and “Service Security” of the current section for additional information.

2. Web Service Mediation – Two infrastructure components can be used to support Web services intermediary functions.

• XML Gateway: DataPower

XML Appliance

As an XML appliance, DataPower mediates between the Web service consumer and Web service provider interface and provides the following services:

a. XML firewall or XML proxy at the DMZ.


Chapter

4


b. XML gateway for XML content-based routing, schema validation, protocol mediation, and message transformation.

c. XML messaging cryptographic (digital signature and encryption/decryption) process acceleration.

Use of DataPower

The following summarizes the DataPower usage.

a. Securing Web services communications with external partners to comply with Confidentiality and Integrity security requirement.

i. Outbound Web service invocation

• For external Web services that support WS-Security, use DataPower’s WS-Security support to secure message exchanges over the public internet.

This should be the preferred choice.

• For external Web services that do not support WS-Security, use DataPower’s bidirectional SSL to secure message exchanges over the public internet.

• In situations where business requirement has low rating on Confidentiality and Integrity, or external Web services do not use standard security implementation, use of DataPower is not recommended.

ii. Inbound Web service invocation

• The preferred choice is to use DataPower’s WS-Security support to secure message exchanges over the public internet.

• If WS-Security cannot be supported by external consumers, use DataPower’s bidirectional SSL to secure message exchanges over the public internet.

b. Web services mediation functions

i. Message mediation between service consumer and provider

ii. Protocol mediation between endpoints using different protocols

iii. Service orchestration that implements stateless micro-flow activities by invoking synchronous Web services

Please refer to the SOA Infrastructure website for details about DataPower.

• BizTalk ESB


Chapter

4


Microsoft BizTalk provides ESB functions such as Store and Forward, Publish and Subscribe, Service Orchestration, and Event Processing, which can be used when project teams implement Web services based solution.

The following is a summary of the functions and their availability status at Ford.

a. Store and Forward – receiving and persisting messages then forwarding them to the specified destination for processing if the destination is alive. The function is available and supported.

b. At the time of writing, the following two functions are not supported; but can be made available to support business need.

i. Publish and Subscribe – publishing messages to multiple downstream systems (i.e. subscribers).

ii. Service Orchestration – orchestrating stateless micro-flow activities.

c. At the time of writing, the following two functions are not supported due to the infrastructure constraint at Ford.

i. Process Orchestration – orchestrating long-running, stateful process or workflow (a.k.a micro-workflow).

ii. Event Processing – supporting Complex Event Processing (CEP).

Please refer to the SOA Infrastructure website for details about the BizTalk ESB functions and their most recent availability information.

3. Web Services Consumer/Provider Interface – A software module inside the WebSphere Application Server (WAS) that exposes functionality. In a typical "industry-view" scenario, a service consumer/provider interface hosts a network-accessible software module. At design time, the service provider interface defines and publishes the service description and message structure for service consumers in the service registry repository following the registration and governance process (section 6). Standards for service description and message structure are WSDL and XML Schema Definition (XSD).

a. The Web service provider interface can invoke business logic implementation through a WAS component API.

b. The Web service consumer/provider interface should comply with Web services standards, including WS-I Basic Profile 1.1 and WS-I Basic Security Profile 1.0. Please refer to the "Web Services Design Guidelines" section for details.

4. WAS components – WAS components within the WebSphere Application Server (WAS) implement business logic and can run in separate Java Virtual Machines (JVMs) or separate WAS servers. Invocation is through a Java EE API provided by WAS components.


Chapter

4


5. Ford Java Framework (FJF) / Web Services Core (WsCore) Framework – WsCore framework is a lifecycle Web services JAX-WS framework and is part of FJF. WsCore offers the following capabilities:

a. Web Service Lifecycle Support – Provides support for runtime lifecycle process of Web service request/response with extensible hooks for handling customized request validation, authorization and etc. for both Web service consumer and provider.

b. Reusable Handlers – WsCore also provides a set of reusable/extensible JAX-WS handlers that offer the capability to handle certain non-functional events such as logging, adding WSL persistent cookie or DataPower principal.

Please refer to the Java Center of Excellence documentation on WsCore framework for more details.

6. MQSeries Connectivity – Connectivity to WebSphere MQ (WMQ) for z/OS is achieved through the use of the Async Framework in the FJF. WMQ can support underline messaging persistence for Web services. Please refer to the Guide to Transaction Pattern 2011 Section II for details.

7. IMS Access – Access to IMS is achieved through the use of the Connector Framework in the FJF, which leverages an IBM IMSConnect adaptor. Please refer to the Guide to Transaction Pattern 2011 Section II for details.

8. Mainframe DB2 Access – Access to DB2 on the mainframe is done using IBM's DB2Connect. Please refer to the Guide to Transaction Pattern 2011 Section II for details.

9. SQL Server Connectivity – Connectivity to SQL Server databases is done via the Persistent Framework contained within FJF, which leverages the WAS/SQL Server JDBC driver. Please refer to the Guide to Transaction Pattern 2011 Section II for details.

10. Data Warehouse Connectivity – Access to Teradata Data Warehouse is achieved through the use of a Teradata JDBC driver. Please refer to the Guide to Transaction Pattern 2011 Section II for details.

11. Service Security – Service security components include authentication, authorization, and message integrity and confidentiality.

The security requirement for a Web service is determined by the security classification (CIA – Confidentiality, Integrity and Availability) set by business for the service function. Please refer to the CIA Table2 for more information about the security classification. Also refer to the SOA Implications to Security and Controls publication available at the SOA SOE website.

a. Authentication – WSL is Ford's current standard internal authentication mechanism. It consists of a Web server-based WSL agent and central

2 https://comm.sp.ford.com/sites/ITSecurity/process/Pages/CIATable.aspx


Chapter

4

https://comm.sp.ford.com/sites/ITSecurity/process/Pages/CIATable.aspx


authentication services. A consumer application needs to request a persistent WSL cookie from a central WSL service3. The FJF PropertyManager stores and retrieves the persistent cookie. The persistent WSL cookie must be present in an HTTP request sent by the consumer application when invoking a Web service. The FJF WsCore Cookie Handler ensures that the WSL cookie is included in every Web service request. For more details, please refer to the FJF ITCore and WsCore frameworks from the Ford Java Frameworks Web site4. For external facing Web services, message based X.509 certificate authentication is preferred. Please refer to the "Web Services Design Guidelines" section for additional information.

b. Authorization – WSL enforces course grain (URL level) access policy, using a WSL agent and WSL security policy files. EAA Security5 or Application Policy Services (APS) stores and manages finer grain security policy files. The FJF EAA Security module enables provider applications access to the authorization policy and user entitlements. For information on EAA security, please refer to EAA Security Website6 and FJF EAA security module. APS is designed to replace EAA security services. Please refer to APS API Developer Guide for more information. NOTE: DataPower is not currently integrated with EAA/APS. Message routing is based upon the pre-configured service policy. Granular authorization needs to be performed at service/application level by APS or EAA.

c. Message Integrity and Confidentiality –

i. Internal Web services communications

• For service function that requires the Integrity of CIA rating less than 3, use HTTP channel based SSL for message security. This helps achieve transaction efficiency and economy.

• For service function that requires the Integrity of CIA rating that is 3, use message based XML encryption and signature for message security.

ii. Inbound and outbound Web services communications

Use message based XML encryption and signature for message security.

OASIS standard Web Services Security 1.0, which is part of WS-I Basic Security Profile 1.0, is supported by the Guide to Transaction Pattern 2011.

d. XML Threat Protection – With the advent of XML messaging, new security threats are appearing, such as XML denial of service (XDOS) and Xpath injection. DataPower Gateway appliance is used to counter XML threats against Ford external facing Web services. It also provides hardware based message signing and encryption, offloading the cryptographic functions from each and every application.

3 https://www.cns.ford.com/wsl/pcookie.asp 4 https://www.tc2.ford.com/ts/JCOE/Sections/Frameworks.aspx 5 EAA stands for Enterprise Authentication and Authorization6 http://www.eaa.ford.com/


Chapter

4

http://www.eaa.ford.com/

https://www.tc2.ford.com/ts/JCOE/Sections/Frameworks.aspx

https://www.cns.ford.com/wsl/pcookie.asp


12. Service Governance – The service registry repository is implemented through the IBM WebSphere Service Registry and Repository (WSRR) tool. The registry repository stores Web services versioned artifacts such as WSDLs and supports service lifecycle management and service certification process. See the "SOA Web Services Governance Process" section for details.

13. Logging – The DataPower appliance has no local hard drive for storage. The DataPower logging uses Global NetOps HA (high availability) syslog services, which provides the syslog search tool’s UI (https://log.netops.ford.com/syslogsyncDP/) dedicated for DataPower and protected by WSL.

14. Monitoring – Web services monitoring occurs through Hewlett Packard (HP) Business Availability Center (BAC). BAC is a suite of application monitoring and diagnostics tools, which includes Business Process Monitor (BPM) and SiteScope. BPM and SiteScope both collect Web services availability and performance data periodically in an agentless and active fashion. BPM runs scripted tests to simulate business transactions on a recurring basis to calculate Web services availability and response times where complex monitoring logic is required. SiteScope complements BPM for pre-built and tailored Web services monitoring for availability and performance on system infrastructure. Data is stored in the BAC repository. BAC provides a single dashboard to observe Web services monitor status and alert activity. For more information on BAC, BPM and SiteScope, please see "Governance Technologies" in the "SOA Web Services Governance Process" section.

The DataPower device monitoring occurs through HP Systems Insight Manager (SIM) and IBM Tivoli Enterprise Console (TEC), which is passive SNMP monitoring. The SIM catches the predefined DataPower SNMP traps and alerts TEC. A GIRS ticket can be issued from TEC to trigger the DataPower issue diagnostics and support processes. Support team can also be paged.

DataPower Logical ArchitectureIBM WebSphere DataPower is deployed to support both inbound Web services messaging and outbound Web services messaging. DataPower helps secure and accelerate our external facing Web service deployments while extending our SOA infrastructure. For services on the public internet, x.509 digital certificates are required for authentication, signing and encryption. For internal services on the Ford Intranet, WSL authentication is supported.

Starting in 2011, the DataPower logical deployment architecture diagram has also been kept as a Wiki page stored at SharePoint site. Please click DataPower Logical Deployment Architecture to view the current version diagram.


Chapter

4

https://comm.sp.ford.com/sites/soa/SOA_WebServicesPattern/Wiki%20Pages/Logical%20Deployment%20Diagram.aspx

https://comm.sp.ford.com/sites/soa/SOA_WebServicesPattern/Wiki%20Pages/Logical%20Deployment%20Diagram.aspx


Figure 3 – DataPower Logical Deployment Architecture


Chapter

4


5 Web Services Design GuidelinesThis section describes design principles, guidelines, standards, and best practices for building SOA enabled systems, including:

• Service Architecture

• Service Design Principles

• Service Modeling

• Metadata - XML Schema and WSDL

• Exception Handling

• Orchestration

• Service Mediation

• WS-I Compliance

• Versioning, Loose Coupling and Open Content Models

• Security

• Service Hosting in SharePoint

• Services and Service Metadata

Ford Service ArchitectureFord Service Architecture provides a framework for building enterprise services at Ford. The purpose of the service architecture is to guide project teams during service development and enable the creation of consistent, reusable, extensible, standard-compliant services and related design artifacts published to the RR, i.e. Re-usable Asset Registry Repository.

Ford Service Architecture supports most of the Architecture Management's enterprise Architecture Principles, particularly the Commonality Principle, Virtual Enterprise Principle, Organization Principle, Point to Point Principle, Phasing Principle, and Ownership Principle.

The ultimate goals of service architecture are to help maximize service asset reuse, reduce application fragmentation, and reduce system complexity, which will consequently allow us to better support constant changes in the business and technology and realize the long-term benefits of SOA.

Please refer to the Specification for Ford Enterprise API for details.


Chapter

5


Service Design PrinciplesFollowing are key principles that govern service-oriented design7.

Boundaries Are Explicit

Although current tooling can make calling a service appear as invoking a local object method, an explicit boundary is crossed that must be acknowledged. Crossing the service boundary may be an expensive operation. Only well-defined messages may cross this boundary. No assumptions are made about what happens to a message after it leaves the boundary of a requester and before it enters the boundary of a provider; the message may be routed through multiple intermediaries or may be signed or encrypted, etc.

Services are Autonomous

Services behave as independent entities. A service-oriented environment has no presiding authority. Services deployment, versioning, and management happen independently. The topology in which a service executes can and will evolve. The service should expect that other associated consumed services can and will fail, and that it can and will receive malformed or malicious messages. Service providers should build services to not fail, using (for example) redundancy and failover techniques.

Share Interface, Not Implementation

A service publishes its interface contract in the form of a WSDL document. Only the WSDL (and policy information) need be shared between providers and consumers to enable communication. No assumptions are made about how each partner implements the interface. Implementation artifacts are usually generated from the WSDL by platform specific tooling. Adherence to published interfaces (and not using shared implementations) greatly reduces coupling between consumers and providers.

Interfaces are Resilient

Service interfaces are designed to be coarse grained (and hence more stable) and to survive minor version changes and revisions. Thoughtful XML Schema design with judicious use of extensibility constructs (e.g. use of open content models with type substitution and element substitution) is important to achieve stable, resilient interfaces. See the Guide to XML Schema Design for information on open content models.

Design for Reuse

The value of SOA comes from reusing services and, thus, leveraging investments made into existing assets. Basing service interfaces on established enterprise information models is one way of achieving greater reusability (see the Enterprise Information Models).

7 Some of the principles in this section are based upon the article Service Orientation and Its Role in Your Connected Systems Strategy


Chapter

5


Standards First

Adherence to standards is important to Web services based architecture, because standards-based tooling can be exploited for greater productivity and easier interoperability. While a particular problem may be solved in many different ways, it is necessary to go the extra mile to find applicable standards and to conform to such standards even if it requires some custom effort (in case tooling is still evolving, for example). While a custom effort is not always a justifiable investment, it must be given due consideration for long-term benefits.

Metadata is a First-Class Citizen

Increasingly, aspects of service will be specified by standards-based metadata. Metadata such as WSDL and XML Schema is already well-established and well-supported for defining service interfaces. In the near future, WS-Policy based languages such as WS-SecurityPolicy, WS-Reliable Messaging policy assertions, and others will describe additional capabilities of service endpoints. Further, protocols such as WS-MetadataExchange will allow tooling to easily consume service metadata and configure service consumers correctly for calling a particular service.

Custom metadata also may be developed as WS-Policy compatible assertions for expressing intra-company or business partner specific policies.

Appropriate diligence must be given to service metadata. This could be as simple as ensuring consistent naming conventions to storing WSDL and Schemas in central repositories, governed by well-defined processes.

Exploit Intermediation When Appropriate

Intermediation is a key feature of Web services based SOA. This is essentially the use of SOAP headers and platform-specific handlers for abstracting functionality out of service implementations and putting it into declarative or configuration-driven components. Consider using custom SOAP headers (in a standards-cognizant manner) and custom handlers as part of any significant services-oriented design effort.

Existing Web services standards (i.e., WS-Security, WS-Addressing, WS-ReliableMessaging, etc.) use Intermediation extensively. This pattern is equally well-applicable to custom SOA endeavors. An example of such an approach would be to use a WSL token as a custom WS-Security binary token. A handler on the consumer side inserts the custom token in the outgoing message and another handler on the service side validates the token embedded in an incoming message. Individual services and consumers do not have to be explicitly written for WSL authentication, which can be easily achieved by ‘dropping’ in the handlers at configuration time.

Note that SOAP intermediaries may be independent servers (or devices such XML gateways), or handlers running in-process with a service or a consumer.


Chapter

5


Service Modeling

This section describes techniques and guidelines for modeling services and its contextual processes in Unified Modeling Language (UML).

Service Model

Figure 4 – Service Model Example

The above diagram depicts a service model of a Parts Catalog service. To reflect the semantics of a Web service in UML use the following guidelines:

• Model the service as a UML interface

• Each operation must always have one and only one input parameter. Create a dummy or wrapper class if one does not naturally occur. For example the operation GetPartList() does not require any parameters but to implement it as a Web service a parameter – which may be empty – is required. To reflect this, the wrapper class GetPartList was created.

• If a service operation takes multiple input parameters, create a wrapper class and make all the input parameters the attributes of that wrapper class. Make the wrapper class the sole input parameter of the operation. Note this technique reflects the 'document' approach to Web service interfaces as opposed to the RPC (remote procedure call) approach.


Chapter

5


Use of 'Document / Literal' Web services ensures that data is only modeled in XML Schema. RPC Web services have the data model split between WSDL messages and XML Schema which is harder to manage.

• Each operation may optionally have one result or output parameter.

• Show the dependency between each operation and its input and output (if any) via UML Dependency Associations suitably labeled to reflect the relationship.

• The rest of the associations between data classes should follow normal UML guidelines.

Use Activity diagrams to show how the service is / can be used in a larger context. There are no strict guidelines for the diagrams but the following is an example that you may use to document interactions with your service:

UML Activity Diagram

Figure 5 – UML Activity Diagram

Metadata – XML Schema and WSDL

XML Schema

XML Schemas establish semantics, structure, and constraints that govern the content of a particular message exchange. Please see the Guide to XML Schema Design for detailed guidance on XML Schema design.

Web Services Description Language (WSDL)

WSDL is an XML format for describing network services as a set of endpoints (or ports) operating on messages containing either document-oriented or procedure-oriented


Chapter

5


information. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints are combined into abstract endpoints (services). WSDL is extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate.

WSDL is the interface definition language for Web services. An understanding of WSDL is essential for effective use of Web services. This section assumes that the reader is familiar with the basics of XML and XML Namespaces.

WSDL has two basic parts:

1. Interface: Defines the Web services interface independent of any transport (e.g., SOAP over HTTP).

2. Binding: Defines the transport(s) that a Web service supports.

Versioning

See "Versioning, Loose Coupling & Open Content Models" later in this section.

Interface

This is the part of the WSDL that defines the abstract service interface, independent of transport or protocol.


Chapter

5


Figure 6 – Interface WSDL Logical Model

Elements

E L E M E N T D E S C R I P T I O N

Definitions Root element of a WSDL document.Types Contains all top-level XML Schemas used in the WSDL.Schema, XML Schema, global element

Schema contains an XML Schema. An XML Schema may in turn include or import other XML Schemas, which can be other embedded WSDL schemas or external schemas. An XML Schema defines many components but the only components of interest (from a WS-I compliant WSDL perspective) are global elements.

Message, Part A message is a named reference to a schema global schema element. WSDL operation elements (input, output and fault) refer to schema elements via messages.Note: The WSDL spec allows the message element to contain multiple part elements. However, WS-I Basic Profile restricts compliant WSDLs to only one part per message. Further, the part must refer to a globally defined schema element (as opposed to a schema type).

portType A grouping of WSDL operations. A WSDL may define many port types but typically only one is defined.

Operation, input, output, fault

Input, output and fault elements all refer to messages defined in the WSDL and are grouped under a uniquely named operation element. Semantically, an operation is similar to a programming language function or method. The input message is equivalent to method input parameters; output is equivalent to return type; and fault is equivalent to exception

Table 6 – WSDL Elements


Chapter

5


Sample

<definitions xmlns=”...wsdl namespace...” targetNamespace=”urn:service” xmlns:s=”urn:service” xmlsn:sd=”urn:service/data” xmlns:xs=”...schema namespace...” xmlns:soap=”...soap wsdl binding namespace...” > <types> <xs:schema targetNampespace=”urn:service/data”> <xs:element name=”Input” type=”xs:string” /> <xs:element name=”Ouput” type=”xs:string” /> </xs:schema> </types> <message name=”InputMessage”> <part name=”parameters” element=”sd:Input” /> </message> <message name=”OutputMessage”> <part name=”parameters” element=”sd:Output” /> </message> <portType name=”servicePort”> <operation name=”DoSomething”> <input message=”s:InputMessage” /> <output message=”s:OutputMessage” /> </operation> </portType> <.... binding elements .... ><definitions>

Binding

This represents the part of the WSDL that specifies protocol and transport, via which the service interface would be accessible.

Figure 7 – WSDL Binding Logical Model


Chapter

5


Elements

E L E M E N T D E S C R I P T I O N

Definitions Root element of a WSDL document.Types Contains all top-level XML Schemas used in the WSDL.Binding, soap:binding

Binding is used to bind a portType (see the abstract WSDL diagram) to a transport. The presence of a soap:binding element means the portType is available over a SOAP transport. Currently SOAP over HTTP is the only canonical binding defined for WSDL.

Operation, soap:operation

Binding contains operation elements, corresponding to operation elements under the portType that the binding refers to. Soap:operation provides a way of attaching SOAP binding specific information to the operation.

Input, output, fault, soap:body, soap:fault

Similar to the operation element, input, output and fault elements (under binding/operation) correspond to similar elements under the relevant portType operation. Soap:body provides a way of attaching SOAP binding specific information to input and output elements, and soap:fault to fault element.

Service, port, soap:address

Service is a named grouping of ports. A port refers to a binding and provides a physical access location via the soap:address element. The soap:address element usually contains an HTTP URL to the service. At Ford the service element is restricted to contain only one port.

Table 7 – Binding Elements

Sample

<definitions xmlns=”...wsdl namespace...” targetNamespace=”urn:service” xmlns:s=”urn:service” xmlsn:sd=”urn:service/data” xmlns:xs=”...schema namespace...” xmlns:soap=”...soap wsdl binding namespace...” > <.... interface elements .... > <binding name=”soapBinding” portType=”s:servicePort” <soap:binding transport=”... soap http transport uri...” style=”document” /> <operation name=”DoSomething”> <soap:operation style=”document” soapAction=”...operation identifier uri...” /> <input> <soap:body use=”literal” /> </input> <output> <soap:body use=”literal” /> </output> </operation> </binding> <service name=”service”> <port name=”servicePort” binding=”s:soapBinding”> <soap:address location=”http://... service access point url...” /> </port> </service><definitions>


Chapter

5


Exception Handling

There are two distinct but related types of error handling in Web services: SOAP faults and WSDL faults.

SOAP Faults

SOAP faults are defined at the SOAP protocol level. These are XML messages that convey error conditions back to the caller. Typically any unhandled exceptions on the server will be returned to the caller as a SOAP fault. Most SOAP runtime engines on the caller side will convert a SOAP fault to some kind of programming language specific exception.

We recommend the use of SOAP Faults as preferred method of exception propagation between service provider and consumer.

WSDL Faults

WSDL faults are user-defined messages that are specified in the WSDL definition. The message specified in a WSDL fault is carried inside a SOAP fault wrapper when a WSDL fault is indicated by a service.

We discourage the use of WSDL faults. The overhead and tool-related interoperability issues resulted from the use of WSDL faults outweigh the benefits that WSDL faults provide.

Orchestration

Service Orchestration

Service Orchestration refers to leveraging open-standards and collaborating different services functionality to compose Business Services. It deals with tailoring the flow of Web services at a Message Level, by defining the order of execution of the exposed methods and orchestrating atomic services into business services. At Ford, the ESB is positioned as a usage pattern and ESB functions can be realized with DataPower and/or BizTalk. Both DataPower and BizTalk are essential components in the service orchestration layer, providing availability and routing of services.

Process Orchestration

Process Orchestration typically deals with messaging between various stakeholders of a Business Process i.e. Customers, Suppliers, Retailers, Partners etc. unlike Service Orchestration responsibilities which mainly focus on Web services level message flow. Process Orchestration involves creating business processes by stringing business services provided by the service orchestration layer, and including normal execution paths, decision points, exception paths and compensation paths.


Chapter

5


Please refer to the Business Process Management (BPM) website for more information.

Service Mediation

Protocol Mediation

Protocol mediation typically deals with exchanging message between endpoints that communicate using different protocols. Intermediary is used to mediate between these protocols. Some instances of protocol mediation are:

• HTTP–HTTPS: This mediation is used when a Web service is to be secured which are not secured by provider inherently.

• HTTP–MQ: This mediation is used when service requestor can only communicate through MQ whereas service provider communicates through HTTP and vice versa is also possible.

• SFTP–FTP: This mediation is used when service requestor communicates through FTP and provider only supports SFTP.

Message Mediation

Message mediation typically deals with transforming data from one form to another form.

• Transforming from one data model to another like XML-XML transformation

• Transforming form one format to another like XML-Text / XML-Binary

WS-I ComplianceWeb Services Interoperability Organization (WS-I) is the foremost body governing Web services interoperability. Adherence to WS-I guidelines is essential for minimizing interoperability issues.

What are WS-I Profiles?

WS-I guidance comes packaged as 'profiles'. Each profile is a set of clarifying guidelines and restrictions over a set of related Web services standards. For example, the WS-I Basic Profile v1.1 is a set of restrictions and clarifications over SOAP, WSDL and UDDI standards.

Current WS-I ProfilesP R O F I L E D E S C R I P T I O N

WS-I Basic Profile v1.1 Basic Web Services (SOAP, WSDL, UDDI, XML, HTTP)WS-I Basic Profile v1.2 WS-I BP v1.1 and WS-Addressing, Message Transfer


Chapter

5


Optimization Mechanism (MTOM)WS-I Basic Security Profile v1.0 Securing Web Service messages (WS-Security)

WS-I Reliable Secure Profile v1.0 Message reliability and optimized security (WS-ReliableMessaging, WS-SecureConversation).

Table 8 – WS-I Profiles

WS-I Profile Compliance

There are two relevant profiles that require consideration for Web services at Ford:

• WS-I Basic Profile v1.1

• WS-I Basic Security Profile v1.0

Any new service must, at least, support WS-I Basic Profile v1.1. Additionally, service WSDLs must be 'Document / Literal'. See the Java EE Developer’s Guide for Web Services for additional information on supporting WS-I Basic Profile. Additional information can also be found in the Web Services FAQ. More guidance regarding WS-I Basic Security Profile is provided later in this section.

Versioning, Loose Coupling & Open Content ModelsAs mentioned in our Introduction Section, a major goal of SOA is to allow for greater reuse of services. A corollary to that is to build service interfaces that support loose-coupling (i.e., the ability to revise a service interface without breaking existing clients). A significant way to achieve loose-coupling is to leverage XML Schema design patterns for open content models. Also, at some point, a service interface may be revised to deliberately break backward compatibility or to create an entirely new version for some other reason. This section provides guidelines on both of these topics.

Service Versioning

Services are designed for re-use. As re-use widens, so does the potential impact of changes. Service changes may:

• force ‘consumer’ applications to change• necessitate extensive testing• occur frequently or at short notice

Consequently, these changes can reduce the ROI of SOA and discourage adoption on an enterprise scale. A Service Versioning policy protects service consumers from disruptive


Chapter

5


change whilst recognizing service evolution is both necessary and desirable. For more information on Ford current service versioning guidelines, please refer to the Service Versioning Policy.

Schema Versioning and Open Content Models

There are two main design patterns for building open content models:

• Type Substitution.

• Element Substitution

Both are well documented in the Guide to XML Schema Design. Of the two, Type Substitution is the preferred pattern for Web services. Generally, Type Substitution works better with object oriented languages as it is somewhat object oriented in nature. An additional benefit is that it requires nothing special in terms of schema structure when defining the schema (which is not the case with Element Substitution).

Security

Internal Authentication

Web Single Logon (WSL) with SSL

For internal, Transaction Pattern hosted Web services, use Ford proprietary WSL authentication mechanism with Secure Sockets Layer (SSL).

You will require a WSL Persistent Cookie. Request the cookie from the Disaster Recovery and Data Center Security website.

See the Guide to Transaction Pattern 2011 and Java EE Developer’s Guide for Web Services for more information on how to use WSL Persistent Cookies.

External Authentication

WSL-SSL is not a suitable authentication mechanism for external facing Web services. The preferred method is to use message based security using X509 Certificates.

Message Based Security

Starting with Transaction Pattern (TP) 2008 there is a capability to utilize OASIS standard Web Services Security 1.0 to secure Web services for external access via Message based security using XML Signature and XML Encryption.


Chapter

5


Following are tooling-independent guidelines for using message based security:

• Use X509 Certificates for Security Tokens.

• Sign body and all significant headers and encrypt message body.

• Optionally, encrypt sensitive fields like SSN in message payload.

• Optionally, use uni-directional or anonymous SSL if needed to prevent eavesdropping of header data over the public internet.

• Follow message based security guidelines posted in WS-I Basic Security Profile

• The default algorithm suite should be Basic128 as outlined by OASIS WS-SecurityPolicy (see table below).

• Be aware that you are responsible for certificate management. Any changes such as installing a new certificate will require a redeployment of the application.

• Note: For additional background and guidance, please review, "Notes on Message Security and Key Management Strategy."

Basic128 Algorithm Suite

The recommend default algorithm suite for Message Based security for the current transaction pattern is Basic128 (see reference to WS-SecurityPolicy above) which consists of the following algorithms:

TYPE ALGORITHM URI

Digest SHA1 http://www.w3.org/2000/09/xmldsig#sha1

Encryption AES128 http://www.w3.org/2001/04/xmlenc#aes128-cbc

Key Transport

KwRsaOaep http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Table 9 – Basic128 Algorithm Suite

NOTE: Java EE Developer’s Guide for Web Services provides basic guidance on how to configure a service or consumer to use message based security. For more details, please see the IBM Redbook, WebSphere Version 6 Web Services Handbook Development and Deployment (chapter on "Securing Web Services") or contact the Java Center of Excellence for assistance with Rational Software Architecture (RSA) in setting up message based security.


Chapter

5


Other Security Considerations

Authorization

Use any of the existing authorization mechanisms supported by the referenced Transaction Pattern version.

Input Validation

Validation of the input message is the responsibility of the service implementer. Web services' tooling only partially validates the structure of the message. By default, full schema validation is not done. Future versions may have better support for optionally enabling full schema validation.

For additional input validation guidelines (for example, to prevent SQL Injection or other types of attacks) please use the relevant sections of the J2EE Guide to Secure Input Validation (Note: this J2EE guide is written from the point of view of a Struts developer, however the types of attacks described and some of remedial approaches are still valid for Web services input validation).

Service Hosting in SharePoint

Microsoft SharePoint supports Web services via SharePoint List interface. Essentially, any SharePoint List can be accessed as a Web service. This technology is not recommended for hosting general production use services.

SharePoint's Windows/NTLM based authentication model is not suitable for machine-to-machine interaction, because of the need to embed userids and passwords in code. Note that under Ford policy, Windows normal passwords expire every 90 days.

An example of a suitable use of this technology would be to make user-entered data available as a Web service for Office or .Net Smart Clients, where integrated Windows authentication can be easily used to access SharePoint services.

Services and Service MetadataStarting in the second quarter of 2011, the Re-usable Asset Registry Repository (RR) has been used as the service registry repository tool at Ford. The RR, whose underlying implementation is the IBM WebSphere Service Registry and Repository (WSRR), enables the management of Web services and their artifacts, and support for SOA governance.

All Web services at Ford, either consumed or provided by Ford applications, need to be registered in the RR. Please refer to the next section "SOA Web Services Governance Process" for details on service lifecycle process.


Chapter

5


6 SOA Web Services Governance

What is SOA Web Services Governance?Ford Motor Company's SOA Web services governance is made up of processes, tools, and a governance body that help us manage service-oriented architecture (SOA). Processes include service development lifecycle process, discovering and management of Web services that are in production, service mediation process, and process touchpoints with the SEER Estimate, Solution Delivery Methodology (SDM) and Enterprise Architecture Assurance (EAA). Governance tools include the Re-usable Asset Registry Repository (RR) and service monitoring software.

This section will cover high-level service identification, registration and certification process, governance artifacts, and technologies that make up Web services governance.

Today, the governance process starts with service identification, followed by services and their complementing artifacts being registered into the service registry repository, where they are managed by the SOA Center of Excellence. Future state, services will be validated against policies at runtime by SOA infrastructure components.

Why Ford needs Web Services GovernanceEffective governance is essential to the success of Ford's SOA strategy. An SOA includes many independent, self-contained moving parts – with components that are reused and manipulated. An SOA implemented without governance risks policy non-compliance, and may result in development of duplicate, incompatible services.

An SOA governance process ensures that services are built so they can be used to compose new applications, business processes and other services, and changes to them will have no or minimized impact to other consumers. Well managed services allow reuse of business functionality, increase return on investment (ROI) from capabilities these services provide, and reduced overall complexity.

SOA requires strategic planning and management of the entire service portfolio in order to expose and act upon interdependencies among services, policies, and other SOA artifacts. By giving us a better view into our Web services operations, we can articulate return on ROI and determine where improvements need to be made in order to secure a better ROI.

Summary of Lifecycle Process for Web ServicesCreating a service portfolio requires a process for developing services. At high-level, the process today consists of the following key steps:

• Identification and assessment of service opportunities

• Registration of the services in the registry repository

• Design, review and approval of service interfaces


Chapter

6


• Service realization

• Service certification and deployment

The process summary flow is show below. Please refer to <link to the process summary flow> for the most current version flow diagram.

Figure 8 – Process Summary Flow for Web Service Creation

Detail to the process shown above:


Chapter

6


• Project team identifies a service need, i.e. a service idea or service opportunity.• SOA COE reviews and assesses the service idea.• If the service idea gets funded and approved, the service will be registered in the

service registry repository.• Project team works on service interface design, and engages SOA COE / JCOE for

design related consultation to ensure the creation of right service interfaces.• Project team involves SOA COE for service interface review and approval.• Project team performs registry related tasks such as uploading WSDL and schema files.• Project team works on service realization, which includes component design, coding,

and testing.• SOA COE certifies the service.• Project team launches the service in production.• Service consumers are registered in the service registry repository.

For more detailed service lifecycle process, please refer to <link to detail process flow>.

Roles and Responsibilities The following is a list of Roles and Responsibilities that are involved in SOA Web Services governance.

SD – Creators and consumers of services (service creation and consumption)

S3 – Owners of services (service support and SLA management)

SOA COE – Governance of services (service certification, standards and best practices), and

consultation for service development

JCOE Consulting – Consultation for service development

Solution Architect – Consultation for service development

Enterprise Architect – Consultation for service development

Highlight of Key Process StepsThis segment provides high-level descriptions of key process steps in SOA Web services governance.

Please refer to the SOA Web services statement of use for more information.


Chapter

6


Service Identification and Architecture Assessment

Currently service opportunities are often identified in the context of development projects. Service Opportunity Reviews are reviews happened in early development lifecycle (i.e. E2 SEER Estimate) to identify opportunities to re-use existing services or create new ones. Service Architecture Assessment focuses on service alignment with enterprise data and process models, finding the appropriate system of record, and functional scoping; and makes recommendations accordingly. This helps avoid the development of duplicated, incompatible services.

A different approach called “Top-down Service Identification” has been researched, piloted, and is emerging.

With the top-down approach, the “top” means the scope or the context in which analysis and modeling is to be performed to identify service opportunities. The “top” could be the enterprise, though often it is more practical that the “top” is at a lower level such as a domain (i.e. line of business), a program, or a project. “Top-down Service Identification” promotes looking at a broader scope of business area than that of the current, immediate project, focusing on analysis and modeling from the top, and creating a service landscape prior to the instantiation of development projects.

The process around “Top-down Service Identification” has not been finalized at the time of writing, though it is the future state for service identification.

Service Registration

All Web services at Ford, either consumed or provided by Ford applications, need to be registered in the service registry repository.

The registered Web services are classified as one of the following three types:

• Enterprise – Suitable for re-use for more than one portfolio or line of business

• Portfolio – Suitable for re-use within a portfolio or line of business

• Application – Suitable for re-use within an application or system

Service Interface Review and Approval

Ford existing service design principles put a great emphasis on service interface. “Metadata is a First-Class Citizen”, “Interfaces are Resilient”, “Design for Reuse”, and “Standards First” are a few examples. Please refer to the Services Design Principles in Section 5 for details.

Service interfaces for enterprise and portfolio services need to be reviewed and approved by SOA COE prior to the realization of the services.

Service Certification and Rating

Enterprise and portfolio services need to be certified prior to their launch into production. During the service certification process, service registry information gets validated, QA/QC testing of enterprise services gets checked, and services are rated for their quality.


Chapter

6


The main purpose of service interface approval and service certification is to ensure services are designed and built as best they can be.

SOA Governance CheckpointsSOA Web services governance has been integrated into other processes such as SEER Estimation, SDM, and EAA. This is to ensure that project teams follow methodologies and develop SOA based solutions according to published policies and standards. This segment describes high-level touch points between SOA governance and other processes.

Touch Points with SEER Estimation

Currently when a project team requests E2 SEER Estimate, the estimation process initiates the Service Opportunity Review where SOA COE works with the project team to identify opportunities to re-use existing services or create new services. With the review results, SEER estimators factor service reuse savings and creation effort into project estimates.

SOA COE will follow up with the project teams through the lifecycle of the projects to see whether SOA recommendations are being actualized.

For small projects (i.e. Category 0 and 1 projects), which do not go through the SEER estimation process, project teams should notify SOA COE whether they will reuse and build a new service so that the Service Opportunity Review could take place early in the development lifecycle followed by other SOA governance actions such as EAA reviews.

Touch Points with EAA

The EAA Guidance review refers to the results from the Service Opportunity Review to validate the correct services were identified.

The EAA Assurance review refers to the outcome of the Service Interface Approval and helps further validate the correct services have been chosen and designed.

Mediation sessions may be requested to resolve issues or conflicts.

Touch Points with SDM

If a project includes Web services development or consumes Web services, the project team needs to perform the following during the ID & Assess stage of Classic SDM or the Inception phase of Unified SDM:

• participate in Service Architecture Assessment

• initiate a Service Level Agreement for any service the project team wishes to consume

During early Analysis stage of Classic SDM or Elaboration phase of Unified SDM, SOA COE works with project teams to register Web services in the RR.

The project team should use the SOA Service Definition document as the SDM artifact.


Chapter

6


During Analysis and Design, project teams engage SOA for service interface reviews. The service interface approval needs to occur prior to the end of the Design stage of Classic SDM or prior to the end of the Elaboration #2 phase of Unified SDM.

Project teams engage QA/QC for testing of enterprise class services, and optionally portfolio class services.

Project teams engage SOA for service certification prior to their launch of services.

SOA COE works with project teams to register service consumers after the services are launched in production.

Mediation Process

Web services development is different from traditional application development in that Web services are designed and built for re-use across application or system boundary. Please refer to the Design for Reuse and Services are Autonomous principles in Section 5.

In Web services development or reuse of Web services, issues or conflicts can arise. For instance, the conflict between fulfilling immediate project needs and satisfying enterprise goals, the issue or concern about having funding, resources to support changes from different service consumers, and so forth.

The service mediation process provides a framework for escalating, reviewing and resolving the issues in a timely manner to avoid any undesirable consequences.

Governance ArtifactsProject teams should define services in a standard and clear way so that they can be reused and understood. Service providers publish and maintain well-defined artifacts in order to capture and preserve subject matter expertise and facilitate communication amongst stakeholders. Currently, SOA COE and project teams publish the following into the repository:

• Service Registry Entry Data• XML Schema(s) and XML Schema Specification• WSDL file• UML Models• SLA

Service Registry Entry Data

After approving a service idea, SOA COE registers the service in the service registry repository. The name and namespace of the service, which are part of Service Architecture Assessment, conform to naming conventions and are used during the registration. Project teams need to use these names in their service interface artifacts such as WSDLs so they can publish the artifacts into the repository later on. Service versioning (i.e minior or major service version) is also decided and captured in the registry repository.


Chapter

6


Other information such as service description, service operations, and performance and support expectations for the service are also specified in the registry repository.

XML Schema and XML Schema Specification

XML is the language used for exchanging data between heterogeneous systems. XML Schemas establish semantics, structure, and constraints that govern the content of a particular message exchange. XML schemas must be well-annotated in order to describe components of the schema and to articulate the context of associated message(s).

Project teams must provide the XML Schema along with the WSDL file when requesting for service interface approval. The completed schema must be included for a service interface to be approved. See the Guide to XML Schema Design for information on XML Schema.

The XML Schema Specification is a tool-generated document that serves as communication material for the business and for new project members, imparting to them visual and verbal descriptions about the project XML implementation, so that they are able to understand the source code without opening the XML file. Altova XMLSpy and Rational Software Architect (RSA) tooling are used to generate such documentation.

WSDL

A Web Service Description Language (WSDL) file is an XML file that describes Web services endpoint interfaces. It specifies the operations and their input / output messages that the service exposes. A completed WSDL is required for a service to be approved. For a practical way of creating WS-I BP compliant WSDLs, see the "Web Services Design Guidelines" section.

UML Models

At Ford, enterprise Web services are defined via enterprise, domain and logical models. Unified Modeling Language (UML) models include a set of diagrams that may be required, depending on the scope of the services.

• Use Case Models – Describes, from an external observer's viewpoint, how users

interact with a system.• Class Diagrams – Provides an overview of a system by showing its classes, features,

and relationships between classes.• Activity Diagrams – Focuses on the flow of activities involved in a single process.• Sequence Diagrams – Details how operations are carried out.• Deployment Diagrams - Depict the physical layout (software and hardware) of a

system.

There is also an abundance of research material available on the Internet and via Ford's internal libraries (such as RLIS, Books 24x7) on how to create these models.


Chapter

6


For enterprise-class Web services, project teams must provide UML models along with WSDL and schema files when requesting for service interface approval.

Process Models

Web services include communication between processes, which include explicit passing of data or invocation of a process. Modeling business processes makes impact analysis easier, allowing optimization of those processes that drive maximum ROI. Modeling business processes improves productivity by identifying processes that can be reused – identifying new service opportunities. In order to reuse and manage a business process, it must be visible. For a good example on how to use business process models to identify SOA opportunities see, Using Business Process Models to Identify Service-Oriented Architecture Opportunities in our Reference section.

Business process models are also useful in leading to the creation of solutions that are based on service composition, service orchestration, or process orchestration.

Business Process Modeling may be done in UML or Business Process Modeling Notation (BPMN) to take advantage of current modeling standards.

Project teams are recommended to provide process models when presenting a set of services in a concentrated business area such as a portfolio or program. Bill of Material (BOM) services and Consumer Data Refinery (CDR) services are two examples. The models are rendered as Business Process Flows/Swim Lanes diagrams, and Process Decomposition diagrams, which are described in the Guide to Business Owner View.

Service Level Agreement (SLA)

As a Web service provider, a project team needs to publish the Qualityof Service (QoS) information for its services in the registry. Examples of QoS data for a Web service are performance, reliability, capacity, integrity, availability, security, and so forth.

To consume a Web service, a project team needs to create the Service Level Agreement (SLA) with the service provider. The SLA describes the details of a specific service subscription (i.e. usage) and defines the quality of service properties that the service consumer will follow in using the service. Specific information captured in an SLA includes agreement effective and termination dates, average/maximum/minimum/peak messages per day, etc.

A Web service provider needs to approve the SLA before a service consumer can use the service.

Governance TechnologiesService registry repository and monitoring technologies have been identified as core SOA governance technologies. Simply put, a registry is a place where you list services, and a repository is a place where you store and manage service artifacts (models, WSDLs, schemas, etc.). Together, these components exist to fulfill the mission of making Web services discoverable, manageable, and reusable. Additionally, monitoring tools keep track of the services and their hosting applications on the network.


Chapter

6


Currently, Ford is using existing HP Mercury-based monitoring tooling for server/website uptime monitoring. Future state will be discussed later in this section.

Service Registry Repository

A service registry is a place to catalog, publish, search, demonstrate, download, and collaborate on services, without actually containing those assets. It just specifies attributes of the services – definitions and associated policy metadata – to help consumers looking to discover a service and providers looking to be discovered.

A service repository is for storing and versioning service artifacts (models, WSDLs, etc.) that make up the service. The repository also controls access to these artifacts and serves up what is listed in the registry. It should be noted that a service repository is not a general reuse code repository (i.e., Java Code repository); however, any code that is published into the repository can be linked from a reuse repository.

As the place where services are published and discovered, a registry repository is a natural management and governance point. For example, when a service is being published to the R-R, compliance requirements, such as conformance with WS-I Basic Profile or use of specific namespaces, can be checked. If the published service is changed, then approvals and change notification workflows can be triggered to those in charge of approving the change, as well as to those who may be affected by the change.

Ford Re-usable Asset Registry Repository (RR) has been deployed to be the registry repository tool for supporting SOA Web services governance. The underlying implementation of the RR is the IBM WebSphere Service Registry and Repository (WSRR).

The RR tool provides three different perspectives for the Web services registered:

• Business perspective – providing the business view of service capabilities and focusing on business governance aspect

• Developer perspective – providing the technical view of service functions, and focusing on the management of services and artifacts such as WSDLs and schemas.

• Operations perspective – capturing Service Level Agreement (SLA) including information such as service usage, Quality-of-Service (QoS) characteristics of registered Web services.

With the RR tool, different roles can perform different governance related functions. The following is a collective list of key functions that are currently provided:

• Find a service or business capability

• Propose a new service idea

• Create (register) a new service

• Request to use a service

• Manage Service Level Agreement (i.e view/approve/reject/activate/terminate SLAs)


Chapter

6


• Manage changes to services

• Propose service interface for review

• Approve service interface

• Certify services

• Rate service quality

• Provide service quality metrics and reports

For more information about the tool, please refer to the Registry Repository Training website https://comm.sp.ford.com/sites/sarr/Pages/Training.aspx.

Integration of the RR and DataPower

The service registry repository stores and governs SOA Web services and their metadata. It serves as the authoritative source (or System of Record) for the SOA artifacts.

The service registry repository can also be used in the run-time environment to enable dynamic endpoint selection, retrieve service policies and ensure services get validated against the specified policies prior to their invocation.

Specifically, our Re-usable Asset Registry Repository can be integrated with DataPower to support the runtime governance for SOA Web services.

At the time of writing, the RR is used as a static, design-time solution that contains a list of services and their artifacts, and the governance process only supports design-time governance for SOA Web services.

For more information about the SOA runtime governance and our infrastructure availability for supporting it, please contact the SOA Center of Excellence.

Monitoring

Hewlett Packard's Mercury Business Availability Center (BAC) and SiteScope are currently the only TMC approved tools for application monitoring, which are capable of monitoring Web services at Ford. BAC is a suite of application monitoring and diagnostics tools, which includes Business Process Monitor ("BPM", not to be confused with "Business Process Management") and SiteScope.

BAC's BPM and SiteScope are active monitoring solutions (a.k.a. "synthetic" monitoring), which means that "agents" are not deployed onto the servers and systems that are being monitored. BPM runs scripted tests, which simulate business transactions, on a recurring basis to calculate availability and response time. Whereas SiteScope is simply a Request/Response type of monitor, BPMs can be scripted to monitor Web services where complex monitoring logic is required. Consequently, BPMs can use a result from one transaction as input into another transaction.

SiteScope complements BPMs and uses pre-built, specialty, monitors for enterprise applications (web, application, and database servers, exchange, etc.), Web services and more


Chapter

6

https://comm.sp.ford.com/sites/sarr/Pages/Training.aspx


to monitor availability and performance on the Web and its system infrastructure. It also provides immediate diagnostics and alert notification of identified availability and performance problems. The Web service monitor can be configured to send a SOAP-based request to a server to verify that a Web service is responding. This will ensure that the service is accepting SOAP requests within a certain amount of time and that the response is correct based on the specifications provided by the tester.

In addition to the active monitors described above, Ford also has "passive" monitoring, which use "probes", or agents, deployed on servers in a network to collect performance, availability, and diagnostics data from Java EE applications without application source code modification or recompilation. The active monitoring tools work with the passive monitoring tools enabling IT support teams to probe problematic transactions at the application tier where the problem originated. The data is gathered and brought back to a central server for analysis. The HP J2EE Diagnostics provides the passive monitoring capability, though Ford has limited licenses for the tool.

Because passive monitoring looks at real transactions (not simulations) on the network it may be a better indicator of actual performance causes that a real user is experiencing. However simulated scripts can often find issues before they happen, while passive monitors find issues as they are happening.

Future State

In the future, Ford is looking at a hybrid approach of monitoring for Web services. Active monitoring will continue to serve the company for URL, transaction, and application monitoring, while passive monitoring will be considered for business critical services when we need to have a view of real-time service calls and the performance of the methods of those services.

For more information on BAC and SiteScope, please visit the Monitoring Tool websiteat https://dept.sp.ford.com/sites/monitoringtools/Pages/Default.aspx

For more information on the HP J2EE Diagnostics, please visit the HP J2EE Diagnostics website at https://www.tc.ford.com/ts/DevTools/j2eediag/default.aspx


Chapter

6

https://www.tc.ford.com/ts/DevTools/j2eediag/default.aspx

https://dept.sp.ford.com/sites/monitoringtools/Pages/Default.aspx


7 ReferencesBelisle, Steve, Architecture Management Glossary, Ford Motor Company internal publication, Dearborn, MI, 2005, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Biringer, Bernie and Gottwald, Mike, Architecture Strategy for Information, Ford Motor Company internal publication, Dearborn, MI, 2005, http://www.tc.ford.com/ts/ampo/publications/pages/Information.aspx

Drummond, Chuck, Guide to Transaction Pattern 2011, Ford Motor Company internal publication, Dearborn, MI, 2011, https://www.tc.ford.com/ts/ampo/publications/default.aspx

EAA Security Web Site, Ford Motor Company internal publication, Dearborn, MI, http://www.eaa.ford.com

Esker, Ed, Architecture Principles, Ford Motor Company internal publication, Dearborn, MI, 2005, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, Enterprise Data Model, Ford Motor Company internal publication, Dearborn, MI, 2005, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, Enterprise Information Models, Ford Motor Company internal publication, Dearborn, MI, 2007, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, Enterprise Process Model, Ford Motor Company internal publication, Dearborn, MI, 2010, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, Osborne, Mark, Guide to Business Owner View, Ford Motor Company internal publication, Dearborn, MI, 2005, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, Kanapur, Raj, Process for Information Governance, Ford Motor Company internal publication, Dearborn, MI, 2005, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Esker, Ed, et al., Using Business Process Models to Identify Service-Oriented Architecture Opportunities, Ford Motor Company internal publication, Dearborn, MI, 2005, https://mysite.sp.ford.com/personal/eesker/Presentations/Forms/AllItems.aspx

SOA Center of Excellence, Guide to XML Schema Design, Ford Motor Company internal publication, Dearborn, MI, 2011, https://www.tc.ford.com/ts/ampo/publications/default.aspx


Chapter

7


https://mysite.sp.ford.com/personal/eesker/Presentations/Forms/AllItems.aspx







http://www.eaa.ford.com/


http://www.tc.ford.com/ts/ampo/publications/pages/Information.aspx



Ford IT Policy Manual, Ford Motor Company internal publication, Dearborn, MI, http://www.itpolicy.ford.com

Java Center of Excellence, Ford Java Frameworks Web Site, Ford Motor Company internal publication, Dearborn, MI, https://www.tc2.ford.com/ts/JCOE/Lists/FJF%20Releases/Display%20View.aspx

Ford Legal Access Web Site, Ford Motor Company internal publication, Dearborn, MI, https://dept.sp.ford.com/sites/fordlegal/Pages/Default.aspx

Ford Re-usable Asset Registry-Repository, Ford Motor Company internal publication, Dearborn, MI, https://www.sarr.ford.com

Java Center of Excellence, Java EE Developer’s Guide for Web Services, Ford Motor Company internal publication, Dearborn, MI, 2009, https://www.tc2.ford.com/ts/JCOE/Java%20Technologies%20Wiki/Web%20Services.aspx

Koenig, Paul, Process for Setting Technology Standards, Ford Motor Company internal publication, Dearborn, MI, 2009, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Information Technology Solution Delivery Methodology (SDM), Ford Motor Company internal publication, Dearborn, MI, https://comm.sp.ford.com/sites/sdm/Pages/index.htm

Java Center of Excellence, Java Center of Excellence Web Site, Ford Motor Company internal publication, Dearborn, MI, http://www.j2ee.ford.com/index.html?ID=home

Karsten, Eric, Architecture Patterns, Ford Motor Company internal publication, Dearborn, MI, 2004, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Kerr, Tom, Architecture Management Guidebook, Ford Motor Company internal publication, Dearborn, MI, 2004, https://www.tc.ford.com/ts/ampo/publications/default.aspx

Shi, Wei, et al., Guide to Interoperability, Ford Motor Company internal publication, Dearborn, MI, 2011. https://www.tc.ford.com/ts/ampo/publications/default.aspx

Reference Model for Service Oriented Architecture 1.0, OASIS Publication, August 2006, http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

Service Orientation and Its Role in Your Connected Systems Strategy, Microsoft Corporation, Redmond, WA, 2004, http://msdn2.microsoft.com/en-us/library/ms954826.aspx


Chapter

7

http://msdn2.microsoft.com/en-us/library/ms954826.aspx

http://msdn2.microsoft.com/en-us/library/ms954826.aspx

http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf




http://www.j2ee.ford.com/index.html?ID=home

https://comm.sp.ford.com/sites/sdm/Pages/index.htm


https://www.tc2.ford.com/ts/JCOE/Java%20Technologies%20Wiki/Web%20Services.aspx

https://www.sarr.ford.com/

https://dept.sp.ford.com/sites/fordlegal/Pages/Default.aspx

https://www.tc2.ford.com/ts/JCOE/Lists/FJF%20Releases/Display%20View.aspx

https://www.tc2.ford.com/ts/JCOE/Lists/FJF%20Releases/Display%20View.aspx

http://www.itpolicy.ford.com/


SOA Center of Excellence, SOA Center of Excellence Web Site, Ford Motor Company internal publication, Dearborn, MI, https://comm.sp.ford.com/sites/soa/Pages/Default.aspx

SOA Center of Excellence, Web Services Frequently Asked Questions, Ford Motor Company internal publication, Dearborn, MI, https://comm.sp.ford.com/sites/soa/Lists/Web%20Services%20FAQ

Web Services Interoperability Organization, Web Services Interoperability Organization publication, http://www.ws-i.org

Web Services Security: SOAP Message Security 1.0. Organization for the Advancement of Structured Information Standards (OASIS) publication, 2004, http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

Web Services Handbook for WebSphere Application Server Version 6.1, IBM Publication, 2009, http://www.redbooks.ibm.com/abstracts/sg247257.html

WS-Basic Security Profile, Web Services Interoperability Organization publication, http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity

WS-Security Policy v1.0, Organization for the Advancement of Structured Information Standards (OASIS) publication, 2005, http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf

WS-I Basic Profile, Web Services Interoperability Organization publication, http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

SOA Center of Excellence, Specification for Ford Enterprise API, Ford Motor Company internal publication, Dearborn, MI, 2009, https://www.tc.ford.com/ts/ampo/publications/default.aspx

John McClean, Service Versioning Policy, Ford Internal Publication, Dearborn, MI, 2011, https://comm.sp.ford.com/sites/soa/Sections/Standards%20and%20Best%20Practices.aspx

SOA Center of Excellence, SOA Infrastructure Web Site, Ford Motor Company internal publication, Dearborn, MI, https://comm.sp.ford.com/sites/soa/Pages/SOAInfrastructure.aspx

Guy Footring, John McClean, HTTP(S) for B2X Outbound Messaging, Ford Motor Company internal publication, Dearborn, MI, https://www.tc2.ford.com/ts/JCOE/Java%20Technologies%20Wiki/HTTP(S)%20for%20B2X%20Outbound%20Messaging.aspx


Chapter

7

https://www.tc2.ford.com/ts/JCOE/Java%20Technologies%20Wiki/HTTP(S)%20for%20B2X%20Outbound%20Messaging.aspx

https://www.tc2.ford.com/ts/JCOE/Java%20Technologies%20Wiki/HTTP(S)%20for%20B2X%20Outbound%20Messaging.aspx

https://comm.sp.ford.com/sites/soa/Pages/SOAInfrastructure.aspx

https://comm.sp.ford.com/sites/soa/Sections/Standards%20and%20Best%20Practices.aspx

https://comm.sp.ford.com/sites/soa/Sections/Standards%20and%20Best%20Practices.aspx


http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicprofile

http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf

http://www.oasis-open.org/committees/download.php/15979/oasis-wssx-ws-securitypolicy-1.0.pdf

http://www.ws-i.org/deliverables/workinggroup.aspx?wg=basicsecurity

http://www.redbooks.ibm.com/abstracts/sg247257.html

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf

http://www.ws-i.org/

https://comm.sp.ford.com/sites/soa/Lists/Web%20Services%20FAQ

https://comm.sp.ford.com/sites/soa/Lists/Web%20Services%20FAQ

https://comm.sp.ford.com/sites/soa/Pages/Default.aspx


Business Process Management, Business Process Management Web Site, Ford Motor Company internal publication, Dearborn, MI, https://www.tc.ford.com/ts/BPM/default.aspx


Chapter

7

https://www.tc.ford.com/ts/BPM/default.aspx


8 Contacts

The SOA for Web Service Pattern 2012 document is maintained by the SOA Center of Excellence within Java Shared Services of Application Development Solutions (ADS) organization of Ford Motor Company. The following individuals can be contacted regarding the material described in this document:

• Scot Ferman (RFERMAN1)

• Denis Naranjo (DNARANJ2)

• Preeti Saravastinam (PSARAV1)

The authors would like to acknowledge and thank the following individuals who have contributed and/or provided feedback on this Pattern:

John McClean, Justin Hamilton, Jeff Mantei, Ravi Swaminathan, Eric Karsten, Lynn Cox, Subramanian Chandru, Ian Gale, Tim Haigh, Jonas Rönnkvist, Roopak Verma, Paul Vickers, Norbert Zimmermann, and Marie Gatenholm.


Chapter

8

soa for web services pattern 2012

Documents