What is the Endpoint of a Web Service Deployed on GlassFish Server ?

This evening, I was trying to play a little bit with GlassFish server to familiarize myself with it. I created a simple web service and deployed it to the server.

I followed the top-down approach by creating a wsdl, generating the stub code and writing my logic in the Impl class. I then deployed it to the server. When it came to testing the service, it took me some time to figure out what the endpoint of my web service was.

Here is where you can find the endpoint: Even though you have given a different address in the location element of the wsdl that you used to generate the stub, this address is overwritten in the wsdl file that is generated when you generate the stub code. Look under <Project Root Folder>/WebContent/WEB-INF/wsdl/<PortName in your WSDL>.wsdl for the new address as shown in the picture.

Web Service Endpoint - GlassFish Server 3.1

It looks like the endpoint for both top-down and bottom-up approaches will be in the following format
http://<Host>:<Port>/<Application Name>/services/<Port Name in your WSDL>

Free IPhone and IPad App development Course by Mr. Paul Hegarty (@ Stanford Univ.)

Absolutely love this course!! I should mention that i greatly admire Mr. Hegarty for his style of teaching. A must go thru for any one who is trying to learn development of iOS applications.

If you have access to iTunes, click "iTunes store" in the navigator > "iTunes U" (on the drop-down arrow) in the menu > select "Universities & Colleges" > select "Stanford" > In the "All Courses" section, click on "See All" and select "iPad and iPhone App Development (Fall 2011)" [Try and select the course that is latest].

You should be able to view all of the course material.

For more info and course material, visit Mr. Hegarty's blog

Good Luck with your "iDevelopment"!

DataPower: Flushing Stylesheet Cache.

Summary: Why aren’t my changes to the stylesheets being picked up by DataPower? Learn about the stylesheet cache in DataPower and what you should do to refresh the cache.

DataPower appliances maintain a cache of the stylesheets that are being used on the appliance for performance reasons. "Although the cache is configurable, disabling the cache might degrade performance. DataPower caches compiled stylesheets and if the cache is disabled the stylesheets will have to be compiled every time they are used." - [1]

Ever get into a situation where you have made a change on an imported/included stylesheet on DataPower and when the stylesheet was run, you did not see the changes you made being reflected in the results?

The reason is that DataPower fetches all the content from top level stylesheet with any imported and included stylesheets and after compilation stores it in the cache as one single compiled stylesheet. If you make changes to one of the imported/included stylesheets, DataPower does not detect the change and the recompilation and refreshing the same in the cache is not triggered.

In such scenarios, for the changes to be reflected, you could do two things

1. You could flush the stylesheet cache. One way of doing this would be to use the WebGUI administrative interface. In the GUI select objects/XML Processing/XML Manager. Select the respective xml manager and to the top right corner you should see option called “Flush  Stylesheet Cache”.



DataPower: Flush Stylesheet Cache

2. You could introduce an empty line in the top level xslt and save it. This will trigger recompilation of that top level stylesheet effectively recompiling the imported/included stylesheets also.

 “At compile time all imported and included stylesheets are fetched and the complete compiled top level stylesheet is then cached. You can't see the imports and includes but they are all there under the top stylesheet.” – [2]

“Disabling the cache can be performance concern and might not be your goal. When style sheets are not cached, an XSLT compilation is run on every single transaction.

If you need to disable stylesheet caching, create a separate XML Manager for the particular service wherestylesheet caching is not required.

Do not disable stylesheet caching for a widely used XML Manager. For example, do not disable caching on the default XML Manager.” – [1]

References:

[1] WebSphere DataPower Intehgration Appliance version 3.8.1 - Information Center

[2] IBM Developer Works post regarding stylesheet cache

WSRR Migration Best Practices

Summary:
Websphere Service Registry & Repository (WSRR) is useful to register reusable Business Services and serves as a centralized repository to capture all metadata related to Service Lifecycle, Configuration and Deployment.


Purpose
This document aims to shed light on some of the WSRR migration issues from version 6.x to v7 and v7.5. WSRR v7 offers major improvements compared to previous versions in different areas such as performance, enhanced governance lifecycle, ontology support etc. To quote an example, we have seen significant improvements related to import and export of documents from Web UI after migrating to WSRR v7. So there are a handful of very good reasons to migrate to the newer version.

Migration Path & Best Practices:
A medium-size or large enterprise typically will have separate environments for Development, Testing and Production activities. The challenge is to accomplish migration of all environments minimizing the repetition of same tasks for each environment, thereby reducing the overall time to complete migration.
We have also taken into account future needs of the WSRR, as the Enterprise’s SOA Adoption Strategy evolves. The chosen migration path should be reusable for any enhancements to be done in future on WSRR dataset.
 
Upgrade In-place vs. New Install & Copy Dataset
Given both options for a typical migration project, I would prefer new install & copy of dataset. This is lesser error-prone, risk-free approach and would allow leveraging all new features available with the newer version after migration. To eliminate the confusion, IBM does not offer a solution to upgrade “In-place” in the case of WSRR. Instead, recommends a 2-step process for a successful migration.

Migration Tasks

Profile Migration:
•    Capture profile in source repository using WSRR Web UI. Choose Configuration perspective, profile export option.
•    Load the exported profile into target WSRR. 

Note: If errors are encountered during the import, modify the profile using WSRR v7 Studio. Import the updated profile into WSRR v7.

Ontology Migration:
For this, ‘upgradetool.sh’ should be used. It involves the following 2 tasks.
i)  Export the dataset. This will create a cloudscape database dump file.
ii) Import the dataset. 

For a dataset with 200 documents and around 100 concepts, export took almost 40 hours. There were errors at the end of the long wait. We have to manually fix these errors using WSRR utility code developed in-house.

Why Cloudscape database is needed?
It might be useful if the database type of target WSRR v7 is different from source WSRR v6.x such as from SQL Server to Oracle or vice-versa. However, for most of the ESB Environments, it is unlikely to change the database type from one to another and breaks 80-20 rule. It adds unnecessary complexity to the overall migration process.

The following 2 approaches were considered for Migration.
 
Option A (Repeat Migration Tasks for each Environment):
•    Migration of WSRR v6.x DEV to WSRRv7 DEV.
•    Repeat this for 2 times to complete migration for QA and Production environments.

Option B (Migrate only once; leverage WSRR API features):
•    Migration of WSRR v6.x DEV to WSRR v7 DEV.
•    Reconcile dataset from QA and Production to WSRR v7 DEV using the WSRR client API. This will provide a good baseline dataset to setup Governance Repository in future.
•    Develop WSRR client code to modify / migrate metadata using WSRR API. It is fairly simple and should not take longer time to develop.
•    Build datasets for QA and Production from WSRR v7 DEV dataset using export utility available in WSRR v7 after classifying the dataset as DEV / QA / Production.
•    Import dataset into QA.
•    Import dataset into Production. 

Decision Taken: We have used Option B for migration instead of Option A and successfully completed the Migration ahead of time.