与动态 HTML 相比，Web 服务有哪些优点？
我想知道使用应用程序服务器（例如 glassfish）而不是通过动态 html 页面（例如 PHP）提供内容的优点是什么。我想了解“网络服务”的优势，而不仅仅是一个网站，因为我正在开发一个在线商务网站，并且我想知道从直接 Apache 切换到类似的东西的一些经验法则可能是什么玻璃鱼。
I was wondering what the advantages are of using an application server (e.g. glassfish) instead of providing content via a dynamic html page (e.g. PHP). I'd like to understand the advantages of a 'web service', rather than simply a website, as I'm developing an online commerce site, and I am wondering what some rules of thumb might be for switching from straight Apache to something like glassfish.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
应用程序服务器（如 Java 世界中的 Glassfish）通常指的是除了实现 Web 服务器运行之外的软件Java Enterprise Edition 规范上下文中的 Java（或其他基于 JVM 的语言）Web 应用程序。所以它基本上只是一个用 Java 编写的用于 Web 应用程序的精美 Apache。
经验法则：如果您决定使用 Java 或在 Java 虚拟机上运行的其他语言，并且需要或想要使用任何 J2EE API，那么您可以使用应用程序服务器。
由于 HTML 页面通常是人类可读的信息表示，因此 Web 服务以机器可读格式提供信息，以便机器可以使用 HTTP 协议相互交互。术语 Webservice 主要用于使用 SOAP 协议进行通信，而不是一般的 Web 服务概念。由于 Web 服务不是特定于语言的，因此无论您使用 PHP、Java 还是 Ruby On Rails 或其他任何语言来实现 Web 服务，都没有关系。如果您想要提供一种与 Web 应用程序交互的方式，而不仅仅是通过用户操作的 Web 浏览器，则需要做出决定。
Application Servers like Glassfish in the Java world usually refers to a software that additionally to just implementing a webserver runs your Java (or other JVM based language) web application in the context of the Java Enterprise Edition specification. So it basically just a fancy Apache for web applications written in Java.
Rule of thumb: If you decide to use Java or another language that runs on the Java Virtual Machine and need or want to use any of the J2EE APIs you use an application server.
As a HTML page is normally a human readable representation of information a webservice provides information in a machine readable format so that machines can interact with each other by using the HTTP protocol. Instead of the general webservice concept, the term Webservice is mostly used for a communication using the SOAP protocol. Since webservices are not language specific it doesn't matter if you are using PHP or Java or Ruby On Rails or whatever to implement the webservice. The decision if you want to provide a way to interact with an your web application other than just via a user operated webbrowser.
当您开发 Web 服务时，您正在对接口进行编程，而不是实现。当您开发的页面推出只有您的应用程序知道如何使用的数据（例如专有 html 页面）时，您所做的恰恰相反。
从更广泛的角度思考您想要实现的目标 - 您是否将在多个地方、技术等中实施和重用此服务。这是您的关键。
When you develop a web service, you are programming to an interface, not an implementation. When you develop a page that is pushing out data that only your application understands how to consume, such as a proprietary html page, you are doing the exact opposite.
Think in broader terms of what you are trying to accomplish -- whether you will be implementing and reusing this service in multiple places, technologies, etc. That's your key.
考虑网络服务的风格。
您是否正在将 Soap 与 REST 进行比较？
REST Web 服务与网页非常相似，因为它使用 HTTP 的所有内置功能。作为 SOAPrest 服务，需要读取和消化它所需的基础设施。
玻璃鱼将您与特定的环境联系在一起，这意味着具有出色的可扩展性且无麻烦，但实际上情况往往并非如此，需要昂贵的资源来构建和维护代码。 （更不用说基础设施和许可证）
我建议使用一个非常简单的层来生成您的 Web 服务。例如：PHP 和一个小的休息框架工作，mabee 类似代码点火器的修改版本。由于休息是无状态的，因此很容易扩展。只需添加更多的 apache Web 服务器，直到牛来 hiome.. 错误.. 或直到你的数据库被破坏.. 但成功总是有其问题。为什么不在云上采用 REST 实施呢？在亚马逊上放置一些微型实例网络服务器，添加一个抽象的关系数据库，然后就可以开始了。
但正如本次讨论中其他人指出的那样，您不受语言的限制。更好地决定您的服务是什么。休息或肥皂。休息服务可以用 Python、Java、Pearl PHP 等构建。 SOAP 休息服务可能用 Java 构建，因为所有很酷的工具都在那里……这可能意味着玻璃鱼。
Think in terms of what style of web service.
are you comparing Soap to REST?
a REST web service is very similar to a web page as it uses all the inbuilt functionality of HTTP. Where as a SOAPrest service requires teh infrastructure required to read and digest it.
Glass fish ties you to a particular environment, which is meant to be wonderfully scalable and hassle free, but in reality is often not the case, requiring expensive resources to build and maintain the code. (not to mention infrastructure and liscences)
I would recommend using a very simple layer to produce your web service. eg: PHP and a small rest frame work, mabee something like a modified version of code igniter. Since rest is stateless, it makes it very easy to scale. Just add more apache web servers till the cows come hiome.. err.. or untill your database gets smashed.. but success always has its problems. Why not go with a REST implementation on the cloud. Put pup some micro instances Webservers on amazon, add an abstract relational databse, and off you go.
But as pointed out by others in this discusion you are not limited by language. better to decide on what your service is. REST or SOAP. a rest service can be built in Python, Java, Pearl PHP etc etc.. A SOAP rest service woukld probably be built in Java,a s all the cool tools are there.. which may mean glass fish.