bildwelt
E2E FORUM
E2E Bridge E2E Commerce

Containment Tree Package Hierarchy in SOAP Url

E2E Forum Modeling & Development Containment Tree Package Hierarchy in SOAP Url

This topic contains 5 replies, has 2 voices, and was last updated by  Marcel R. 4 years, 7 months ago.

Viewing 6 posts - 1 through 6 (of 6 total)
  • Author
    Posts
  • #475

    Christof
    Blocked

    Why is the containment tree hierarchy of a SOAP port part of the SOAP URL? Wouldn’t it suffice to use the PortType name from the component diagram?

    I just cleaned up the containment tree of a project, did some re-ordering and structuring into packages, and now my (regression) testcases don’t work any more…

    #483

    Marcel R.
    Blocked

    In the component diagram you can refer to two different port types that have the same name but reside in different packages. But the URL has to identify a port type uniquely within one composite. So we cannot use just the simple port type name. Thus, we map the full qualified name to a URL by default. However, you can use the tagged value “path” to define your own URL making you independent of your package structure.

    #484

    Christof
    Blocked

    Imho, two different port types that have the same name is a rather questionable design… Does that happen often?

    I’d rather suggest to forbid this and just use the unique port type name. In case it’s not unique, the modeler can adapt it easily, can’t he?

    I think renaming packages / restructuring the containment tree is something that happens quite often, and it’s more transparent to the modeler that his testcases won’t work any more if he or she changes port type names.

    Specifying a path in yet another place (tagged value) is a good alternative, but from my point of view does not make it more transparent neither.

    #485

    Marcel R.
    Blocked

    I don’t know how often it happens. I agree, it’s a questionable design, but it would not be the first one that occurs in practice. I also agree that it would make sense to forbid non-unique port type names but I assume it is to late now. Because if we do this now, we not only have to forbid non-unique port type names but also change the namespaces to get rid of the package names. This would break all existing WSDLs. Better ideas?

    #488

    Christof
    Blocked

    I didn’t think of the namespaces (although this explains why further testcases failed even after manually correcting the SOAP URL in Analyzer).

    I’d nevertheless vote for a change with the next major release 😉 Due to the simplified component diagram introduction, existing projects / WSDLs need to be “migrated” anyway.

    Currently the modeling guideline is:
    Once you defined a SOAP Service, never ever again modify any package name that contains data structures.
    I fear this does not promote agility 😉

    #489

    Marcel R.
    Blocked

    We could make the path mandatory. Then the compiler tells you to set it and it is always visible in the component diagram. Additionally, you could avoid breaking the WSDL by using the same path.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.