The problem:

I created a WCF service library and was able to consume it in a web site on my local machine and call the functions within the service library via creating a proxy class that was generated via svcutil.exe.  I moved the .svc, .config and /bin to my development server and tried to access the .svc and noticed that the reference exposed was to the machine name of the server rather than the ip that I was expecting.  Because the server is not on the domain, I am unable to access the references from my local machine.

The solution:

Thanks to the linked blog below I found one solution in which I can set the IIS Site Binding that will allow the service to use this as the base address.  A link to this blog is http://blogs.msdn.com/wenlong/archive/2007/08/02/how-to-change-hostname-in-wsdl-of-an-iis-hosted-service.aspx.

Follow up:

I’m not sure why this isn’t a setting in the config file.  I’m still looking into this.  Here are some posts on the issue at Stackoverflow.com http://stackoverflow.com/questions/1925519/net-wcf-service-references-use-server-name-rather-than-ip-causing-issues-when-co and http://stackoverflow.com/questions/1941900/wcf-hosting-service-in-iis-machine-name-automattically-being-picked-up-by-wcf and http://stackoverflow.com/questions/1220904/how-to-bind-wcf-service-to-ip-address

Petals Master v1.0, the first official version of the Petals governance tool has been finally released on OW2 today. Here is the quick release note from the Team :

Petals Master 1.0, includes a lot of improvements for users, as well as optimisations, and nice new features :

• Categorize your services, endpoints and enterprises with UDDI based categories or add your own categorization value sets
• Community capabilities : Share ratings, tags and comments on registered services and endpoints with all users
• Share additional information about services by uploading related documents. Supported related document types are: DOC, PDF, XML, HTML, XLS, PPT, TXT, RTF, ODT, ODS, ODP
• Identify your Enterprises with UDDI based identification system (Thomas Register, Dun and Bradstreet (DUNS)), or add your own identification system)
• Search registered entities with a UDDI V2/V3 compliant Inquiry WS API
• Do all what you can do with Petals Master UI with the Petals Master specific WS API
• SLA Management is disabled, but will be back soon, with lots of improvements: SLA enforcement, service contract creation and management based on information collected on execution environments
• Integration with new Petals ESB v3.0 Camelia edition: Govern services and endpoints deployed in Petals ESB by just providing Petals ESB specific WS address and click “synchronize”. That’s all !

As mentioned, this tool is integrated with Petals ESB v3.x, so now you can govern services from your Entreprise Service Bus.
There are also several new tools which are connected to Petals ESB, I think that more news will come soon…

I have spent some time figuring out why I could not see any WSDL despite everything else seemed to be OK.

After having followed these kind of steps: Creating web services with Eclipse (Bottom up) it appears that I could not see any WSDL.
So I have typed http://localhost:8080/Axis2/axis2-web/index.jsp , then clicked on services and the following screen was displayed:

Axis main screen

The service  - Converter – seemed to be running ! but when trying to reach the WSDL by clicking on the Converter link I had this:

WSDL page

After some experiments I have found that the WSDL was actually correct (!) . it was just not displayed in Safari. Running the same URL on Firefox confirmed it.

It’s not the first time something is hidden by Safari unfortunately. It seems it waits a really clean html code. It’s still viewable by clicking on view-> view Source but you don’t expect immediately such a thing to happen.

In my last article I hinted about investigating the use of an open source tool in support of my current employment.  I won’t go into details about the use case itself but I will gladly describe the tool and its potential.  First, a little background.

The Need

As noted in previous articles, a large part of my work the past several years has been in information management, specifically product and application configuration.  I’ve so far had the pleasure of leading and supporting work on two major enterprise rollouts of workflow solutions, each employing different commercial offerings and approaches to implementation.

The first project addressed a huge gap in product data and change management for consumer products development.  PTC Windchill was selected for the workflow solution based on its own strengths and helped by the fact that PTC product engineering applications were already in use.

The next project at a later employer involved replacing a claims handling application with a true process workflow solution.  Serena Business Mashup (SBM) was selected over competing products due to its rich feature set and seemingly unlimited extensibility.  I found the development environment (Mashup Composer) to be flexible, powerful and intuitive.

Both projects were very successful in streamlining and improving the ability of stakeholders to view end-to-end processes and manage events in their domains.  The commercial products involved proved their value although expenses were certainly significant.

An Open Alternative

In my current employment I am once again faced with the need to improve management of an enterprise activity, except that the prevailing economic decline prevents the sort of corporate funding that had been required for the other two projects.  This led me to search for low cost or even free solutions.

I found several tools that looked promising, but just about every search highlighted one in particular: the open source ProcessMaker.  Glowing write-ups such as this one by Python Developer’s Journal gave the impression that this free tool just might be close enough to WindChill or SBM to significantly improve our change management process.

The Short Take

ProcessMaker is 100% web-based and managed at popular open source hoster SourceForge.  The PM website states that its code “… is licensed under the GNU Affero General Public License version 3”.  It is provided in Windows and Linux versions.

I downloaded and installed the latest Windows version (1.2-2865) to my work laptop running XP.  The installation included MySQL and the Apache web server.  The first installation attempt hung up on the Apache portion at the end, but the second try went smoothly.  I’m not sure what happened (or didn’t happen) the first time.

I’ve barely explored what ProcessMaker can do and yet so far I am impressed.  While its mashups have not yet reached the number that one can access for Serena’s offerings, the same potential is there and hopefully the open source community is already at work developing more to be shared.  ProcessMaker supports Web Service Definition Language (WSDL), enabling a process developer to integrate numerous off-the-shelf applications that provide similar access.

The interface is clean and fairly easy to navigate.  However, I could see immediately that I’ll have to read the documentation and/or follow tutorials before being able to develop a useful process model.  Still, by sheer intuition alone I was able to create a new user, associate him with a group, install a sample weather report mashup and run the activity successfully.  This speaks well for the UI design.

I did find some minor but obvious phrasing issues in some areas, possibly reflecting ProcessMaker’s international heritage (Colosa has offices in New York, Bolivia and Peru and partners with a Danish IT firm) but they were not showstoppers.  Indeed, even in my untrained fumbling I did not run into anything that raised any real concerns.

ProcessMaker has recently brought data table creation and management to its set of features, bringing it closer to its commercial peers.  I’m eager to test this particular addition and see how it stacks up against Mashup Composer’s robust equivalent.

Bottom Line

 WindChill was the first purely Internet-architectured data management and collaboration tool, so by now (version 9.1) it’s very mature.  Too much time has passed since I worked with WindChill so I couldn’t do a post mortem justice.  I do recall that it easily handled everything we threw at it and integrated well with our other enterprise systems… SAP, BPCS et al.  It’s strictly a commercial offering.

Serena’s Business Mashup solution certainly has the power to wire together any silos across an enterprise landscape.  Serena has taken a hybrid approach in this space, offering a closed commercial product supported by a growing collection of popular user-developed mashups.

ProcessMaker, however, is completely free and open so that the developer community can create and push upstream additions and improvements not only to mashups but also the core product.  Colosa, the group behind ProcessMaker, charges only for training, hosting and other support.

There’s nothing wrong with PTC’s and Serena’s commercialization of course but lately I’m coming to believe more and more that ProcessMaker’s open mode is that of the future… assuming of course it reaches the critical mass necessary to attract enough mashup developers.  My initial take is that it definitely has the potential.

I plan to continue exploring that potential and expect to do at least one more general follow-up once I’m more familiar with the product… hopefully soon!

Over the last 2 years I have worked on a number of CXF projects. In this time frame I alternated between WSDL first and Java first methodologies. Each have benefits but I think I have finally settled on a preferred solution. First lets weigh up the two options.

WSDL First

This is the classic purists solution. It ticks all of the boxes for large project design, laying down a language agnostic contract for interfaces in advance. You can hand-craft your WSDL file, simultaneously give it to the service team and any other interacting teams (be it UI or up/down stream apps), everyone can develop to it and in the end everything can be plugged together and it just works (yeah right!).

Pros & Cons

Java First

This is solution suits the agile developer must better, the service can evolve over time as new functions are added and existing ones modified. The code can be more intuitively updated as it is not an all-or-nothing generation. Most importantly the communication objects can be more than just PJOs, they can contain custom business logic functions as they will not be blown away the next time they are generated.

Pros & Cons

Conclusion

After a number of projects I now favour the Java first solution this is for a number of key reason:

1. I like being able to use my CXF objects in business logic and tie them to Hibernate via Annotations
2. I find I rarely can define a complete interface at the beinning of a project and regeneration from WSDL is a pain
3. Java first allows me to use more complex data structures (like maps)
4. I dislike the way WSDL to Java generates container classes for any collections of objects

However, beware of the following pitfalls:

1. You neeed to use the @WrappedElement attribute to ensure that collections are compatible with Flex (and look reasonable)
2. Be careful with namespaces
3. If possible don’t return Dates (compatibility issues with Flex and C#)

If you have a java object marked with the attribute @XmlElementRoot you can convert it to an XML string like this:

            JAXBDataBinding binding = new JAXBDataBinding();
            JAXBContext jc = JAXBContext.newInstance("com.groupgti.esb.jobengines.email.service.groupgtisupportsystem.emailschedulertarget" );
            Marshaller marshaller = jc.createMarshaller();
            StringWriter writer = new StringWriter();

            marshaller.marshal( javaObject, writer );
            System.out.println( writer.toString() );

This does not work quite so simply if the object is not marked with @XmlElementRoot – which means that marshalling an arbitrary object received via a SOAP interface needs a bit more work:

            JAXBDataBinding binding = new JAXBDataBinding();
            JAXBContext jc = JAXBContext.newInstance("com.groupgti.esb.jobengines.email.service.groupgtisupportsystem.emailschedulertarget" );
            Marshaller marshaller = jc.createMarshaller();
            StringWriter writer = new StringWriter();

            marshaller.marshal( new JAXBElement( new QName( "http://xml/namespace/for/type", "XMLType" ), JavaClass.class, javaObject ), writer );
            marshaller.marshal( object, writer );
            System.out.println( writer.toString() );

You can unmarshall (from XML string to java object) like this:

            StringReader reader = new StringReader( xmlString );
            Unmarshaller unmarshaller = jc.createUnmarshaller();
            JAXBElement< JavaClass > root = unmarshaller.unmarshal( new StreamSource( reader ), JavaClass.class );
            JavaClass javaObject = root.getValue();
            System.out.println( "Read back as " + javaObject.toString() );

If you want to change the namespace prefix used when marshalling you can override the NamespacePrefixMapper like so:

    private class NamespaceMapper extends NamespacePrefixMapper
    {

        @Override
        public String getPreferredPrefix( String namespaceUri, String suggestion, boolean requirePrefix )
        {
            if( "http://xml/namespace/for/type".equals( namespaceUri ) )
            {
                return "MINE";
            }
            else
            {
                return suggestion;
            }
        }
    }

...
            marshaller.setProperty( "com.sun.xml.bind.namespacePrefixMapper", new NamespaceMapper() );
            marshaller.marshal( new JAXBElement( new QName( "http://xml/namespace/for/type", "XMLType" ), JavaClass.class, javaObject ), writer );

You can also try to force the use of the default namespace by returning an empty string from the getPreferredPrefix function.
Unfortunately there is a small bug in JAXB in that it uses the namespace prefix blindly for namespace qualified attributes – but XML does not consider unqualified attributes to be in the default namespace.
If you use qualified attributes don’t try to force CXF/JAXB to use the default namespace.

When writing web services it’s quite common to need to represent an array of some custom type.
For this example I’m working with a “Box” that contains an array of “Thing” elements (it’ll also contain a “Colour” element, for reasons that will become clear).
Each “Thing” element has to have an attribute (“name”).

There are two basic ways of doing this in XML:

<Box>
  <Thing name="Thing 1"/>
  <Thing name="Thing 2"/>
</Box>

<Box>
  <Things>
    <Thing name="Thing 1"/>
    <Thing name="Thing 2"/>
  </Things>
</Box>

When we prepare the schema for representing these structures we have two options: use an inline complex type or use a top level named complex type.

<xsd:element name="Box">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element name="Thing" minOccurs="0" maxOccurs="unbounded">
                <xsd:complexType>
                        <xsd:attribute name="name" type="xsd:token"/>
                    </xsd:complexType>
            </xsd:element>
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

<xsd:complexType name="BoxType">
  <xsd:attribute name="name" type="xsd:token"/>
</xsd:complexType>
...
    <xsd:element name="Box">
      <xsd:complexType>
        <xsd:sequence>
          <xsd:element name="Thing" type="BoxType" minOccurs="0" maxOccurs="unbounded"></xsd:element>
        </xsd:sequence>
      </xsd:complexType>
    </xsd:element>

So we have a total of four options for what to put in our schema.
The question is, which is best?
For my purposes the answer is based on which gives the best representation as XML and when converted into java (by wsdl2java) or c# (by wsdl.exe).

What do I want to see?
Well, what I don’t want are things like this:

List<Things> things = Box.getThings();

List<Thing> things = Box.getThings().getThing();

List<Thing> things = Box.getThing();

<Box>
  <Things name="Thing 1"/>
  <Things name="Thing 2"/>
</Box>

Although the examples above are java, I have the same requirements from C#.
So, four options, and three things to look at for each one.

Bare, Inline complex type

The schema:

            <xsd:complexType name="TricksResponseType">
                <xsd:sequence>
                    <xsd:element name="Box">
                        <xsd:complexType>
                            <xsd:sequence>
                                <xsd:element name="Colour" type="xsd:token"></xsd:element>
                                <xsd:element name="Thing" minOccurs="0" maxOccurs="unbounded">
                                    <xsd:complexType>
                                            <xsd:attribute name="name" type="xsd:token"/>
                                        </xsd:complexType>
                                </xsd:element>
                            </xsd:sequence>
                        </xsd:complexType>
                    </xsd:element>
                </xsd:sequence>
            </xsd:complexType>

The XML:

      <cat:TricksResponse>
         <Box>
            <Colour>?</Colour>
            <Thing name="Thing 1"/>
            <Thing name="Thing 2"/>
         </Box>
      </cat:TricksResponse>

Java usage:

{
    TricksResponseType response = hat.getTricks( null );
    Box box = response.getBox();
    String colour = box.getColour();
    List< Thing > things = box.getThing();
}

C# usage

{
    TricksResponseType response = svc.GetTricks( null );
    TricksResponseTypeBox box = response.Box;
    string colour = box.Colour;
    TricksResponseTypeBoxThing[] things = box.Thing;
}

What’s wrong with that?
Well the XML representation is as good as we can get, it’s concise (it doesn’t need a pointless wrapper) and the elements have a nice singular name.
The downside is that the properties in java and C# are singular, and they shouldn’t be.

Bare, Global complex type

The schema:

<xsd:complexType name="ThingType">
    <xsd:attribute name="name" type="xsd:token"/>
</xsd:complexType>

<xsd:complexType name="TricksResponseType">
    <xsd:sequence>
        <xsd:element name="Box">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="Colour" type="xsd:token"></xsd:element>
                    <xsd:element name="Things" type="tns:ThingType" minOccurs="0" maxOccurs="unbounded"></xsd:element>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
    </xsd:sequence>
</xsd:complexType>

The XML:

<cat:TricksResponse>
    <Box>
        <Colour>?</Colour>
        <Things name="Thing 1"/>
        <Things name="Thing 2"/>
    </Box>
</cat:TricksResponse>

Java usage:

{
    TricksResponseType response = hat.getTricks( null );
    Box box = response.getBox();
    String colour = box.getColour();
    List< ThingType > things = box.getThings();
}

C# usage

{
    TricksResponseType response = svc.GetTricks( null );
    TricksResponseTypeBox box = response.Box;
    string colour = box.Colour;
    ThingType[] things = box.Things;
}

Well that’s tidied up the java and C# representation, but made a total mess of the XML.
Notice that the name of the customType is seen in both java and C#, but is not seen at all in the XML itself.

Wrapped, Inline complex type

The schema:

<xsd:complexType name="TricksResponseType">
    <xsd:sequence>
        <xsd:element name="Box">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="Colour" type="xsd:token"></xsd:element>
                    <xsd:element name="Things" minOccurs="1" maxOccurs="1">
                        <xsd:complexType>
                            <xsd:sequence>
                                <xsd:element name="Thing" minOccurs="0" maxOccurs="unbounded">
                                    <xsd:complexType>
                                        <xsd:attribute name="name" type="xsd:token"/>
                                    </xsd:complexType>
                                </xsd:element>
                            </xsd:sequence>
                        </xsd:complexType>
                    </xsd:element>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
    </xsd:sequence>
</xsd:complexType>

The XML:

<cat:TricksResponse>
    <Box>
        <Colour>?</Colour>
		<Things>
            <Thing name="Thing 1"/>
            <Thing name="Thing 2"/>
		</Things>
    </Box>
</cat:TricksResponse>

Java usage:

{
    TricksResponseType response = hat.getTricks( null );
    Box box = response.getBox();
    String colour = box.getColour();
    Things things = box.getThings();
    List< Thing > thingList = things.getThing();
}

C# usage

{
    TricksResponseType response = svc.GetTricks( null );
    TricksResponseTypeBox box = response.Box;
    string colour = box.Colour;
    TricksResponseTypeBoxThing[] things = box.Things;

}

Well now this is interesting – the XML has gained an unnecessary wrapper, but maybe I can live with that if it makes the generated code look good.
But see how the C# code is almost perfect (the type name is messy, but the pluralities are perfect) whilst the java code is horrid.
This bonus for the C# is because the .net wsdl.exe code generator short circuits elements that only have one child element.
Worth noting that C# has to generate a nasty name for the ‘Thing’ type, whilst java (with ubiquitus namespaces) is able to provide a much nicer name.

Wrapped, Global complex type

The schema:

<xsd:complexType name="ThingType">
    <xsd:attribute name="name" type="xsd:token"/>
</xsd:complexType>

<xsd:complexType name="TricksResponseType">
    <xsd:sequence>
        <xsd:element name="Box">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="Colour" type="xsd:token"></xsd:element>
                    <xsd:element name="Things" minOccurs="1" maxOccurs="1">
                        <xsd:complexType>
                            <xsd:sequence>
                                <xsd:element name="Thing" type="tns:ThingType" minOccurs="0" maxOccurs="unbounded"></xsd:element>
                            </xsd:sequence>
                        </xsd:complexType>
                    </xsd:element>
                </xsd:sequence>
            </xsd:complexType>
        </xsd:element>
    </xsd:sequence>
</xsd:complexType>

The XML:

<cat:TricksResponse>
    <Box>
        <Colour>?</Colour>
		<Things>
            <Thing name="Thing 1"/>
            <Thing name="Thing 2"/>
		</Things>
    </Box>
</cat:TricksResponse>

Java usage:

{
    TricksResponseType response = hat.getTricks( null );
    Box box = response.getBox();
    String colour = box.getColour();
    Things things = box.getThings();
    List< ThingType > thingList = things.getThing();
}

C# usage

{
    TricksResponseType response = svc.GetTricks( null );
    TricksResponseTypeBox box = response.Box;
    string colour = box.Colour;
    ThingType[] things = box.Things;
}

This structure provides a perfect solution for the .net users, but the java users are still lumbered with the intermediate object.

Conclusions

The first conclusion is that the use of wrapper objects, handled so nicely in C#, is really ugly in java so I recommend against using it at all.
The benefit of having control over the name makes global complex types nicer to work with in both C# and java.
But this leaves a problem with the plurality, it’s going to end up being wrong in either the XML or the code.
I think it’s more important to be right in the XML, so I’ll be using the schema from my first example.

In case you think the C# wsdl tool is much better than the java one from this please bear in mind that wsdl2java can work with abstract wsdl files, whereas the C# equivalent generates nothing unless the WSDL file has a concrete service defined – which is rubbish.

Problem

JAXB is great for generating JAVA code necessary to support marshalling and unmarshalling of XML to Java Pojo’s particularly when working with web services. However with some WSDL’s the Java code generated contain JAXBElement types instead of Java data types. For example a schema fragment from a Salesforce notification wsdl:

        <schema elementFormDefault="qualified" xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="urn:sobject.enterprise.soap.sforce.com">
            <import namespace="urn:enterprise.soap.sforce.com"/>
            <!-- Base sObject (abstract) -->
            <complexType name="sObject">
                <sequence>
                    <element name="fieldsToNull" type="xsd:string" nillable="true" minOccurs="0" maxOccurs="unbounded"/>
                    <element name="Id" type="ent:ID" nillable="true" minOccurs="0" maxOccurs="1"/>
                </sequence>
            </complexType>
            <complexType name="Opportunity">
                <complexContent>
                    <extension base="ens:sObject">
                        <sequence>
                        <element name="Sales_Opportunity_Number__c" nillable="true" minOccurs="0" type="xsd:string"/>
                        </sequence>
                    </extension>
                </complexContent>
            </complexType>
        </schema>

would generate the following corresponding Java code fragments:

public class Opportunity
    extends SObject
{

    @XmlElementRef(name = "Sales_Opportunity_Number__c", namespace = "urn:sobject.enterprise.soap.sforce.com", type = JAXBElement.class)
    protected JAXBElement<String> salesOpportunityNumberC;

    /**
     * Gets the value of the salesOpportunityNumberC property.
     *
     * @return
     *     possible object is
     *     {@link JAXBElement }{@code <}{@link String }{@code >}
     *
     */
    public JAXBElement<String> getSalesOpportunityNumberC() {
        return salesOpportunityNumberC;
    }

    /**
     * Sets the value of the salesOpportunityNumberC property.
     *
     * @param value
     *     allowed object is
     *     {@link JAXBElement }{@code <}{@link String }{@code >}
     *
     */
    public void setSalesOpportunityNumberC(JAXBElement<String> value) {
        this.salesOpportunityNumberC = ((JAXBElement<String> ) value);
    }
}

The JAXBElementsalesOpportunityNumberC type is a bit cumbersome to work with your Java code.

Solution

A simple solution to this problem is to edit a copy of your wsdl. Do the following:

• Replace all nillable=”true” to nillable=”false”

The desired side effect of this generating Java code with the desired Java types in place. See corresponding example:

public class Opportunity
    extends SObject
{

    @XmlElement(name = "Sales_Opportunity_Number__c", namespace = "urn:sobject.enterprise.soap.sforce.com")
    protected String salesOpportunityNumberC;

    /**
     * Gets the value of the SalesOpportunityNumberC property.
     *
     * @return
     *     possible object is
     *     {@link String }
     *
     */
    public String getSalesOpportunityNumberC() {
        return salesOpportunityNumberC;
    }

    /**
     * Sets the value of the salesOpportunityNumberC property.
     *
     * @param value
     *     allowed object is
     *     {@link String }
     *
     */
    public void setSalesOpportunityNumberC(String value) {
        this.salesOpportunityNumberC = value;
    }

}

Props

Brian Dussault and Julie Dougherty word on this problem and came up with the solution documented and currently used by my team.

For the most part the two have been working okay, but 1 thing that keeps getting messed up is when an input parameter gets added to a WCF web service.  I added the parameter value to the Flex code, but it still would not get received by WCF.

Apparently this happens for return parameters too.  The solution is similar to fixing the web service call — modify the generated code.  (Apparently when I do an update on the WSDL, the code edit remains and I do not have to manually edit it again — adding to the mystery.)

So, in src/generated/webservices/Base[Name of my svc file]Schema.as, find the return list of the operation being called, and any new parameters that Flex is not picking up.

Massaging away.

I had a BPEL process that was using a File Adapter to poll a new folder for incoming files.  It was not behaving like I wanted it too, so in order to control the execution better I changed the BPEL process to trigger based on a field value in the database.

I deleted the File Adapter and added the Database Adapter.  It compiled and deployed successfully.  However in the logs the following errors were recorded when the criteria in the database was met.

<2009-10-19 13:44:02,202> <ERROR> <default.collaxa.cube>
<BaseCubeSessionBean::logError> Error while invoking bean "process manager":
[com.collaxa.cube.ws.WebServiceException: Cannot find partnerLinkType 2.
PartnerLinkType "{http://xmlns.oracle.com/.../TableWatch/}TableWatch_plt"
is not found in WSDL at "file:/C:/product/....BPEL.wsdl". Please make sure the
partnerLinkType is defined in the WSDL.] ORABPEL-08016 Cannot find
partnerLinkType 2. PartnerLinkType "{http://xmlns.oracle.com/.../TableWatch/}
TableWatch_plt" is not found in WSDL at "file:/C:/product/....BPEL.wsdl".
Please make sure the partnerLinkType is defined in the WSDL.

After much hair pulling re-engineering my BPEL process, I eventually resorted to google and found this brief post that saved the day.

To fix the problem, load up the BPEL console and go to the “BPEL Processes” tab.  From there select “Clear WSDL Cache”.  And that’s it sorted.

This problem is annoying.

If you make a .NET web service and you add the web reference to another project, Visual Studio runs WSDL.exe in the background to create a Reference.cs file – which is awesome (sort of). The Reference.cs file gives you the ability to call your web service just as if it were any other .NET class you have a reference to, which again, is awesome (sort of).

The problem arises when you have a class defined that is accepted as a parameter to, or returned from, a method in your web service. WSDL.exe generates a class definition for this class in the Reference.cs file, which is great if you don’t want to reference the actual class.

The standard solution to this problem is much as Bruce Johnson describes, which is to hand-edit the Reference.cs file to remove the generated class, and add a “using” statement or fully qualify the class name to point to the correct (the original) namespace.

Unfortunately, this means that every time you need to update the web reference, and the Reference.cs file is regenerated, you need to hand edit the Reference.cs file, which is a huge waste of time and kind of a pain in the butt.

There is apparently a way to use SchemaImporterExtensions to affect the way that WSDL.exe generates the Reference.cs file, but to be honest, it looked really confusing and also difficult to maintain. I didn’t really attempt to do it, though, so maybe it’s easier than it looks.

So, after having to deal with this on a project I’m working with currently, I decided that it would make sense to automate this annoying problem. I built an executable that accepts, on the command line, the path to a dll, and the path to a Reference.cs file. The executable looks for any public classes or enums that are defined in both the dll and the Reference.cs file, removes the class declaration from the Reference.cs file, and fully qualifies the class references.

I then changed the project properties (in the project that contains the web references) to add several pre-build commands. The commands call the executable with whatever combination of dll’s and Reference.cs files. This way, you can update the web reference as often as necessary, and before the project builds, the executable will run and fix all the issues in the Reference.cs file.

This code is kind of hacked together, but I really had a hard time justifying spending much time on polishing it, so I’m just going to post it as is. It’ll only work on C#, and as far as I know, there aren’t any bugs, although you might have some. If you use it and find anything wrong with it, leave a comment, and I’ll update the code.

Anyway, here’s the code – I’m kind of surprised I couldn’t find something to do this already, so hopefully it’ll help you.

Back when TCA SOAP support was implemented, the most common SOAP format was the rpc/encoded.  At that time, Java implementations were the most common client for SOAP.

As time has moved on, the .NET framework has dominated the Web Services landscape.  By default, .NET uses the document/literal style (although it happily interoperates with rpc/encoded)

Now the latest Java libraries have dropped support for rpc/encoded (Apache Axis2 – see http://ws.apache.org/axis2/1_1_1/Axis2-rpc-support.html).  Attempting to use Axis2 to read the TCA WSDL will fail with an exception stating : “Encoded use is not supported”.  Obviously this will cause problems with any software built on Axis2, such as Crystal Reports.

To address this, TCA has been modified to support the wrapped document/literal format (described here: http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/).  The modifications come as an updated .mac file for the Transoft Development Suite and as a modified Component Broker.

The changes will be part of the next release, but in the meantime if you find yourself needing to interoperate with a SOAP framework that doesn’t support rpc/encoded, contact customer services and we can supply an update

I know nothing about this stuff other than some basic XML knowledge so this is a bit like climbing Everest in winter in your skivvies for me (not that I would, I don’t even like heights!).

I have a SOAP service that I can make requests to quite fine thank you if I hard code the soap request string. So what I want to do is to create a wsdl for the service so that anyone can use it. Fine so far.

However the actual data being requested is determined by one of the attributes of the request and the attributes in the response vary depending upon what is being requested. So imagine the following:

<Get>

<name>ident_of_thing_I_want</name>

<other attributes> etc

</Get>

Now for any given request the ident_of_thing_I_want is a fixed string so I want to be able to define that in the wsdl itself so that when I gen a SOAP request from the wsdl for this ‘thing’, that ident string, i.e. ‘ident_of_thing_I_want’ is automatically included into the soap request between the attributes.

In other words, not only does the wsdl define the request attributes, but in the case of this one, the actual contents as well.

However, so far I have been unable to figure out if this is even possible, never mind how to do it.

I am using the WSDL editor of the Web Tools Project in Eclipse to create my wsdl and BIRT (also in Eclipse) to test it. to make matters worse I am unfamiliar with either tool or indeed even Eclipse itself so the whole experience so far ‘sucks’.

Plus, the tools are all Java based and Java runs like a snail on my machine!

I’ve been fighting with this for a week now and it’s driving me barmy. This is why I hate all this ‘clever’ stuff. Give me good old assembler any day. Heck I’d even write Cobol if I had to but they’ve even ‘webized’ that these days (sob!).

P.S. If you know how to do this, pleeeeze let me know!

Implementando um Web Service simples

O objetivo é aprender, então será criado um serviço bem simples. O serviço é a soma de duas variáveis inteiras retornando o resultado. Este exemplo poderá servir para qualquer outra implementação. Abaixo está a classe implementada. O nome do arquivo é Servico.java:

public class Servico {
      public int soma(int valor1, int valor2) {
            return valor1 + valor2;
      }
}

Agora só falta disponibilizá-lo no nosso servidor para o mundo acessar. E, para fazer isso, deve-se alterar o nome do arquivo de Servico.java para Servico.jws, coloca-lo no diretório: CATALINA_HOME / webapps / axis / e iniciar o servidor, se ele já não estiver iniciado. Se já estiver iniciado, o seu Web Service está publicado.

Os arquivos. jws são lidos pelo Axis e representam Java Web Services. O Axis se baseará nesses arquivos (. jws) para criar os arquivos de definição WSDL. Todos os métodos públicos existentes nessas classes serão automaticamente disponibilizados para terceiros.

Criar documentos XML é demorado e, muitas vezes, chato. Gerar o WSDL é uma característica muito relevante na escolha de uma implementação de SOAP e o Axis é um dos poucos frameworks que conseguem fazer essa façanha de maneira transparente para o desenvolvedor. É por esse motivo que ele é altamente recomendado na construção de Web Services.

Para acessar o Web Service criado basta abrir um navegador e ir ao endereço: http://localhost:8080/axis/Servico.jws . Da mesma forma que os outros dois Web Services foram vistos, este também terá um link para ver a especificação WSDL, e novamente poderá ser visto ou não dependendo do seu navegador.

O arquivo WSDL da classe Servico ficará como abaixo:

<?xml version=”1.0″ encoding=”UTF-8″?>
<wsdl:definitions targetNamespace=”http://localhost:8080/axis/Servico.jws”   
       xmlns=”http://schemas.xmlsoap.org/wsdl/”   
       xmlns:apachesoap=”http://xml.apache.org/xml-soap”   
       xmlns:impl=”http://localhost:8080/axis/Servico.jws”   
       xmlns:intf=”http://localhost:8080/axis/Servico.jws”   
       xmlns:soapenc=”http://schemas.xmlsoap.org/soap/encoding/”   
       xmlns:wsdl=”http://schemas.xmlsoap.org/wsdl/”   
       xmlns:wsdlsoap=”http://schemas.xmlsoap.org/wsdl/soap/”   
       xmlns:xsd=”http://www.w3.org/2001/XMLSchema”>  
    <wsdl:message name=”somaRequest”>  
<wsdl:part name=”valor1″ type=”xsd:int”/>  
<wsdl:part name=”valor2″ type=”xsd:int”/>  
   </wsdl:message>  
   <wsdl:message name=”somaResponse”>  
<wsdl:part name=”somaReturn” type=”xsd:int”/>  
   </wsdl:message>  
   <wsdl:portType name=”Servico”>  
     <wsdl:operation name=”soma” parameterOrder=”valor1 valor2″>  
<wsdl:input message=”impl:somaRequest” name=”somaRequest”/>  
       <wsdl:output message=”impl:somaResponse” name=”somaResponse”/>  
     </wsdl:operation>  
   </wsdl:portType>  
<wsdl:binding name=”ServicoSoapBinding” type=”impl:Servico”>  
<wsdlsoap:binding style=”rpc” transport=”http://schemas.xmlsoap.org/soap/http”/>  
     <wsdl:operation name=”soma”>  
       <wsdlsoap:operation soapAction=”"/>  
       <wsdl:input name=”somaRequest”>  
         <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”   
             namespace=”http://DefaultNamespace” use=”encoded”/>  
       </wsdl:input>  
       <wsdl:output name=”somaResponse”>  
         <wsdlsoap:body encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”   
             namespace=”http://localhost:8080/axis/Servico.jws” use=”encoded”/>  
       </wsdl:output>  
     </wsdl:operation>  
   </wsdl:binding>  
   <wsdl:service name=”ServicoService”>  
<wsdl:port binding=”impl:ServicoSoapBinding” name=”Servico”>  
<wsdlsoap:address location=”http://localhost:8080/axis/Servico.jws”/>  
     </wsdl:port>  
   </wsdl:service>  
</wsdl:definitions>  

Analisar este arquivo é essencial para entender a profundidade da implementação. Uma das linhas mais importantes para este arquivo é a 19ª linha, onde define-se o nome do método e o nome de seus parâmetros. Eles deverão ser de conhecimento público para que as interfaces cliente consigam se comunicar com o Web Service.

In this post let me go through the process of creating a web service client in java on ubuntu.

We need to have the apis for programming web services. Java provides a api called JAX-WS which is version 2 of the java web services api the previous version being JAX-RPC. JAX-WS comes a part of JDK6.0 and above. If you are using jdk5 then we need to download the JAX-WS web-service apis. JAX-WS is developed as a separate project called Metro and the latest version can be downloaded from the Metro project site – https://jax-ws.dev.java.net/. you can follow the instructions on the site for installing it.
Once installed it can be checked by tying wsimport at the terminal. It should give an output which looks like this


Usage: wsimport [options]


where [options] include:
-b specify jaxws/jaxb binding files or additional schemas
(Each must have its own -b)
-B Pass this option to JAXB schema compiler
-catalog specify catalog file to resolve external entity references
supports TR9401, XCatalog, and OASIS XML Catalog format.
-d specify where to place generated output files
-extension allow vendor extensions - functionality not specified
by the specification. Use of extensions may
result in applications that are not portable or
may not interoperate with other implementations
-help display help
-httpproxy:: specify a HTTP proxy server (port defaults to 8080)
-keep keep generated files
-p specifies the target package
-quiet suppress wsimport output
-s specify where to place generated source files
-target generate code as per the given JAXWS specification version.
version 2.0 will generate compliant code for JAXWS 2.0 spec.
-verbose output messages about what the compiler is doing
-version print version information
-wsdllocation @WebServiceClient.wsdlLocation value


Examples:
wsimport stock.wsdl -b stock.xml -b stock.xjb
wsimport -d generated http://example.org/stock?wsdl

If you get an output like this then we are done with the installation. we can proceed to the next step. Otherwise refer tot he metro site for installing this. For people using jdk6 everything is set by default and they can verify their installation by typing the above command in a terminal
Now we will find a site which provides free web service. I found a site http://www.webservicex.net/ which hosts lot of free web services organized into different categories. For this example lets us take a service which is called WHOIS web service which is available in the utilities section. The url for this is – http://www.webservicex.net/WCF/ServiceDetails.aspx?SID=51

Now we have to get the WSDL for this web service and compile it using the wsimport utility to get the start-up code for our web service.
To do this open a terminal and type

here the -keep tells the command to keep the generated java files and the -d is used to specify the output directory. we would get a output like this


parsing WSDL...


[WARNING] Ignoring SOAP port "whoisSoap12": it uses non-standard SOAP 1.2 binding.
You must specify the "-extension" option to use this binding.
line 113 of http://www.webservicex.net/whois.asmx?wsdl

[WARNING] ignoring port "whoisHttpGet": no SOAP address specified. try running wsimport with -extension switch.
line 116 of http://www.webservicex.net/whois.asmx?wsdl

[WARNING] ignoring port "whoisHttpPost": no SOAP address specified. try running wsimport with -extension switch.
line 119 of http://www.webservicex.net/whois.asmx?wsdl

generating code...
net/webservicex/GetWhoIS.java
net/webservicex/GetWhoISResponse.java
net/webservicex/ObjectFactory.java
net/webservicex/Whois.java
net/webservicex/WhoisSoap.java
net/webservicex/package-info.java



Now go to the directory where these files are created and we can create the client.

Create a java file with the following contents


package net.webservicex;
public class WhoisClient{
public static void main(String args[]){
Whois whois=new Whois();
WhoisSoap whoisSoap=whois.getWhoisSoap();
System.out.println(whoisSoap.getWhoIS("www.google.com"));

}
}


or still more usable as


package net.webservicex;
public class WhoisClient{
public static void main(String args[]){
Whois whois=new Whois();
WhoisSoap whoisSoap=whois.getWhoisSoap();
System.out.println(whoisSoap.getWhoIS(args[0]));

}
}


That is it we are donw with our web service client. Now compile the program by setting the classpath to point to the directory that contains the generated class files using the command


javac WhoisClient.java


Now the program can be run with by typing this in the terminal


java net.webservicex.WhoisClient www.google.com


we would get an output as below


Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

WWW.GOOGLE.COM.VN
WWW.GOOGLE.COM.TW
WWW.GOOGLE.COM.TR
WWW.GOOGLE.COM.SA
WWW.GOOGLE.COM.PE
WWW.GOOGLE.COM.MX
WWW.GOOGLE.COM.CO
WWW.GOOGLE.COM.BR
WWW.GOOGLE.COM.AU
WWW.GOOGLE.COM.AR

To single out one record, look it up with "xxx", where xxx is one of the
of the records displayed above. If the records are the same, look them up
with "=xxx" to receive a full display for each record.

>>> Last update of whois database: Sat, 05 Sep 2009 06:29:11 UTC <<<

NOTICE: The expiration date displayed in this record is the date the
registrar's sponsorship of the domain name registration in the registry is
currently set to expire. This date does not necessarily reflect the expiration
date of the domain name registrant's agreement with the sponsoring
registrar. Users may consult the sponsoring registrar's Whois database to
view the registrar's reported date of expiration for this registration.

TERMS OF USE: You are not authorized to access or query our Whois
database through the use of electronic processes that are high-volume and
automated except as reasonably necessary to register domain names or
modify existing registrations; the Data in VeriSign Global Registry
Services' ("VeriSign") Whois database is provided by VeriSign for
information purposes only, and to assist persons in obtaining information
about or related to a domain name registration record. VeriSign does not
guarantee its accuracy. By submitting a Whois query, you agree to abide
by the following terms of use: You agree that you may use this Data only
for lawful purposes and that under no circumstances will you use this Data
to: (1) allow, enable, or otherwise support the transmission of mass
unsolicited, commercial advertising or solicitations via e-mail, telephone,
or facsimile; or (2) enable high volume, automated, electronic processes
that apply to VeriSign (or its computer systems). The compilation,
repackaging, dissemination or other use of this Data is expressly
prohibited without the prior written consent of VeriSign. You agree not to
use electronic processes that are automated and high-volume to access or
query the Whois database except as reasonably necessary to register
domain names or modify existing registrations. VeriSign reserves the right
to restrict your access to the Whois database in its sole discretion to ensure
operational stability. VeriSign may restrict or terminate your access to the
Whois database for failure to abide by these terms of use. VeriSign
reserves the right to modify these terms at any time.

The Registry database contains ONLY .COM, .NET, .EDU domains and
Registrars.



Here we can give different host names as argument and experiment with it. There are many free web services available at http://www.webservicex.net and almost all of them can be consumed using the same method by using java clients. Thanks for reading

Introdução a Web Service utilizando Axis

A galera da Apache nos disponibilizou essa grande ferramenta que irá ajudar muito no desenvolvimento e implementação de Web Services, ela é super fácil de utilizar, sendo que faz quase todo o trabalho sozinha, escrevendo os XML, interpretando os métodos implementados nas classes JAVA e gerando o tal arquivo WSDL.

Um requisito básico de qualquer empresa é prover serviços, sejam os vendedores de uma empresa, o setor de custos e compras, os prestadores de serviço, etc. Cada empresa oferece serviços para a comunicação entre ela e outras pessoas, sejam pessoas físicas ou jurídicas, internas ou externas a empresa.
Alguns desses serviços podem ser automatizados. Por exemplo, não é necessário existir um representante de vendas se o seu cliente já tem, em mãos, o preço e todos os outros dados relevantes para constituir um pedido de compra. Este pedido pode e, em muitos casos, já é feito, via interfaces computacionais. O cliente entra em seu site, monta o pedido como desejar e confirma a compra. Isto é um serviço web, ou seja, um serviço que está publicado na web para que qualquer pessoa possa fazer uso.

Web Services foram criados para construir aplicações deste tipo, aplicações que são serviços na internet. Porém não faz parte do conceito de Web Service a criação de interfaces gráficas para os usuários, deixando esta parte para outras empresas ou pessoas desenvolverem. É comum encontrar textos afirmando que Web Services disponibilizam serviços somente para desenvolvedores, ou que Web Services nada mais são do que chamada de métodos usando XML. Estas definições estão corretas.

Web Services é a tecnologia ideal para comunicação entre sistemas, sendo muito usado em aplicações B2B. A comunicação entre os serviços é padronizada possibilitando a independência de plataforma e de linguagem de programação. Por exemplo, um sistema de reserva de passagens aéreas feito em Java e rodando em um servidor Linux pode acessar, com transparência, um serviço de reserva de hotel feito em. Net rodando em um servidor Microsoft.
Para comunicar-se com o Web Service, é necessário uma implementação do protocolo SOAP (Simple Object Access Protocol) definido no W3C . Este protocolo é o responsável pela independência que o Web Service precisa. Atualmente já encontra-se várias implementações disponíveis em várias linguagens. É só escolher uma e usar.

Na Figura abaixo encontra-se um diagrama mostrando as mensagens trocadas entre cliente e servidor em uma comunicação SOAP. Existem duas aplicações se comunicando, um Client Wrapper e um Server Wrapper que estão disponibilizando a transparência para as aplicações. Entre eles só trafega XML, seguindo o protocolo SOAP sobre HTTP.

Um Web Service será publicado, e para que outras pessoas possam utilizá-lo é necessário definir como ele é, como deve ser acessado, e que valores ele retornará. Estas definições são descritas em um arquivo XML de acordo com a padronização Web Service Description Language (WSDL). Este arquivo deve ser construído para que os usuários do serviço possam entender o funcionamento do Web Service e, logicamente, será de acesso público.
Os Web Services também podem ser utilizados para implementar arquiteturas orientadas a serviços, as Service-Oriented Architectures (SOA). Neste modelo de arquitetura os principais requisitos viram serviços e são acessados por outros serviços, modularizando e aumentando a coesão dos componentes da aplicação.
O que será implementado neste artigo é um Web Service simples, para aprendizado da tecnologia e para desmentir a afirmação que Web Services são complexos de construir e complexos para utilizar.

برای آن دسته از دوستانی که با زبان PHP آشنا هستند کتاب زیر را پیشنهاد می نمایم در این کتاب علاقه مندان با حدود 20 تکنولوژی زیر شاخه XML آشنا خواهند شد مانند ( DOM,XSD,RelaxNG,XSL,XSLT,…. )

Pro PHP XML and Web Services

Buy: $171.98

برای دوستان علاقه مند به پایگاه داده کتاب زیر را پیشنهاد می نمایم

Professional XML Databases

Buy: $25.87

برای آنان که کم و بیش با XML آشنا هستند کتاب زیر را پیشنهاد می کنم

Understanding Web Services: XML, WSDL, SOAP, and UDDI

Buy: $32.84

این هم دو کتاب در دو سطح مقدماتی و پیشرفته در دنیای XML

Beginning XML

Buy: $8.00

Professional XML

Buy: $31.49

تهیه و تنظیم : بهنام سلطان رضایی

Produced by : Behnam Soltanrezaey