需要一些有关 WSDL 名称空间实践的建议来应对不断变化的公司名称吗?

发布于 2024-12-05 16:38:09 字数 233 浏览 1 评论 0原文

作为一个在过去几年中至少更改过 3 次名称(以及域名)的公司工作过的人,使用 com.[company].[product].[function] 命名我们的 java 代码的做法等等意味着频繁的重构(或者只是生活在奇怪的 java 命名空间中)。

然而,我们现在也发布 WSDL 服务,并且它们也以类似的方式命名。在这里,域/公司更改的影响要严重得多,因为我们不能随意更改命名空间。

对于我们的服务命名空间有哪些建议?

As someone who has worked for a company that has changed it's name (and hence domain name) at least three times over the last few years, the practice of namespacing our java code with com.[company].[product].[function] etc has meant frequent refactoring (or just living with odd looking java namespaces).

However, we're now publishing WSDL services as well, and they are also namespaced in a similar way. Here, the impact of a domain/company change is much more serious, as we can't change the namespace on a whim.

What are some recommendations for namespacing our services?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

紙鸢 2024-12-12 16:38:09

使用简单的 URN ...

... 例如 urn:OrderServiceurn:BookSearchingServiceurn:TradingService 等,表明服务正在做什么。您的公司(无论今天的名称是什么)提供了这样的服务(例如书籍搜索),这应该足够了(不要到处都印上公司名称)。

将公司名称或项目名称添加到公共命名空间可能会导致诸如您提到的问题。有时您可以重构并更改名称,有时则不能。

对于 Web 服务,如果您进行重构,您将会破坏您的客户端,因为来自旧客户端的消息不会针对新的命名空间进行验证。您将在新命名空间上拥有客户端,在旧命名空间上拥有客户端。重复几次,记住哪个版本在哪个版本上会变得令人沮丧......

项目名称也有问题。如果该公司使用的名称是另一家起诉您的公司的商标名称,然后法律规定您不能再使用该名称,会发生什么情况?您必须更改名称,在这种情况下,您被迫重构并使所有客户端升级到新的命名空间。这对生意不好……你丢脸了。

因此,使用命名空间来标识 Web 服务作为操作提供的内容

Use simple URNs ...

... like urn:OrderService, urn:BookSearchingService, urn:TradingService etc, something that signals what the service is doing. Your company (whatever its name is today) offers such a service (e.g. book searching), and that should be enough (don't stamp the company names all over the place).

Adding company name or project name to a public namespace can cause problems such as the one you mention. Sometimes you can refactor and change the names sometimes you can't.

In case of a Web Service you will break your clients if you refactor because messages comming from the old clients will not validate against the new namespace. You will have clients on the new namespace and clients on the old one. Repeat this a couple of times and it becomes frustrating remembering which is on what version of the thing...

Project name is also problematic. What happens if the company uses a name which is a trademark of another company which sues you and then the law says you can no longer use the name? You have to change the name and in this case you are forced to refactor and make all your clients upgrade to the new namespace. This is not good for business... you loose face.

For this reason, use a namespace that identifies what the web service is offering as operations.

天邊彩虹 2024-12-12 16:38:09

互联网上充满了 Java 代码,其中的包展示了古老的原则:“本体重演系统发育”。换句话说,它们的包名称反映了古老的公司历史。

您的目标首先是避免冲突,然后是营销。因此,我建议您注册一个不是公司名称但或多或少描述代码的域名,并使用它。然后,当不可避免的更大的鱼出现时,名字却泰然自若。

瓮:建议既不存在,也不存在。如果有人运行一个代码生成器,无论你使用什么 URI,都将被映射到 Java 包名称或 C# 名称或其他名称,如果它与其他名称发生冲突,当然,这将是“互联网的消亡”据我们所知。”

The internets are full of java code with packages that exhibit that old principle: "Ontology recapitulates phylogeny." In other words, they have package names that reflect ancient corporate history.

Your goal here is confict-avoidance, first, and marketing second. So, I'd suggest that you register a domain name that is not the company name but is more or less descriptive of the code, and use it. Then, when the inevitable bigger fish comes along, the names are unperturbed.

The urn: suggestion is neither here nor there. If someone runs a code generator, whatever URI you use is going to be mapped to a Java package name or a C# name or whatever, and if that collides with some other name, it will be, of course, "the death of the internet as we know it."

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文