Archive for the ‘Architecture’ Tag
On several occasions I have been asked about the possibility of integrating LiveCycle ES with UDDI to provide a standards based way of browsing LiveCycle services. Well I figured MAX2008 was a good motivator for getting such an integration working and so that is what I kicked off several weeks prior to MAX. I decided I would build a LiveCycle Component that allowed for both the publishing and querying of data to and from UDDI from within LiveCycle. Unfortunately, I quickly realized that there still seemed to be limited tooling around UDDI. So while, I could use a complete Java implementation of the UDDI specification from Apache, JUDDI, there was no easy means for me to browse the registry to show the results. This inevitably lead to the 2nd part of this proof of concept which was to build a UDDI browser with Flex. Note: there is an open source Java UDDI Browser available at http://uddibrowser.org/ that works well, however using it for a UDDI LiveCycle demo didn’t seem right for my purposes 😉
You can view an entire walkthrough at screencast.com Or the following lower res videos at YouTube.
So why did I create this demo?
- To provide a Proof of Concept for Integrating LiveCycle with UDDI
- To Discuss features and concepts around the LiveCycle Registry
- Learn How-to(s) with Flex and Web-Services (i.e. another excuse for me to improve my Flex chops)
IMPORTANT DISCLAIMER: This was a demo done as a proof of concept for which I am making the source code available. However note that the LC Component, and UDDI browser need a lot of fine tuning, which I have not and probably won’t have the time to complete anytime soon. The demo did accomplish its goal of proving that it is not only possibly but very feasible to integrate LCES with UDDI.
Below is a high-level diagram for the architecture of the UDDI/LCES proof of concept.
- JUDDI: A Java based implementation of the UDDI 2 Specification which was used for purposes of this demo. You can find more info about JUDDI at http://ws.apache.org/juddi/
- UDDI Component: A custom LiveCycle component deployed in a LiveCycle Instance capable of querying the LiveCycle Registry and publishing service meta-data to a UDDI Registry
- UDDI Browser: An AIR application for browsing Businesses, Services, and TModels in a UDDI Registry.
LiveCycle ES Registry
The “Collective” Registry within LiveCycle ES is made up of at least 6 sub registries that store meta-data around the components deployed within ES. The meta-data in the LiveCycle Registry is used at both Runtime (e.g. Service & version resolution) and Designtime (e.g. to build composite applications).
- Component Registry: Stores the base information relevant to a component such as component id, title, description, etc…
- DataType Registry: DataTypes are Java classes that are exported from a component and that can be leveraged by the LCES tooling
- PropertyEditor Registry: Property Editors are UI elements implemented in Java that control the visual rendering of types and properties within LiveCycle ES tooling.
- Connector Registry: Connectors are integration mechanisms that define a means by which to invoke a LiveCycle service. Example connectors include EJB Connector, SOAP Connector, and VM Connector.
- Service Registry: Maintains all the meta-data we have around services such as the signature of a service, description, hints, config values, etc…
- Endpoint Registry: Stores configuration necessary to bind a service to one or more connectors. This provides for the loose coupling between service implementations and the means by which they are invoked (i.e. Connectors).
Trying out the UDDI Proof Of Concept
Unfortunately, I have not setup an environment where demos such as this are available online.
For now however you will need to do the following steps:
- Download and install the LiveCycle trial (if you haven’t already) from http://www.adobe.com/devnet/livecycle/trial/.
Note: This demo was built on LCES Update 1 (also known as 8.2.1)
- Download the Source Code for a) the AIR app and b) the LiveCycle Java Component (i.e. uddi-dsc.jar) used from Download Source Code Note: uddi-dsc.jar contains the related Java code within
- With LiveCycle up and running go to LiveCycle Workbench and click on Window–>Show View–>Components. In the Components view you can right click the top node to then install the Java Components downloaded (i.e. uddi-dsc.jar) Note: You will need to configure the UDDI3Service by right clicking it in the components view, setting the user/password expected by JUDDI (‘admin’/” for me), and setting the publishAsHost & publishAsPort (used to fill int the WSDL URL in the UDDI Registry)
- Import the Flex Project included in the Download to your Flex Builder environment
- Run the AIR APP!
- Oh wait….. Before any LC Services are available in the UDDI Registry you need to invoke the UDDI2Service.publishLiveCycleService. You can do this from the “Components View” in Workbench, however, you need to first turn on the unsupported workbench option –> -Dcom.adobe.workbench.unsupported.dscadmin.invoke.enable=true in the workbench.ini file
Anyway, Good Luck! there is a lot to play with there.
Few more notes for those digging deeper:
- I packaged two modified WSDLs from which the WebService ActionScript stubs were generated within Flex Builder. I had to modify the WSDL to get around issues with the decoding of arrays.
- If you need to regenerate the WebService ActionScript stubs then you will need to modify the src/webservices/inquiry/BaseInquireService.as file to change the isWrapped properties of the WSDLMessages to false rather than true.
- The calls between LiveCycle and JUDDI seem to be slow on the perf side, but I haven’t drilled into that aspect as of yet