[jboss-svn-commits] JBL Code SVN: r34376 - labs/jbossrules/trunk/drools-docs/drools-docs-guvnor/src/main/docbook/en-US/Chapter-Guvnor.
jboss-svn-commits at lists.jboss.org
jboss-svn-commits at lists.jboss.org
Thu Jul 29 20:50:28 EDT 2010
Author: Rikkola
Date: 2010-07-29 20:50:28 -0400 (Thu, 29 Jul 2010)
New Revision: 34376
Modified:
labs/jbossrules/trunk/drools-docs/drools-docs-guvnor/src/main/docbook/en-US/Chapter-Guvnor/Section-UserGuide.xml
Log:
removed outdated execution server chapter
Modified: labs/jbossrules/trunk/drools-docs/drools-docs-guvnor/src/main/docbook/en-US/Chapter-Guvnor/Section-UserGuide.xml
===================================================================
--- labs/jbossrules/trunk/drools-docs/drools-docs-guvnor/src/main/docbook/en-US/Chapter-Guvnor/Section-UserGuide.xml 2010-07-30 00:25:42 UTC (rev 34375)
+++ labs/jbossrules/trunk/drools-docs/drools-docs-guvnor/src/main/docbook/en-US/Chapter-Guvnor/Section-UserGuide.xml 2010-07-30 00:50:28 UTC (rev 34376)
@@ -1840,259 +1840,6 @@
automatically contact Guvnor for updates - but that is generally the
easiest way for many people).</para>
</section>
-
- <section>
- <title>Drools execution server</title>
-
- <para>IMPORTANT NOTE: the exact message formats described here are
- likely change post drools 5 (as support for processes and stateful
- sessions is added). The following will be preserved for compatability,
- but may be deprecated in favour of more flexible formats that are in the
- pipelines (ie consider the following to be DEPRECATED).</para>
-
- <para>The drools execution server (drools-server) module is a war which
- you can deploy to execute knowledgebases (rulebases) remotely for any
- sort of client application. This is not limited to JVM application
- clients, but any technology that can use HTTP, and either XML or JSON.
- Currently this execution server is for stateless sessions (which also
- makes it easy to scale out).</para>
-
- <para>A "restful" style of interface is provided, with URLs defining
- what knowledgebase is being accessed. Client applications then execute
- knowledgebases remotely via HTTP(S). The rule execution server uses the
- knowledge agent described in the sections above.</para>
-
- <section>
- <title>Configuration and deployment</title>
-
- <para>drools-server is a war file, which can be deployed in a
- application server (such as JBoss AS). As the service is stateless, it
- is possible to have have as many of these services deployed as you
- need to serve the client load. The war file should be expanded to a
- folder for deployment (which will be clear later) - so you can deploy
- this as a folder called drools-server.war.</para>
-
- <mediaobject>
- <imageobject>
- <imagedata align="center"
- fileref="images/Chapter-Guvnor/running_execution_server.png"
- format="PNG" scalefit="1"></imagedata>
- </imageobject>
- </mediaobject>
-
- <para>Once the war has been deployed, you should be able to go to
- http://localhost:8080/drools-server and see a page like the above
- (obviously substitute a correct server address). The page shown should
- provide information on how to use it, and indicates that it is
- healthy.</para>
-
- <para>To configure a "knowledgebase" - you create a properties file
- with a knowledge agent configuration in it (see the section above for
- details on the options in the knowledge agent configuration). The name
- of this properties file will be the name in the URL that you use to
- access this servive. So lets take the example of
- teamallocation.properties: an agent configuration for a service that
- will allocated some piece of work to a team. teamallocation.properties
- should contain details on what packages are to be loaded, and from
- where.</para>
-
- <para>Place teamallocation.properties in the WEB-INF/classes directory
- in the war directory (and restart the server if needed). Importantly,
- you will ALSO need any jar files that your rules need placed in the
- WEB-INF/lib directory of each execution server instance (eg your
- model, if you are using pojo models, or supporting classes if needed -
- you may not need any). Typically if you are using the execution
- server, your client code will not use a object model jar to talk to
- the service so</para>
-
- <para>Once this is done, the server is accessed via a url of the
- pattern:
- <literal>http://your-server/drools-server/knowledgebase/{agent configuration name}</literal>.
- So in the example above it would be:
- <literal>http://your-server/drools-server/knowledgebase/teamallocation</literal>
- You can see from this that you can have as many agents configured as
- you like, perhaps for many concurrent versions of
- knowledgebases.</para>
- </section>
-
- <section>
- <title>Consuming the service</title>
-
- <para>Consuming the service is quite simple, you need to choose to use
- either XML or JSON. By default XML is used, but by setting the
- Content-Type HTTP header to application/json, JSON will be used (JSON
- can be more performant in some circumstances).</para>
-
- <para>Client libraries: one of the nice things about a REST service is
- that no special client libraries are required, regardless of the
- langugae used. In java however, Apache commons "HttpClient" is
- recommended as an easier API to use then the defaults. Only HTTP is
- required (of course https can be used for secure transport if on an
- untrusted network).</para>
-
- <para>A sample request:</para>
-
- <programlisting><knowledgebase-request>
- <globals>
- <named-fact>
- <id>myglobal</id>
- <fact class="org.drools.server.ExampleFact">
- <carType>Saab</carType>
- <carPrice>42</carPrice>
- </fact>
- </named-fact>
- </globals>
- <inOutFacts>
- <named-fact>
- <id>myfact</id>
- <fact class="org.drools.server.ExampleFact">
- <carType>BMW</carType>
- <carPrice>50</carPrice>
- </fact>
- </named-fact>
- </inOutFacts>
- <inFacts>
- <anon-fact>
- <fact class="org.drools.server.ExampleFact">
- <carType>Audi</carType>
- <carPrice>55</carPrice>
- </fact>
- </anon-fact>
- <anon-fact>
- <fact class="org.drools.server.ExampleFact">
- <carType>Mercedes</carType>
- <carPrice>65</carPrice>
- </fact>
- </anon-fact>
- </inFacts>
-</knowledgebase-request></programlisting>
-
- <para>Elements of the request: note that there are 3 parts: globals,
- inOutFacts and inFacts. Both globals and inOutFacts are returned in
- the response message. Globals and inOutFacts are named (each name must
- be unique) for this purpose (in the case of globals, the name of the
- global is the name used in the rules). The "id" tag is used for the
- name. Note that the "fact" tag refers to a fact as used by the
- knowledgebase - the fields inside that enclosing tag are defined by
- the fact class itself. If a fact class has a nested class, then the
- data for that nested data would show up as <nestedFactFieldName>
- - where nestedFactFieldName is the name of the field in the "parent"
- class. Inside that tag are the tags with the values of the fields for
- that nested data (the class name is not needed as that is derived from
- the parent fact).</para>
-
- <para>A sample response:</para>
-
- <programlisting><knowledgebase-response>
- <globals>
- <named-fact>
- <id>myglobal</id>
- <fact class="org.drools.server.ExampleFact">
- <carType>Saab</carType>
- <carPrice>42</carPrice>
- </fact>
- </named-fact>
- </globals>
- <inOutFacts>
- <named-fact>
- <id>myfact</id>
- <fact class="org.drools.server.ExampleFact">
- <carType>BMW</carType>
- <carPrice>50</carPrice>
- </fact>
- </named-fact>
- </inOutFacts>
-</knowledgebase-response></programlisting>
-
- <para>Elements of response: Similar to the request (note the enclosing
- tags are different) - of course only the global and inOutFacts have
- their state returned.</para>
-
- <para>JSON: (Javascript Object Notation) follows the same basic object
- graph layout as the requests above. Some notes: in JSON, @class is
- used to indicate the type of the fact that the rules use. Also, in
- javascript, associative arrays (maps) are indicated by "{" and "}",
- and arrays via "[" and "]". In some cases, if there would be a list
- (array) but only 1 element of data is present, then "[" will not be
- shown. eg {"a" : "b"} can have the same meaning as [{"a" : "b"}] in
- results.</para>
-
- <para>A sample request:</para>
-
- <programlisting>{"knowledgebase-request":
-{"globals":{"named-fact":{"id":"myglobal","fact":{"@class":"org.drools.server.ExampleFact","carType":"Saab","carPrice":42}}},
-"inOutFacts":{"named-fact":{"id":"myfact","fact":{"@class":"org.drools.server.ExampleFact","carType":"BMW","carPrice":50}}},
-"inFacts":{"anon-fact":[{"fact":{"@class":"org.drools.server.ExampleFact","carType":"Audi","carPrice":55}},{"fact":{"@class":"org.drools.server.ExampleFact","carType":"Mercedes","carPrice":65}}]}}}</programlisting>
-
- <para>A sample response:</para>
-
- <programlisting>{"knowledgebase-response":
-{"globals":{"named-fact":{"id":"myglobal","fact":{"@class":"org.drools.server.ExampleFact","carType":"Saab","carPrice":42}}},
-"inOutFacts":{"named-fact":{"id":"myfact","fact":{"@class":"org.drools.server.ExampleFact","carType":"BMW","carPrice":50}}}}}</programlisting>
-
- <para>Following is an example code snippet showing how a knowledgebase
- is accessed using JSON from Ruby:</para>
-
- <programlisting>
- require 'json'
- http = Net::HTTP.new('localhost', 8080)
- path = "/drools-server/knowledgebase/teamallocation"
- post_data = {"knowledgebase-request" => {
- :globals => {"named-fact" => [{:id => "a", :fact => {"@class" => "teamallocation.Assignment"}}]},
- :inFacts => {"anon-fact" => [{:fact => {"@class" => "teamallocation.Claim", "value" => 150}}]},
- :inOutFacts => {"named-fact" => [{:id => "x", :fact => {"@class" => "teamallocation.Team", "specialty" => "FATAL"}},
- {:id => "y", :fact => {"@class" => "teamallocation.Team"}}]}
- }
- }
- headers = {
- "Content-Type" => "application/json"
- }
- resp, data = http.post(path, post_data.to_json, headers)
-
-
- answer = JSON.parse(data)
- #digging out the results:
- puts answer["knowledgebase-response"]["globals"]["named-fact"]["fact"]["teamName"]
- #if there is more then one fact, they are a list
- puts answer["knowledgebase-response"]["inOutFacts"]["named-fact"][0]["fact"]["specialty"]
-</programlisting>
- </section>
- </section>
-
- <section>
- <title>JMS, SOAP/WSDL integration</title>
-
- <para>A stateless rule execution server may not be enough for your
- needs. If you require WSDL+SOAP, JMS or other integration, JBoss ESB
- (http://www.jboss.org/JBossESB/) can be used.</para>
-
- <para>The esb can provide stateful and stateless rule services via
- multiple transport mechanisms (such as http/soap, or JMS, and many many
- more) as needed. Load balancing, failover, monitoring and more is also
- provided. Refer to the ESB site (http://www.jboss.org/JBossESB/) for
- more information on this (it will not be covered in this manual).</para>
- </section>
-
- <section>
- <title>Manual deployment</title>
-
- <para>This section is only needed for advanced users who are integrating
- deployment into their own mechanism. Normally you should use the
- knowledge agent.</para>
-
- <para>For those who do not wish to use the automatic deployment of the
- KnowledgeAgent, "rolling your own" is quite simple. The binary packages
- emitted by Guvnor are serialized Package objects. You can deserialize
- them and add them into any knowledgebase - essentially that is all you
- need to do.</para>
-
- <para>From Guvnor, binary packages are provided either from the latest
- version of a package (once you have successfully validated and built a
- package) or from the deployment snapshots. The URLs that the Guvnor web
- application exposes provide the binary package via http. You can also
- issue a "HEAD" command to get the last time a package was
- updated.</para>
- </section>
</section>
<section>
More information about the jboss-svn-commits
mailing list