EJBs are core to our platform strategy it must be reasonably easy and consistent as to how to invoke them from any
project type we release:
for 5.2 that is CASA, BPEL and to a certain degree the classic caps project / BDRU.
An additional use case is that the change management must be reasonable as well, i.e. when a new method is added to
the EJB we must be able to pick up that change for project that use it.
BPEL: Invoke an EJB (within the same application or deployed separately)
BPEL project has added an extension to allow drag and drop use of the EJB (which is good), however the WSDLs get
generated and copied into the BPEL project without choice of referencing instead. This becomes an issue with
consistency accross the suite where we should have the choice of referencing WSDLs to make change management more
straight forward for the user - they don't have to go copy the WSDL to other places or remember to refresh them in the
* It requires the user to explicitly know that a WSDL was copied behind the scenes and they need to find the WSDL and
hit "refresh" if the original WSDL changed
* BPEL does support referencing WSDLs/XSDs in other projects, but it is a very manual process and the EJB drag & drop
is not available
o It does not seem to work for EJB projects, also issues
experienced referencing other BPEL projects (?)
o The manual process requires to manually go and generate the
EJB WSDLs via the hidden ant task (see CASA steps to do so)
go to project properties, add an explicit project reference
to the EJB project. Create new WSDL with partner links.
Manually add an import in that WSDL to the EJB WSDL.(this
actually create an IllegalArgumentException on my machine,
so I can't continue there). One would probably change this
wrapper WSDL to have the partnerlink type point to the EJB's
porttype, remove the automatically generated porttype. Use
this partnerlink/WSDL manually in the BPEL.
Overall the requirement is that is should be possible to choose to reference the WSDL from the EJB rather than copy
it, with the appropriate dependency guarantees and change management to make sure users are aware of the BPEL
dependency whan re-factoring the EJB/WSDL and to allow the BPEL project to use the new WSDL.
The existing option of making a copy should still be an option, but users should be explicitly made aware that they're
copying and that they need to manually refresh if there are changes.
The above needs to be consistent behavior accross the suite, not just BPEL.
Current implementation is working as intended. Whole story with adding cross-project references and linking artifacts
across the projects instead of copying will be reviewed in next release.
The feature has been already implemented: it uses a reference to wsdl from EJB instead of copy.
This issue has been verified with an Master Index application EBJ that is exposing a set of web services. The
EJBService was DnD'd into the swimlane of a target BPEL process.
The results were:
a) An EJBServiceWrapper WSDL was generated.
b) The EJBServiceWrapper WSDL was imported
c) An "import" element for the EJBServiceWrapper was inserted into the BPEL code.
d) An "partnerLink" element for the EJBServiceWrapper was inserted into the BPEL code.
e) An EJB WSDL reference was generated for the EJBService WSDL was made in the target project.
f) An "import" element for the EJBService WSDL was inserted into the BPEL code.
With the NetBeans IDE 6.5.1 (Build 200903201801), this ticket is closed.