[JBoss Tools] - How to Proxy A Web Service with SOA-P 5 in JBDS
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"How to Proxy A Web Service with SOA-P 5 in JBDS"
To view the document, visit: http://community.jboss.org/docs/DOC-15171
--------------------------------------------------------------
A common question is how to Proxy a Web Service with SOA-P 5 or the JBoss ESB with the help of JBDS (JBoss Developer Studio). With SOA-P 5, several options are available to either call out to a Web Service or Host a Web Service internally. We will be discussing only the new SOAPProxy, the other main options are HTTP Router, SOAP Processor and SOAP Client, if you are interested these additional options, please consult the http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/5.0.0/html-single/Pro... SOA-P 5 Programmer's Guide. The new SOAPProxy is very useful in consuming an external Web Service implemented in anyway (i.e., C, C++, .NET or PHP), and republishing it with the SOA Platform. In this article, We will just be proxying the Web Service, not touching on the more interesting use cases, such as Versioning, adding Client Service Contracts, Aggregation, Orchestration, Transformations or Content Based Routing. These use cases and more can be built once we have the base foundation for proxying as laid out in this article.
In using SOAPProxy, first thing that you'll need is a wsdl. You can have this as a file or as a remote end point. A file is preferred to avoid dependency on the remote systems availability. When using a wsdl added to the file system, you can point to it by using the classpath, like this classpath:///META-INF/order.wsdl(yes, that is 3 slashes). When using SOAPProxy, HTTPS and associated credentials can be added. An http://wiki.jboss.org/wiki/Wiki.jsp?page=HttpClientFactory Apache Commons HTTPClient http://wiki.jboss.org/wiki/Wiki.jsp?page=HttpClientFactory properties file can be included to setup SSL with the Web Service endpoint. The Apache HTTPClient properties can also be used for Performance tuning settings, this is discussed at the end of this article.
As input to the SOAPProxy Action, a http://community.jboss.org/docs/DOC-14036 HTTP Gateway should be the defined listener. An important feature of the HTTP Gateway is its ability to decode client requests and send the response back in the same requesting context-type. When HTTP Gateway is used with an HTTP Provider, Protected Methods and Allowed Users can be utilized in conjunction with the HTTP Gateway. In addition, you can add a transport guarantee (ie, require HTTPS). The HTTP Gateway uses a servlet in the implementation, it does not need an extra port to listen on, it will use the same port that the ESB is listening on (ie, 8080). The path to the servlet is http:// http://<host>:<port>/<esbname>/http/<URL Pattern>, you have the option of choicing the URL Pattern in the HTTP Gateway definition, you don't have to define it.
Now without any further ado, let's start up the JBoss Developer Studio 3.0, as a prerequisite you need a Web Service Project or an external Web Service available.
Step 1: Create a ESB Project, from the projects menu search for esb to find it, instead of looking thru the categories.
http://community.jboss.org/servlet/JiveServlet/showImage/2552/esb1.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2552/esb1.png
Step 2: Name the project, and define the ESB Runtime. Although you will be using SOA-P5, the ESB version is 4.7, it should default to that version. If not, you may not have JBDS 3.0. Also, SOA-P 5 uses EAP 5.0 as its runtime.
http://community.jboss.org/servlet/JiveServlet/showImage/2553/esb2.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2553/esb2.png
Step 3: At this point, the ESB Editor should be in the middle of the screen. This editor allows you to add most of the jboss-esb.xml functionality by point and clicking. We are going to start by adding a HTTP Provider in Step 4, so find the Providers section and right click New and then HTTP Provider.
http://community.jboss.org/servlet/JiveServlet/showImage/2554/esb3.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2554/esb3.png
Step 4: Name the HTTP Provider
http://community.jboss.org/servlet/JiveServlet/showImage/2555/esb4.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2555/esb4.png
Step 5: Name a Channel which will be referred to by the HTTP Gateway in the subsequent steps.
http://community.jboss.org/servlet/JiveServlet/showImage/2556/esb5.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2556/esb5.png
Step 6: Add a Service with a category and description.
http://community.jboss.org/servlet/JiveServlet/showImage/2557/esb6.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2557/esb6.png
Step 7: Add Global as the inVM parameter, this means that the service can be invoked in the same classloader.
http://community.jboss.org/servlet/JiveServlet/showImage/2558/esb7.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2558/esb7.png
Step 8: Add the HTTP Gateway and select the channel defined earlier from the select drop down list.
http://community.jboss.org/servlet/JiveServlet/showImage/2559/esb8.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2559/esb8.png
Step 9: In the URL Pattern box, pick a path for your service to be called by external clients.
http://community.jboss.org/servlet/JiveServlet/showImage/2560/esb9.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2560/esb9.png
Step 10: In the Actions section, right click and then Actions->Web Services ->SOAP Proxy
Here we specify an external wsdl or bring it in local to avoid external dependencies on startup.
http://community.jboss.org/servlet/JiveServlet/showImage/2561/esb11.png http://community.jboss.org/servlet/JiveServlet/downloadImage/2561/esb11.png
Step 11: Make sure the WSDL is located in the file location specified. Here we are using the META-INF folder as our WSDL location.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15171-6-2565... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15171-6-...
Step 12: Start the server and add the ESB Project to the server. At this point, any changes can be updated with a Publish from the Server tab.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15171-6-2566... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15171-6-...
http://community.jboss.org/servlet/JiveServlet/showImage/102-15171-6-2567... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15171-6-...
Step 13: With the server up and runing, open your favorite SOAP testing tool(SoapUI is used here), and add the Message body and verify that the ESB is accepting the message and proxying correctly.
http://community.jboss.org/servlet/JiveServlet/showImage/102-15171-6-2568... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-15171-6-...
Just a few notes on Performance tuning. Please review the guide on http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/5.0.1/html/Administra... Performance Tuning. There are some specific recommendations that will greatly improve your Performance with SOAPProxy. First, the the maxthreads for the service can improve the throughput under heavy load. Second, the HTTPClient Properties should be added to the SoapProxy, this is discussed in the http://www.redhat.com/docs/en-US/JBoss_SOA_Platform/5.0.1/html/Programmer... ESB Programmer's Guide of SOA-P 5.0.1. You can not add these via the ESB Tooling in JBDS 3.x. However, you can add these properties by viewing in the Source View, instead of the Tree view by clicking on the tab. Here is an example:
<service category="WS Proxies" description="A Order Web Service Proxy"
invmScope="GLOBAL" name="myService">
<property name="maxThreads" value="100"/>
<listeners>
<http-gateway busidref="myChannel" name="myHTTPGateway" urlPattern="/order"/>
</listeners>
<actions>
<action name="myProxy">
<property name="wsdl" value="classpath:///META-INF/order.wsdl"/>
<property name="file" value="/META-INF/httpclient.properties" />
</action>
</actions>
</service>
Here is an example of the httpclient.properties that We have seen better throughput for high load Performance Tests:
# Connection config
max-connections-per-host=100
max-total-connections=100
That's it! You are now ready to implement more Business Specific Use Cases with this Web Service Proxy as a base.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-15171]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - Tooling Support for Multiple Run time Versions
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"Tooling Support for Multiple Run time Versions"
To view the document, visit: http://community.jboss.org/docs/DOC-13335
--------------------------------------------------------------
http://community.jboss.org/docs/DOC-11954 <-- Back to SOA Tooling
Introduction
h1. Case Study
In this case study we examine key features of multiple Java VM support in http://www.eclipse.org Eclipse. We use this example not because it dictates how support for multiple versions of run times must be handled in every situation, but rather because it illustrates core design considerations for this problem.
Regardless of the Java version used to run Eclipse itself, the Eclipse Java development environment allows the user to configure which Java VM will be used for development. As will be seen below, a default choice is made for Java development, and this default can be overridden on a per-project basis.
Within the Java development environment preferences, there is a section for configuring Java run times:
http://community.jboss.org/servlet/JiveServlet/showImage/102-13335-5-1149... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13335-5-...
In this case, we have two Java VM versions available, with a 1.5 VM set as default. (Available Java VM run times actually can vary on two dimensions: version and vendor. In this example, we will concentrate on version differences, though the same applies to vendor differences as well.)
The user can add new Java VM options:
http://community.jboss.org/servlet/JiveServlet/showImage/102-13335-5-1150... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13335-5-...
Here I have added a Java 1.6 VM. Note that there are a number of archives (jar files) involved in the definition of a "Java 1.6 VM," and the tooling has determined these based on the location chosen. Also notice that adjustments to the archives list are possible (add, remove, etc.) using the buttons on the right-hand side.
Since a Java 1.5 VM is the default, a Java code using generics will compile without error and is supported by editor features such as code completion:
http://www.jboss.org/community/servlet/JiveServlet/downloadImage/1151/jav... http://www.jboss.org/community/servlet/JiveServlet/downloadImage/1151/jav...
The user can, however, change the Java VM level at the default or project level. For this example, I changed the Java VM level to 1.4 for the project only. Doing so results in a rebuild and errors displayed in the editor:
http://www.jboss.org/community/servlet/JiveServlet/downloadImage/1152/jav... http://www.jboss.org/community/servlet/JiveServlet/downloadImage/1152/jav...
With more detail in the Problem View:
http://community.jboss.org/servlet/JiveServlet/showImage/102-13335-5-1153... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13335-5-...
Although this example seems very simple and obvious, it does illustrate a number of features. In particular, we can ask how useful (and usable) the Eclipse Java development environment would be if:
* The user could not choose the Java VM for development. Perhaps instead the Java VM would be only the one used to run Eclipse, and hence the Eclipse launch configuration would need to be changed to switch Java VM run times.
* The user could not choose a Java VM version on a per-project basis. Instead the Java VM would be global, and changing it would impact all projects in the workspace.
* When adding a new Java VM option the user had to specify the set of archives by hand. That is, rather than thinking about add a "Java VM," the user had to think about adding a set of archives that together comprise the "Java VM."
* The Java editor was not aware of specific features in Java VM versions. Perhaps the Java editor would not support generics even though a Java 1.5 VM was is use.
* Switching the Java VM version for a project (or on a global default basis) did not register errors for code invalidated by the change.
* The Java editor and (Eclipse) incremental Java compiler did not show any compile errors, but when a application was run, the Java VM threw an error for invalid byte code.
Clearly these sorts of problems would seriously hamper efficient development of Java applications in Eclipse, and users would not consider the Eclipse Java tooling as particularly useful or usable. Luckily the Eclipse Java development environment does not suffer from these short-comings, and the relatively simple features in support of Java VM versions are keys in achieving this cohesiveness.
Design Considerations
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13335]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - Creating a JSR 181 Web Service using JBT/JBDS Tooling
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"Creating a JSR 181 Web Service using JBT/JBDS Tooling"
To view the document, visit: http://community.jboss.org/docs/DOC-14663
--------------------------------------------------------------
This document is meant to provide some simple, straightforward steps to illustrate how to create a JSR 181 web service that you can then mediate in the ESB.
1. In the JBT/JBDS tooling, open the JBoss AS Perspective.
2. In the Package Explorer view, right-click and select New->Dynamic Web Project or use the File menu and select File->New->Dynamic Web Project.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1832... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
3. Type "MyWebServiceProject" as the Project name.
4. If the Target Runtime is set correctly, just click Finish. Otherwise, specify an appropriate Target Runtime.
5. The "Open Associated Perspective?" dialog will appear if you are in the JBoss AS perspective. You can switch to the Java EE perspective if you want, but for now we'll stay in the Java AS perspective for these steps, so click "No."
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1833... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
6. Now we want to create our web service java class in our project. In the "src" folder of your new project, right-click and select New->Class.
7. Give the class an appropriate package, such as "org.jboss.lab" and the name "MyWebService". Then click Finish.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1834... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
8. The code for the class is pretty simple:
package org.jboss.lab;
import javax.jws.WebMethod;
import javax.jws.WebService;
@WebService()
public class MyWebService() {
@WebMethod()
public String sayHello ( String name ) {
return "Hello " + name + "!";
}
}
9. Save your class and go to the "WebContent/WEB-INF" folder in your project. Double-click on web.xml.
10. In the navigator on the left of the Web XML Editor, find and select Servlets.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1835... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
11. Click "Add..." in the Servlets section and in the dialog that appears, give it the name "MyWebServiceServlet" and give it the fully-qualified class name for our web service class - org.jboss.lab.MyWebService. Click Finish.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1836... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
12. Now click "Add..." in the Servlet Mappings section. In that dialog, give it the name "MyWebServiceServlet" and the URL-pattern "/MyWebService".
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1837... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
13. Make sure everything is saved (go to the File menu and select Save All if it's enabled) and now we'll deploy our web service to the server.
14. In the Servers view or JBoss Server View (deprecated in JBT 3.1/JBDS 3), right-click on your runtime server and select "Add and Remove Projects..."
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1838... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
15. In the dialog that appears, select your web service project and click "Add>" to move it to the "Configured Projects" list. Then click Finish.
16. If everything goes well, we should see in the console that our web service was deployed and a WSDL was created in the file system.
17. To verify that it deployed properly, open your web browser and direct it to URL - http://localhost:8080/jbossws/services http://localhost:8080/jbossws/services. (You may need to log in.) Once it comes up, you can see all the web services deployed on the server. Look for your web service "MyWebService" in the list.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1839... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
18. Now you can use a separate tool such as soapUI to try invoking your web service or the Web Services Explorer from WTP.
19. To use the Web Services Explorer...
* Make sure you are in the J2EE perspective, in the menubar, select "Run -> Launch the Web Services Explorer"
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1840... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
* The Web Services Explorer opens. There is a small toolbar in the upper right corner of the window. Click the "WSDL Page" button.
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1841... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
* When the WSDL Page opens, you will see a tree on the left with "WSDL Main" at the root. When you select the "WSDL Main" item in the tree, you will see a panel with "Open WSDL" to the right. Here you can provide a WSDL URL or WSDL file location. When you are finished, click on the 'Go' button.
* Now on the left, you will get a web service tree under the "WSDL Main" root. When you drill in and select your web service operation, you will see "Invoke a WSDL Operation." In the Body section, you'll see a list of arguments where you can provide values. Click Add to provide a value, input the value, and click the "Go" button when you are complete. (If your web service operation needs to input many arguments, you can click the 'Source' menu on the right-top of the right. Then you can give a soap message to the web service.)
http://community.jboss.org/servlet/JiveServlet/showImage/102-14663-7-1842... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-14663-7-...
* In the "Status" pane, you will see the reply message from the web service.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14663]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - JbdsRoadMap
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"JbdsRoadMap"
To view the document, visit: http://community.jboss.org/docs/DOC-11067
--------------------------------------------------------------
Roadmap for JBDS 2:
h2. Packaging
Reduce footprint - JBDS is huge at the moment (500+ meg), need to identify what is taking up all that space and if things could be stripped out. E.g. is it EAP filling up ? Can pack200 help ?
h2. Bundling JBoss EAP 5.0
JBoss EAP 5.0 is bundled and can be installed during installation.
h2. Better installer
Installer/JBDS that can configure against existing/different runtimes.
Because: Users might have existing runtimes and with SOA-P coming more configuration
is needed. Having a "Search..." facility like Eclipse has for Java runtimes would be good..
Note: JBoss EAP and SOA-P includes "multiple runtimes" in it self so would be good it would support that too ;)
h2. Update site for JBDS
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-11067]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - Maxs_Demon
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"Maxs_Demon"
To view the document, visit: http://community.jboss.org/docs/DOC-11384
--------------------------------------------------------------
h2. Max's Demon
* With apologies to, and interesting connections with, http://en.wikipedia.org/wiki/Maxwell's_demon Maxwell's Demon
* Named for http://in.relation.to/Bloggers/Max Max Andersen , since he feels strongly about this issue. :)
h3. Problem Statement
The artifacts desired by humans developing software often are very different from those most suited to computers executing the software. A simple example is the difference between Java source and byte code. A human creating software using Java technology could choose to write in byte code but, for a variety of reasons, finds Java source code easier. On the other hand, the Java Virtual Machine could, in theory, execute Java source code directly but, again for a variety of reasons, it is better to compile Java source code into byte code for execution. This probably seems completely obvious to developers, and hardly worth any effort to explain or consider. Lurking within this system, however, are a number of constraints that are often hard to satisfy in general, and which cause problems when the same pattern is applied to developer tooling in general.
h3. Background
For the purposes of this article, we will use the general (intentionally vague) term 'translation' to refer to cases where one artifact type is changed into another artifact type. 'Translation' is also called 'generation,' 'mapping,' or 'compilation.' For example, the Java compiler translates Java source code into Java byte code. The vagueness of 'translation' here will abstract away details such as whether the translation is done by the computer or by a human (or perhaps a mixture of both), when exactly the translation occurs (e.g. as a separate step during development or on an as-necessary basis during execution), and precisely what happens during the translation (e.g. what additional information is injected or what sorts of optimization are performed). Rather, the key notion for this article is that 'translation' means 'changing one artifact type into another.' Finally, and regardless of the reasons, we will assume that translation is required/desired in a number of cases.
Likewise, the term 'developer' is intended to be vague. We mean to include a range of skill levels/roles/experience within this general catch-all term. So, a 'developer' might be a Java programmer, a web programmer, or a business analyst (creating, for example, business process models or defining data transformations).
h3. Impact of Translation
The act of translation is not the final step in development, except in those exceedingly rare cases where software doesn't have any bugs, errors during execution, or other deficiencies (e.g. performance). Rather, it is often necessary to understand the execution state of one artifact in terms of the artifact that it was translated from. A simple example is a Java run-time exception: at a minimum the error message is expected to be human readable (not expressed in terms of byte code) and, in common development scenarios, further information (such as line numbers) is mapped back into the Java source code. This allows developers to understand Java run time errors in terms of the Java source code. It is difficult to imagine Java being as popular as it is if developers had to debug Java in byte code. Yet, situations similar to 'debugging in byte code' are not uncommon.
Java can enable developers to debug byte code in terms of Java source code because Java technology provides linkage from Java byte code to Java source code. That is, the translation between Java source and byte code is bidirectional. When can think of this as Java technology providing one translation from Java source to byte code and another translation from byte code to the Java source code that is was derived from (it is also possible, with varying degrees of success, to 'disassemble' Java byte code back into Java source code, but that is a slightly different topic).
What happens when the translation is not bidirectional? In short, +information is lost in translation+ (strictly speaking: information present during the process of translation is not preserved after the translation is complete). Because of this missing information, the translated artifact can not be understood, except at a general level, in terms of the source artifact. The developer is then thrust into the domain of the translated artifact. This is not appropriate: if the developer were willing to work in the domain of the translated artifact, then why not start there from the beginning?
h3. The Challenge
Imagine if when Java code is executed any errors or run-time monitoring details where expressed as an array showing the state of each bit in memory and on the CPU? Java developers would find this extremely difficult to accept and even the very few who did manage to learn debugging at this level would constantly need to switch from the problem domain (expressed in the Java source code) to the low-level machine domain. Clearly this would not be an acceptable situation.
The requirement from the above is simple to state, but hard to realize in practice:
* Translations for one artifact to another must be as closely bidirectional as possible.
Why 'as closely bidirectional' and not more strictly 'bidirectional?' Detailed examples are beyond the scope of this article, but there are often cases where only an approximate mapping for specific parts of the artifact is possible. (That is, 'bidirectional' does not mean 'one-to-one.') In these cases, every effort should be made to keep the relationship as close as possible.
The insidious aspect of translation problem is that is pushes developer tooling into extremes:
* Translation itself can be a hard problem, let alone the requirement for bidirectional support. The temptation then becomes to avoid these problems completely. Doing so, however, often means that developers are forced to work at a level that is not productive. (A common example: editing XML files is often seen as 'easy' except by those developers who do not know, and do not wish to know, XML.)
* Translation is done, but is not bidirectional. On the surface this looks better than the other extreme, since at least it allows developers to work at a more appropriate level. The illusion of productivity disappears the moment the developer has to interact with the translated artifact during a debug session.
Thus, the fundamental challenge that Max's Demon gives us:
* Write tools in the developer's domain, translate to run-time artifacts, and let the developer understand run-time execution state in terms of the developer's domain.
In the most general case, this is a very hard problem. Excellent tooling does not arise from avoiding challenges; it comes from managing complexities.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-11384]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - SOA-P 4.3 Configuration with JBDS 2.0
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"SOA-P 4.3 Configuration with JBDS 2.0"
To view the document, visit: http://community.jboss.org/docs/DOC-13380
--------------------------------------------------------------
With the excellent new SOA-P 4.3 tooling in JBDS 2.0 (ESB project wizard, jboss-esb.xml file editor, ESB quickstart example importer, jBPM project creator, and jBPM JPDL editor), creating SOA-P 4.3 applications has become much easier.
The first step to using these new features is to configure JBDS 2.0 to use a SOA-P 4.3 server instance. This wiki will demonstrate how to do that.
Prerequisites:
Install Java 1.5
Install SOA-P 4.3 GA
Install JBDS 2.0.0.CR1
First, we can just start the default JBDS 2.0 IDE.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1218... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
Now, we need to right-click in the "Servers" tab and add a new server.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1219... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
We'll change the server name to SOA-P as shown above and then need to add a new server runtime environment by clicking the "Add..." link.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1220... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
As shown above, we can give it a descriptive name, set the home directory to be the "jboss-as" directory in SOA-P 4.3, and pick our server configuration (I usually use the "all" configuration). Now click the "Finish" button to get back to the New Server dialog.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1222... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
We can select our new Server runtime environment as shown above and click the "Next" button.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1221... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
Again, we just click the "Next" button.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1223... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
If we had existing project to add to the SOA-P server, we could do that now, but we don't, so just click "Finish".
http://community.jboss.org/servlet/JiveServlet/showImage/102-13380-1-1224... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13380-1-...
That's it! Now we can just right-click on the server and start it and/or add projects to it like we would any other server.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13380]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - Using diffmk to add updated/added markers to TOC
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"Using diffmk to add updated/added markers to TOC"
To view the document, visit: http://community.jboss.org/docs/DOC-14256
--------------------------------------------------------------
← back to ../../docs/DOC-14250 How to write documentation for JBDS and JBoss Tools
In order to compare previous documentation with the current one and add update/added marker to TOC, we use DiffMk version 3.0.a1. tool.
We added two script files in the bin folder of the DiffMk distribution:
* run.sh
* run_mkdiff.sh.
The first is responsible for comparing 2 files and producing a third file with *diff* markers. The second one we use to indicate the files to compare and the output files, the format is the following: ./run.sh [+the path to the file+] [+the path to the file modified+] [+the path to the output file+]
To identify the changes between two different revisions of the same guide, use the following line: ./run.sh /path/to/the/old/revision/guide/master.xml /path/to/the/current/revision/guide/master.xml /path/to/the/produced/by/diffmk/master_output.xml
Next, run the run_mkdiff.sh
Actually, the DiffMk is not an ideal tool for comparing. It has a lot of lacks. Here are some of such lacks we run into:
* It removes the HTML entities when outputs the file, for instance & in the links;
* Sometimes it mixes the structure of the document, for instance, put the <chapter> into the <chapter>;
* Sometimes it deletes the tags such as <imageobject>.
Thus, in order the docs with diff markers could be built, the next step is validating and checking the master_output.xml files carefully.
To build the guide with updated/new markers on the TOC, chapters and sections and have the changes highlighted, use the 'diffmk' profile, i.e. the mvn clean install -P diffmk maven command.
To build the release version of the guide (for JBDS release) with updated/new markers on the TOC, use the 'releaseJBDS' profile, i.e. the mvn clean install -P releaseJBDS maven command.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14256]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - SOA-P 4.3 Workshop / Lab Examples
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"SOA-P 4.3 Workshop / Lab Examples"
To view the document, visit: http://community.jboss.org/docs/DOC-14353
--------------------------------------------------------------
JBoss SOA Platform is a collection of technologies designed to meet an organization's SOA needs. SOA-P includes an ESB, BPM engine (jBPM), Rules engine (JBoss Rules), UDDI Registry (jUDDI), as well as a full JEE application server. To cover each of these areas in depth is beyond the scope of this workshop. Instead, this workshop is designed to give you an overview of the SOA Platform as well as some experience using JBoss Developer Studio to create and deploy SOA-P applications.
Here are the labs covered in the attached workshop:
Lab #1: Install and Configure SOA Platform
Lab #2: SOA Platform Quickstarts
Lab #3: Installation of JBDS
Lab #4: Configure SOA-P in JBDS
Lab #5: Creating First ESB Project
Lab #6: Adding a Custom ESB Action
Lab #7: Installing SoapUI For WS Testing
Lab #8: Create a JSR 181 Web Service
Lab #9: Proxy Web Service with ESB
Lab #10: Adding XSLT to WS Proxy on ESB
Lab #11: Adding CBR to WS Proxy on ESB
Lab #12: Using jBPM
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14353]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
[JBoss Tools] - Documentation notes
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"Documentation notes"
To view the document, visit: http://community.jboss.org/docs/DOC-14255
--------------------------------------------------------------
← back to ../../docs/DOC-14250 How to write documentation for JBDS and JBoss Tools
*1. Project structure schema.*
In case you need to show some project structure in the documentation you should use the "tree" utility that builds in terminal the project structure that you can copy/paste to your docs. Quite likely that the "tree" utility is not installed on your local machine, the sudo apt-get install tree command will install this utility. You need to create the project structure schema in Linux since the tree command in Windows draws a tree that is not as nice as the one in Linux, besides Linux is our primary OS. However if you still need to draw a tree in Windows please use the tree /a /f command. This is what the project structure should be like.
|-- pom.xml
`-- src
|-- main
| |-- java
| | `-- org
| | `-- docs
| | `-- richfaces
| | `-- Bean.java
| |-- resources
| `-- webapp
| |-- WEB-INF
| | |-- faces-config.xml
| | `-- web.xml
| |-- index.jsp
| `-- pages
| |-- index.jsp
| `-- index.xhtml
`-- test
`-- java
`-- org
`-- docs
`-- richfaces
`-- BeanTest.java
*2. Inline graphics scale - 100%.*
When inserting an inline graphics element please leave it unscaled. If you scale a tiny inline element, the image will be broken and hardly readable.
*3. Doc build process speed up.*
Command line option for only creating part of the outputs to speed up roundtrip
See the issue for details https://jira.jboss.org/jira/browse/MPJDOCBOOK-7
*4. Task reviewing.*
When writing some article or component description or complicated section/chapter and need some review of it, let me know plz, and I’ll try to find a reviewer for you task.
*5. Text validation.*
E.g. letter “p” inside two opening tags (<section>p <title>… ) makes the document invalid and failes the build on this place. Do not forget to validate xmls each time you make changes.
*6. JBDS team. movies update.*
When updating the guides according to some dev issue, remember about our movies collection, it also should be updated.
*7. Inline graphics.*
Documenting UI, from time to time you talk about icons, mouse arrows that change depending on the user behavior etc. In these cases you can insert an image of the element into the documentation right into the text. DocBook allows you to embed inline graphics using:
<inlinemediaobject>
<imageobject>
<imagedata fileref="images/image1.png"/>
</imageobject>
</inlinemediaobject>
*8. Task resolving before a release.* https://svn.jboss.org/repos/jbosstools/trunk/documentation/jboss-tools-do... https://svn.jboss.org/repos/jbosstools/trunk/documentation/jboss-tools-do...
When you’re resolving a task, make sure that the person who will be closing the task, has enough time for its verification.
E.g. if you resolve the task in a release day it means that QA or a person who needs to verify the task, has no time for it, and also you won’t have time to fix the task if it’s reopened.
*9. "Fix version" of a jira issue.*
When closing or resolving a jira issue, make sure “fix version” is the correct one, it must correspond to the next release version, which could be found on project jira page on Version tab.
*10. JIRA issues resolution.*
When closing an issue, plz write some resolution as the last comment about what exactly was done.
*11. Para and programlisting.*
Don’t insert programlisting into para tags, it causes damaged code on a page.
*
*
*12. JIRA issues format.*All your tasks in JIRA should have versions and components defined.
*13. Image canvas size.*
When print-screening an image, please make sure that canvas size (uninformative white space around) of it is not to large, if yes, trim it.
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-14255]
Create a new document in JBoss Tools at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
13 years, 8 months
