The choice of implementation technology (and language) will be varied, and the methodology should not restrict the choice in anyway.

However, the choice may determine how sophisticated the validation may be between the implementation and the previous service design artifacts. In situations where the validation is not possible, then static validation of the service implementations will not be possible. However the service implementations can still be validated dynamically, as described in the subsequent “Test Services” and “Monitor Services” sections.

The first step that should be possible with most implementation technologies is to provide the initial generation of skeleton service implementation artifacts. For example, for an orchestrated service where the orchestration technology of choice is BPEL, then the abstract behaviour of the service can be generated as a BPEL process. In the case of the purchasing example, the Store participant would have the following skeleton BPEL process:

<process name="PurchaseGoodsProcess_Store" xmlns="http://docs.oasis-open.org/wsbpel/2.0/process/executable">
    <partnerLinks>
        <partnerLink myRole="StoreService" name="BuyerToStore" partnerLinkType="BuyerToStoreServiceLT"/>
        <partnerLink name="StoreToCreditAgency" partnerLinkType="StoreToCreditAgencyLT"                
                         partnerRole="CreditAgencyRequester"/>
    </partnerLinks>
    <variables>
        <variable messageType="BuyRequest" name="buyRequestVar"/>
        <variable messageType="CreditCheckRequest" name="creditCheckRequestVar"/>
        <variable messageType="CreditCheckOk" name="creditCheckOkVar"/>
        <variable messageType="BuyConfirmed" name="buyConfirmedVar"/>
        <variable messageType="CreditCheckInvalid" name="creditCheckInvalidVar"/>
        <variable messageType="BuyFailed" name="buyFailedVar"/>
    </variables>
    <sequence>
        <receive operation="buy" partnerLink="BuyerToStore" portType="StorePT" variable="buyRequestVar"/>
        <scope>
            <faultHandlers>
                <catch faultName="CreditCheckFailed" faultVariable="creditCheckInvalidVar">
                    <sequence>
                        <reply faultName="BuyFailed" operation="buy" partnerLink="BuyerToStore" portType="StorePT" 
                              variable="buyFailedVar"/>
                    </sequence>
                </catch>
            </faultHandlers>
            <sequence>
                <invoke inputVariable="creditCheckRequestVar" operation="checkCredit" outputVariable="creditCheckOkVar" 
                         partnerLink="StoreToCreditAgency" portType="CreditAgencyPT"/>
                <reply operation="buy" partnerLink="BuyerToStore" portType="StorePT" variable="buyConfirmedVar"/>
            </sequence>
        </scope>
    </sequence>
</process>

The skeleton implementation can then be extended to include the non-observable internal details. Note that this skeleton implementation of the Store service only contains the behavior to interact with the CreditAgency service – and therefore reflects the case where the Store participant has not been decomposed into other candidate services. If the decomposition had been performed, then this BPEL process may also include interactions with PriceCalculation, CustomerEntity and potentially DiscountApprover services.

With an implementation technology such as BPEL, it is possible to infer the communication structure from the implementation and check it against the design artifacts. This will also make it possible to incrementally update the implementation as the design changes.

However, if the communication structure cannot be inferred from the language, then it will only be possible to generate the initial skeleton implementation. As design changes occur, it will be necessary to manually apply these changes to the implementation. Confirmation that the implementation is correct, in respect of the design and business requirements, will only be achieved during the “Test Services” and ultimately the “Monitor Services” phases.

Therefore it is better to use an implementation technology that supports the inference of the communication structure.

Details

This section will concentrate on the development of WS-BPEL and ESB based services. Other types of service may use artifacts that are not appropriate to be directly stored within the repository. These scenarios will be considered at a later stage.

Repo: Implementation artifacts (such as BPEL, WSDL, XSD, XSLT, config files, etc) could be stored in the repository, but have appropriate relationships with the service logic design.  Some of these implementation artifacts may be shared across service implementations.

Input: Detailed service design artifacts

Output: Updated deployment model, with implementation details for each participant (service, database, human task manager, etc). Service implementation artifacts, (e.g. BPEL, WSDL, XSD, XSLT, jboss-esb.xml, smooks config files, etc.).