Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance DataPortal to use different endpoint per business type #959

Closed
rockfordlhotka opened this Issue Oct 30, 2018 · 3 comments

Comments

Projects
1 participant
@rockfordlhotka
Copy link
Member

commented Oct 30, 2018

In a service-oriented model there may be value in having different data portal server endpoints for different subsets of business domain types. The reasoning behind this is that some server-side code might:

  • be a "hot spot" that needs different scaling from other parts of the app
  • need to run on specialized hardware
  • need to run in specific geographical data centers (GPDR, etc.)
  • need to version more rapidly than other parts of the app

Now I'm not saying that the data portal will support true service-oriented modeling, it is an n-tier technology after all. However, the goals listed here fit within the realm of n-tier and yet provide a number of benefits also provided by a service-oriented model.

Possible solutions

One way to do this is literally on a per-type basis.

  • The existing data portal configuration would be the default
  • For specific types the data portal proxy type and URL could be provided via configuration
  • The per-type configuration would override the default

Another way to do this would be via some sort of "resource descriptor".

  • The existing data portal configuration would be the default
  • A business type could be attributed with a "resource descriptor" name (an arbitrary string)
  • Via configuration we'd provide the data portal proxy type and URL for each resource descriptor
  • The data portal would use the appropriate proxy/URL based on the resource descriptor attribute on a root type, and would fall back to default otherwise
@rockfordlhotka

This comment has been minimized.

Copy link
Member Author

commented Nov 4, 2018

Current thinking on implementation:

image

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Nov 4, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Nov 4, 2018

MarimerLLC#959 Update default proxy factory to determine proxy descri…
…ptor from object type or DataPortalServerResource attribute.

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Nov 5, 2018

@rockfordlhotka rockfordlhotka self-assigned this Nov 5, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Nov 5, 2018

rockfordlhotka added a commit to rockfordlhotka/csla that referenced this issue Nov 5, 2018

Version 4.9.0 automation moved this from In progress to Done Nov 5, 2018

@rockfordlhotka rockfordlhotka moved this from Done to In progress in Version 4.9.0 Nov 6, 2018

@rockfordlhotka

This comment has been minimized.

Copy link
Member Author

commented Nov 6, 2018

Need to address the proxy factory issue from this comment
MarimerLLC/cslaforum#647 (comment)

@rockfordlhotka rockfordlhotka reopened this Nov 6, 2018

@rockfordlhotka

This comment has been minimized.

Copy link
Member Author

commented Nov 8, 2018

Upon further research, this isn't necessary (or easy or wise).

The way I implemented the multiple proxy/url functionality is actually inside the DataPortalProxyFactory class itself.

And the reality is that the WcfProxy class is designed so you can subclass it and override methods to configure the WCF client as needed, so the scenario in the forum is already addressed.

Version 4.9.0 automation moved this from In progress to Done Nov 8, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.