Petals Studio

Commit # 1857
New options for the SU refactoring.
Readability + precision + performances have been reviewed.

Commits # 1853 to # 1856
The *.common plug-in was refactored to use an API organization.
Refactoring and compare capabilities were added for SU, SA, and more generally, Petals Maven projects.

Still to do:
+ Improve the precision of the replacement for SU projects.
+ Add an option to also update secondary files (e.g. BPEL files).
+ Add an option to update derived names (e.g. port types and ports).

OK with this solution.

However as discussed by phone: if Petals position is to have only one SU-SOAP provide by service partner there is a reflexion to be lead on how this service, through the same SU, can be accessed with different configurations (for example: how to inject one particular SOAP header by flow for several flows and the same partner service ?) ?

For now it is not possible with only 1 SU provide.

Hi,

I think I see your point, but I do not think this is a best practice that tooling it.
Each SU should result in a distinct development, and remain driven by the WSDL.
We want to avoid the modification of a WSDL in the wizard. What we do with the end-point name is already on the limit.

However, maybe could I add a feature in the studio to ease your use case (even if it does not address it specifically).
You might have seen in the snapshot version of the studio that the JBI fields are now grayed in the SOAP wizard. So, it is not about modifying the wizard itself.
In fact, I could implement a refactoring feature. This feature would be available for SU projects (right-click > refactor) and in the JBI editor, in the helpers for "provides" blocks.

That would open a dialog, quite similar to what the Java tooling proposes, that would list the impacted files.
The refactoring would allow to change the service name. By changing it, that would impact the jbi.xml, the WSDL, the service-unit name and the SA projects that references this SU.

For your use case, the usage would be:
1. Create a SOAP project from your WSDL.
2. Refactor it by changing the service name.

Even if it is one additional step, that would remain a clean approach from the tooling perspective and save you some time.

There is no conflict using auto-generated endpoint and that's exactly xhy we're using this method!

Let guess you have 2 SA SOAP-provide (SA-1 and SA-2) with auto-generated endpoints that address the same WS. You want every request on the bus for flow-1 to go SA-1 and every request for flow -2 to go to SA-2 because you have done different SOAP configuration on each flow (SOAP headers information for example).

But you can't do that because when you send the request from flow-1 to SA-1 there 's nothing that guarantee you that your request will be send to SA-1 and SA-2 as they have the same JBI endpoint (as endpoint name is auto-generated so not specified by the consume, and interface and service are the same between SA-1 and SA-2). And this would be delegated to Petals dispatcher algorithm which would result in incorrect SOAP request when wlow-1 request will be send to WS through SA-2configuration and vice-versa.

Do you understand my point?
Am I missing something?

>> "service-unit names": having 2 identical SU with different names let me have them in my Studio but not deployed them as they have the same JBI endpoint.

I just tested it.
I created one SU called ...-provide-01 and a second one named ...-provide-02 (the 3 dots represents a same prefix).
That makes two projects in my workspace. Both target the same service and interface, but have an auto-generated end-point name.

Both are successfully deployed on a same instance of the SOAP BC.
When you have an auto-generated end-point name, you have virtually no chance of having a conflict.
When you deploy such a SU in Petals, Petals (the target component in fact) replaces the "autogenerate" value by a random one. Therefore, you should not have a conflict in the registry.
And since the SU names are different, you should not have a deployment conflict neither.

Are you sure there is a conflict?
However, since I am not sure of what you expect, the suggested approach requires you to create as many SU projects as expected end-points.
These SU projects would all have the same content. Only the project name would change. That would be almost the same if you had to change the service name.

I partially agree/disagree (but I don't have permission to open/close any issue )

"Having different end-point and service-unit names is enough and is flexible enough for what you want to do. "

• "service-unit names": having 2 identical SU with different names let me have them in my Studio but not deployed them as they have the same JBI endpoint.
• "different end-point": this is not possible as end-point are autogenerated

Using endpoints autogenerated is mandatory for load-balancing purpose. Indeed I can't deploy the same SU on 2 differents nodes (actually I can but Petals recognizes only one of both and always send requests to this one withtout balancing) except if enpoints are autogenerated.

The solution would be to multiply the same SU just to change the endpoint name, but this is not admissible and I don't think you would consider this as good practice, so do I

So in my opinion:

• either we find a solution to this issue:
  > keeping autogenerated endpoints and changing something else in the JBI endpoint
  > modifying Petals core with the ability to deploy several times a JBI endpoint, once on each node of the domain.
• either you consider that there can be only on SU-SOAP-provide by external web-service to invoke which is acceptable but couldn't be taken into account on our size because it's know to late to rollback all developments.

Thanks and regards,
Sébastien.

Commit # 1749
The interface and service fields are now read-only in the SOAP provides wizard.

After reading your case description and thinking about it, I am convinced you do not need to change the service name in the WSDL and in the jbi.xml.
Having different end-point and service-unit names is enough and is flexible enough for what you want to do.

If you plan to use these SOAP SU in BPEL processes, you cannot use auto-generated end-points. You will have to set them.
In the wizard, it is possible to change the end-point name. Taking a convention should be enough.

End-point name pattern = <Service-name>Endpoint-<ID>
SU name = su-SOAP-<Service-name>provide<ID>

And in fact, there is no problem with the Petals naming convention.
Taking one of your SU, we would directly know which component (SOAP) and which service are concerned.

Then, you only have to package each SU in its own SA.
Doing differently would not be a good practice IMO, and the studio only aims at encouraging the good ones.

If you disagree with me, feel free to reopen this bug.

> I think that at least if you don't want the WSDL to be modify, the wizard shouldn't allow users to modify these settings (as for the XSLT component for example).
You are right on this point.

> As for the endpoint I think that modifying the service name would be a minor modification as it doesn't appear in the SOAP request.
OK. I see your point.
When you say, editing the service name, you mean changing the local part of the service name, right?
Not the name space URI?

However, if I had to implement what you want, I would rather do the following:
+ Keep the same WSDL for all my provides.
+ Keep the same interface and service names in all the jbi.xml for my SOAP SU.
+ Make the end-point generated by Petals at deployment time.
+ Change the project-name (and thus the service-unit name) for all the SU projects. As an example, append it an ID: "-provide-01" or "-provide-entry-01".

On the other hand, it would not exactly match the naming convention in Petals.
But that can be discussed. I'm going to ask the team about this question (at least for me).
What would be the drawbacks of my solution for your case?

Indeed we decided to have several "SU provide" for the same SOAP service target. Actually we have several flows (about 20) and we want each of them to be packaged in one SA and to be independent so that we can install/desinstall them as we want... Furthermore doing so (even if we are not yet doing that for now) we could specify different parameters (pools, etc...) for each SU SOAP depending on the flow and even if it is the same service invoked.

For now what we are doing is generating the SU and then modifying by hand the service composant of the WSDL.
And indeed I'd expected the WSDL to be modify. As for the endpoint I think that modifying the service name would be a minor modification as it doesn't appear in the SOAP request.

I think that at least if you don't want the WSDL to be modify, the wizard shouldn't allow users to modify these settings (as for the XSLT component for example).

Can you describe a little bit what you would expect to have in the UI and how it would impact the generated artifacts?

I do not see how you could have two provides SU for SOAP that target a same service and which have different identifiers.
The interface and service name must match the WSDL and cannot be modified.

I'm not sure to understand your request.
Do you want to modify the WSDL from the wizard?

The end-point modification is a minor modification.
It is really an exception.