This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Seen in Product Version: NetBeans IDE Dev (Build 200708130000) Java: 1.6.0_01; Java HotSpot(TM) Client VM 1.6.0_01-b06 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb) Userdir: C:\Documents and Settings\lautz\.netbeans\dev (Sorry, should have caught this much, much earlier, but it wasn't obvious enough until I read the online help.) Screenshot of the current CASA Editor Palette is attached. There are 3 categories of palette items: -- WSDL Bindings -- subitems are different BC implementations, such as SOAP, HTTP, JMS, File, etc. -- Service Units -- subitem is External (JBI Modules are an implied subcategory, but can't be added from the palette) -- Endpoints -- subitems are Consume and Provide The use of "Service Units" here is incorrect and should be changed to "Services" or "Service Engines" for the following reasons: -- In JBI, Service Units are the subcomponents of a Service Assembly that specify and configure both Binding Component ports and endpoints and Service Engines. A category labeled of "Service Units" would have to include the WSDL Bindings as subitems as well as the External (services) to be consistent with the JBI terminology. -- JBI is all about separating the implementations from the configurations: Binding Components and Service Engines are the two types of implementation pieces. The Service Assemblies containing Service Units are the configuration files. We're mixing different types of artifacts in our palette labels. WSDL Bindings as a category goes with Services or Service Engines as a category. I have given this P2 priority, because it affects the CASA documentation and perhaps tutorials elsewhere, so the earlier this change is made the better. If the doc people don't mind dealing with such a change later, feel free to drop it to a P3.
Created attachment 46607 [details] Screenshot of CASA Editor palette
We have discussed these name issues in last year design review. There are different ways to interpret these CASA categories. The way we designed was: - dropping a wsdl binding of type (e.g., SOAP, JMS, and File) will create a wsdl port of that type in the composite application. These ports are elements of a service unit. - dropping a service uint of type (e.g., BPEL, XSLT, and SQL) will create a service unit of that type in the composite application. These are JBI service unit. "External" is used to identify all external service unit from other composite applications. (We have not not implement any internal SU type at this time.) - dropping an endpoint will create an endpoint in a service unit. Anyway, I don't think this is a P2 issue. I will drop it to P3 and work with Vince to reslove it in docs.
I'm sure I would have raised the issue had I been at the meeting . . . With further thought, I think my main concern is that the CASA editor doesn't spell out when it is defining service units and when it is not, and doesn't really represent a relationship between services and service units and applications and service assemblies. It seems like the user is expected to translate "composite application" -> "service assembly" and "WSDL binding configurations" and "service engine configurations" -> service units, but we don't lead them down that path very clearly. (And the docs can explain the heck out of it, but I'm one of 5 people who read docs. No offense intended to Vince.) "- dropping a wsdl binding of type (e.g., SOAP, JMS, and File) will create a wsdl port of that type in the composite application. These ports are elements of a service unit." This is true for all the ports of a particular type. There will be one service unit defined for each WSDL binding type, with perhaps multiple ports defined in the service unit. My point is that for each type listed under "WSDL Bindings" that is used in the composite application, there will be a separate service unit defined. Therefore, a "WSDL binding" also maps to an SU once a port is defined. "- dropping a service uint of type (e.g., BPEL, XSLT, and SQL) will create a service unit of that type in the composite application. These are JBI service unit. "External" is used to identify all external service unit from other composite applications. (We have not not implement any internal SU type at this time.)" Then I don't understand why we don't simply use the terms JBI and External "service units" in the Design view instead of modules? Consistency is good. (If we call them "Services" in both the palette and the Design view, then the term would be a bit abstract from the "service unit", but still correct, if someone thinks that "service unit" is user unfriendly -- can "modules" be something other than services?) I think I'm having a problem with the mixing the terminology of configuration/logical view of the application with the deployment/artifact view of the service assembly without a clear mapping of how the two worlds are related. (I keep having to look at the SA/SU files to keep my mind straight on this.) I'll be curious about how users respond to CASA. I'm going to reopen it as a P4 usability issue.
Yes, different people seeing/understanding things differently. Just like in NB5.5 review, xDesign insisted on us to change the term "service units" to "JBI modules". I did not understand their view, but had to accept it. However, I thought we did a good job in designing the CASA palette. The design was simply that: - in the WSDL Bindings category, there are SOAP (wsdl binding), JMS (wsdl binding), FILE (wsdl binding)... - in the Service Units category, there are External (service unit), BPEL (service unit), XSLT (service unit)... - in the Endpoints category, there are Consumes (endpoint), and Provides (endpoint) I am still not fully understand your objection to this design. May be you can explain your view to us in more detail later.