Hi,

when I create a new Java service, sometimes my service begins with

public static final Values JavaServiceName( Values in )
{
Values out = in;
…

and sometimes with

public static final void JavaServiceName( IData pipeline ) throws ServiceException
{
…

I have no idea why I get the first and why I get the second case sometimes. (I would prefer the first one…)

I thought it might have something to do with setting values in the Input/Output field, but that didn’t do anything.

Any help on that would be greatly appreciated!

Holger.

This is ostensibly controlled by the setting in Edit | Preferences on the Services tab. The Default Java service signature lets you set which style you wish to use.

Have you noticed the behavior you described when running Integrator/Developer on the same box? Or have you been running Integrator/Developer on different boxes and noticed the difference?

I would also like to mention that in the 6.0 release, "public static final Values JavaServiceName( Values in ) " will be obsolete…

so please start using “public static final void JavaServiceName( IData pipeline ) throws ServiceException” , to save time later on !!

Because the IData object is indiginous to the Integration Server and the Values object has been deprecated, all existing Values objects in Flow will need to be replaced by IData objects.

Regards,
Saurabh.

Hopefully this just means that the signature option will be removed and new Java services will always be created with the new signature. Eliminating support altogether for Values and forcing those that are upgrading to 6.0 change otherwise working and stable services would be a Bad Thing.

The Values-style services will still be supported and editable in IS 6.0. There will still be a property (now under Developer Tools | Options | Integration Serve | Java Editor) to select the default signature style.

We highly encourage using the new signatures for new services. There are two major advantages:

1. The concept of “pipeline” is better enforced. One cannot replace the pipeline object with another IData/Values object. This makes pipeline management cleaner throughout the Flow engine.

2. You can throw exceptions! Also it is possible in 6.0 to use the ServiceException constructor that takes [and wraps] another exception (this API was there in 4.6 but didn’t do wrapping). This wrapped exception will be returned to Java clients including Developer, making the exceptions thrown by services much more useful. By wrapping exceptions we are able to preserve information like localizedMessage and the locale resolution can be put off until the exception is put on the wire back to the client, so non-English users get a much better experience. I believe Japanese translation will be included in 6.0 on day one.

-Fred

Excellent! Thanks for the clarification Fred. I agree that new Java services should always use the new signature. There is no reasonable reason not to.

Great!! As long as Values-style services are supported in 6.0, I am a happy man.

editing problems in my previous post…

–quote—
Because the IData object is indiginous to the Integration Server and the Values object has been deprecated, all existing Values objects in Flow will need to be replaced by IData objects.
–quote-end—

This quote is from webMethods 6.0 release Conference Notes posted on wmusers or webMethods. So I guess the above quote is no longer valid.

regards,
Saurabh.

Yikes, I’ll take the blame on that one. I should have stated it more clearly.

"Support for older versions (i.e. 3.x, 4.x) will be extended for customers to allow for a phased-in migration to 6.0. "

That sentence should proably have come after the quote that Saurabh pulled out. Poor editing on my part.

Speaking of authorship, look for the next Ezine this Tuesday!