Ivo, before you worry about the webservice, you need to make sure you have set up your domain model and associations correctly to store your data.
Having a one-to-one relationship between your 2 entities means that a contact can only ever be linked to a single ticket, and a ticket can only ever be liniked to a single contact. If you create a new ticket record and link it to the contact, this will replace any existing link from that contact to a previous ticket. I assume this is not what you want.
Normally you would want to allow a single contact record to be linked to multiple tickets. To do this you need to create the relationship by dragging from the ticket entity to the contact entity (Ticket_Contact, a_b) which I think is the opposite direction to the one you have created.
I'm having a problem understanding your requirements. Question, so there are additional attributes that are not part of the ticket or the contact, but part of the link between the two? If so, you need to change your domain model to create an intermediate entity to store this data. This entity would need a one-to-many association to both the ticket and the contact and would replace the direct association between the two
That's a bit clearer. So you have 'temporary' entities published as a webservice. There is no reason why you need 2 entities - you could have a single one that contains parameters that will be used to capture the data needed to create the ticket and validate/link to the contact. You could even have no temporary entities at all...
Remember, a wsdl in Mendix is actually a microflow that you publish, with input parameters, then whatever actions you wish.
Say for simplicity you need the loginname of the contact to be able to identify them, and you need the Summary, Description and Urgency of the ticket to create (you will probably need more than these 4 parameters, but let's keep it simple).
Create a microflow with 4 parameters corresponding to these attributes. In the microflow, use the loginname parameter to retrieve the Contact record. If it can't be found exit the microflow; if found create the ticket using the other 3 parameters, and set the association between the new ticket and the retrived contact record. Get your microflow to return a success boolean or string, such as the identifier of the ticket created.
Then right-click the microflow and choose to Publish as web service operation. Make sure the permissions to create objects in your domain model are correct and that the wsdl user has sufficient rights. You can add any validation to the data you need in your microflow.
All this can be achieved without having a 'staging' entity/ies.
Alternatively, your microflow could simply create a record in a temprary staging entity, and you could then process it later and clean up the old data using a scheduled event. This might give better performance of the wsdl if not having the ticket created immediately is acceptable.