Facade design pattern in web services

[sulbha walawalkar]

Can someone give me some pointers about how to use facade pattern in web services? I am using websphere 6 & RAD 7 as runtime environment.
I am pretty new to web services...so any pointers will be helpful.

Thanks,
Sulabha

[Peer Reynders]

Welcome to JavaRanch!

A design pattern presents a recurring solution for a certain category of problems. What is the problem that you are trying to solve?

In some cases the term Web Services Facade pattern is used to refer to a web service that exposes a proprietary or legacy system technology interface with a web services interface. In other cases application of the facade pattern to web services refers to the composition of multiple subsidiary web services under one single web service interface.

[sulbha walawalkar]

Thanks for the reply..

My requirement is to provide a interface to java and .net clients.
This interface will inturn call another web service or just java/ejb class thats containing the acutal biz logic.
Facade can handle other stuff like logging/security, integrating calsl to other services.

Can you suggest some good link to read abt the design pattern & abt the preformance issues in web services?

Thanks,
Sulabha

[Peer Reynders]

The issues that your are listing cover more than the what the general Facade Pattern usually addresses.
Understanding The Facade Pattern

Unfortunately "facade" is turning up in more and more pattern names where it is justifiable in terms of English language usage but it doesn't necessarily mean that it fits the definition of the general "Facade Pattern".

In terms of general design patterns you are actually dealing with issues usually addressed by at least three design patterns:

Facade - Define a higher-level interface that makes the subsystem easier to use.

Decorator - Attach additional responsibilities to an "object" (possibly dynamically) without any modification of the underlying "class".

Adapter - Let "classes" work together that couldn't otherwise because of incompatible interfaces.

Ultimately you are using the Facade Pattern because you are trying to present one simple unified interface for a whole mess of pre-existing business logic. The purest form of the facade pattern applied to web services is a web service that simply delegates the work to more basic web services. The facade service doesn't implement any "business logic" beyond any necessary data conversion/mapping and the sequencing of the delegate services.

If you are adding logging and security which aren't implemented by the existing systems/business logic then you are adding new responsibilities. That isn't part of the "Facade pattern" that is part of the "Decorator pattern". Basically that would imply that you design security and logging wrappers around the subsystems and that the facade would only access the subsystems through these secured/logged wrappers.
Decorator Design Pattern
.NET cannot use Java code or access EJBs. However .NET can access interoperable web services. So if you expose EJBs or POJOs functionality through a web service then you are building an adapter. Furthermore some of the subsystems may already have their own security in which case you will have to map WS-security to the subsystem's security. There are usually plenty of opportunities to use adapters when you are building a facade.
Adapter Design Pattern

"Message" granularity generally decreases from web service, to EJB, to POJO. Web services exchange "documents" (large), EJB often exchange objects (DTOs) (medium), while POJOS often have JavanBean style setters and getters using only fundamental data types. Web services are also supposed to be stateless. That means that that each message (document) should contain all the information necessary to process the request - information shouldn't be sent piece meal to the service and all the information required to process a transaction should be sent together. So the facade service will also have to act as a Remote Facade because it only accepts complete aggregations of data which it then breaks up into the pieces that are required by the POJOs and EJBs that implement the business logic (and it also aggregates the results to be sent back).

This article may be helpful: The command facade pattern.

Here is an article on the Web Service Facade for Legacy Applications. Just skip the .NET code - it is the higher level concepts that you are after.

This article may be somewhat useful Provide a Facade interface for enterprise Web services though its short on the higher level descriptions and long on code and IDE specific features.

See also Performance: Remote EJB x Web Services
[ January 17, 2008: Message edited by: Peer Reynders ]

[sulbha walawalkar]

Peer,

Thanks for the pointers..it was very helpful.

I am now using spring web services for my application with facade as a interface for web service. The service will send the data in xml format to a third party application to read/write the data to SQL server.

Which design pattern can be used with facade to keep business logic to form xml and call 3rd party api to read/write data to SQL server?

Also in the spring f/w, am using jaxb as marshaller and thinking of using the same to form xml message to send to 3rd party api.
Is there any other good way of forming xml from xsd?

Thanks,
Sulabha

[Peer Reynders]

Originally posted by sulbha walawalkar:
Which design pattern can be used with facade to keep business logic to form xml and call 3rd party api to read/write data to SQL server?

Have a look at this topic. It might contain some relevant ideas.

am using jaxb as marshaller and thinking of using the same to form xml message to send to 3rd party api.
Is there any other good way of forming xml from xsd?

Depending on what you are doing it may not be necessary to unmarshall/marshall anything. XML to XML transformation is usually done with XSLT (Processing XML with Java: Chapter 17. XSLT, XSLT in Java).

[sulbha walawalkar]

well...I have looked at the thread that you hv referred..but my problem is different..
I am using Jaxb marshaller in spring w/s..so end point implementation class gets the java object representing the soap request.
I have written facade as interface to business methods.
To get the data requested by client, w/s will call the other application which accpets xml message (schema provided in xsd format) and returns the response the xml.
Now since my end point has request data in java objects, I need to form the xml message.

I have couple of queries here....

1. while using marshaller, I have created request objects from xsd file (contract-first) which are exposed to client in wsdl.
Should I use/pass the same request objects to servic layer?
Or create diffrent domian objects in servic layer and pass thar to facade/service?

2. Application will also write some of the data to DB2..for which I have written DAO. since no business logic should be kept in facade, I have written that bit of code in DAO. Does that sounds logical?

3. To read/write data in xml from java objects, I think I need to again map the xsd file (provided by third party) to java objects and use apis (from jaxb/xml beans or any other xml tech) to translate the data into xml and vice versa...
I am not sure which pattern would be good to implement this bit of code.

Thanks in advance,
Sulabha
[ February 25, 2008: Message edited by: sulbha walawalkar ]

[Peer Reynders]

1. while using marshaller, I have created request objects from xsd file (contract-first) which are exposed to client in wsdl.
Should I use/pass the same request objects to servic layer?
Or create diffrent domian objects in servic layer and pass thar to facade/service?

Passing generated objects to the service layer - no. Everytime the XML Schema is updated the generated object will change and the interface to the service layer will have to change.

Create separate domain object from the generated objects - better. However you still have to write the code to create the domain objects from the generated objects and you are essentially creating twice as many objects.

Define separate domain objects and create an external binding file - best. With an external binding file you tell the JAXB compiler how to map the XML to your domain objects. That way the XML is unmarshalled to your domain objects. And when the XML Schema changes you update the external binding file.

2. Application will also write some of the data to DB2..for which I have written DAO. since no business logic should be kept in facade, I have written that bit of code in DAO. Does that sounds logical?

Well, it depends. The term business logic is very nebulous. If you hand your domain object to the DAO and it extracts some information to write to the persistent store I guess thats OK. If that "some information" is a separate concept that could be represented by a new class then you should consider writing the DAO against the interface of that new class and provide an adapter the allows the DAO get that information from the domain object. That way the "business logic" of "converting" the interface of these two classes is encapsulated in the adapter. Also "no business logic should be kept in facade" is a bit dogmatic. The fact is that facades often use adapters and translators which either contain "business logic" or delegate to other objects which contain "business logic". The key is to encapsulate to the "domain logic" so that it is readily identified as such and preferably usable by both the facade and domain model rather than burying (and duplicating) it somewhere in the code of the facade.

3. To read/write data in xml from java objects, I think I need to again map the xsd file (provided by third party) to java objects and use apis (from jaxb/xml beans or any other xml tech) to translate the data into xml and vice versa... I am not sure which pattern would be good to implement this bit of code.

You should be able to do most of the XML/Java conversion through the use of external binding files. Then it is simply a matter of layering the responsibilities appropriately.

Web service
Request       Response
===========   ==========
JAXB          ^^^^^^^^^^
XML to Obj    JAXB         Use external bindings to map Objects to and from XML (Schema)
vvvvvvvvvv    Obj to XML
============ ===========
          Domain
          Logic
          Objects
============ ===========   Object-based SQL Server facade
Obj to XML    ^^^^^^^^^^
translators   XML to Obj   JAXB assisted marshalling/unmarshalling
vvvvvvvvvv    translators  possibly using your own XML Schemas
==========    ==========
XML-based SQL Server API

[ February 26, 2008: Message edited by: Peer Reynders ]

[sulbha walawalkar]

Originally posted by Peer Reynders:
[QB]
You should be able to do most of the XML/Java conversion through the use of external binding files. Then it is simply a matter of layering the responsibilities appropriately.

Web service
Request       Response
===========   ==========
JAXB          ^^^^^^^^^^
XML to Obj    JAXB         Use external bindings to map Objects to and from XML (Schema)
vvvvvvvvvv    Obj to XML
============ ===========
          Domain
          Logic
          Objects
============ ===========   Object-based SQL Server facade
Obj to XML    ^^^^^^^^^^
translators   XML to Obj   JAXB assisted marshalling/unmarshalling
vvvvvvvvvv    translators  possibly using your own XML Schemas
==========    ==========
XML-based SQL Server API

Thanks for thr reply. As of now I'm doing the 2nd option to created DTOs from schema objects. I'll look at the external binding option for jaxb. Is there any binding mapping that I need to configure in spring servlet xml file or while binding schema? Could not find any example for that.

About the converting the java objects to xml, yes I can use Adapter to translate the data in xml.
I tried to create the java objects with jaxb1, but the xsd file has <xs:redefine> tags which are not supported by jaxb1. Jaxb2 does support, but we have jaxb1 marshalling/unmarshalling jars being used by other applications. Not sure when they will upgrade to jaxb2. So I cant use jaxb2 as of now.

I'll be implementing castor for soap message & converting java to xml as another approach to test the performance.

Is there any better option to transalte java to xml (with jaxb1 for marhalling/unmarshalling soap message)?

Also if I have <xsd:redefine> in xsd file, the code generator doesn't generate java class with the name of xsd file. Instead it generates java classes for as many xsd files I have in <xsd:redefine> tag. Not sure how to generate xml out of so many classes. I believe any marshal method accepts xml file name & java class containing the data.

Thanks,
Sulabha

[Peer Reynders]

Originally posted by sulbha walawalkar:
I'll look at the external binding option for jaxb. Is there any binding mapping that I need to configure in spring servlet xml file or while binding schema? Could not find any example for that.

External binding happens during compile time with the xjc compiler - so I don't see that having any impact on the deployment settings.

I tried to create the java objects with jaxb1, but the xsd file has <xs:redefine> tags which are not supported by jaxb1.

It may be worth looking at "pre-processing" those redefines out the schemas (people having to deal with them don't seem too fond of them) for JAXB - i.e. replacing the redefines with an "include" to a new schema file that is generated from the "original redefined" schema with all the redefinitions applied. JAXB won't care as long as the fully qualified names aren't affected.

Is there any better option to translate java to xml (with jaxb1 for marhalling/unmarshalling soap message)?

Performance wise Castor is inferior to both versions of JAXB. It is also unclear how long Castor will be supported with JAXB being part of the JDK. The current non-JAXB favorite seems to be JiBX and it is supported by Axis 2. With JiBX you can sidestep the JAXB upgrade issue and possibly use Axis 2 as your front end. JiBX seems to have the best performance characteristics.
[ February 28, 2008: Message edited by: Peer Reynders ]

[sulbha walawalkar]

External binding happens during compile time with the xjc compiler - so I don't see that having any impact on the deployment settings.

Yeah..I have used xjc to bind xsd file (with contract first approach for spring) to java objects (i'll call them as schema objects).
I am using domain objects (DTO) to be used by service layer, as I have mentioned in my previous post. And creating them in end points with the data from schema objects...
Were you suggesting external binding for mapping the xsd to domain objects?

There will be 2 different xsd sets that will be used. One for request/response from client to spring web service.
Another is schema definition for the request/response for 3rd party application from service layer.
So there will be
- schema objects (for marshalling/unmarshalling) soap message
- domain objects (dto) that will be used in service layer
- schema objects (for marshalling/unmarshalling) java to plain xml for 3rd party api

It may be worth looking at "pre-processing" those redefines out the schemas (people having to deal with them don't seem too fond of them) for JAXB - i.e. replacing the redefines with an "include" to a new schema file that is generated from the "original redefined" schema with all the redefinitions applied. JAXB won't care as long as the fully qualified names aren't affected.

I could create the objects with Jaxb2. I didnt like jaxb1 as it creates too many classes.
But when in tried to bing schema with Castor, it was pain. It needs many packages..and finally it gave me xml excpetion while parsing. The same schema I could parse with jaxb2..strange!

Originally posted by Peer Reynders:
[QB]

Performance wise Castor is inferior to both versions of JAXB. It is also unclear how long Castor will be supported with JAXB being part of the JDK. The current non-JAXB favorite seems to be JiBX and it is supported by Axis 2. With JiBX you can sidestep the JAXB upgrade issue and possibly use Axis 2 as your front end. JiBX seems to have the best performance characteristics.

okay..I'll chk this too.
Thanks.

Sulabha

[Peer Reynders]

Originally posted by sulbha walawalkar:
Were you suggesting external binding for mapping the xsd to domain objects?

I was thinking along the lines of forcing JAXB through customization to generate the DTOs that you want. While that is not the same as mapping the XML to existing domain objects it might save you some work. JiBX seems to have been created to map XML documents to and from existing Java objects as long as the objects observe certain rules (and it seems to do this without referring to any XML Schemas). Of course that leaves the burden of writing the bindings/mappings on you.

I could create the objects with Jaxb2

JAXB2 requires Java SE 5 which was as far as I know only introduced with WS 6.1.
[ February 28, 2008: Message edited by: Peer Reynders ]

[sulbha walawalkar]

code:
---------------------------------------------------------------------------
Web serviceRequest Response=========== ==========JAXB ^^^^^^^^^^XML to Obj JAXB Use external bindings to map Objects to and from XML (Schema)vvvvvvvvvv Obj to XML============ =========== Domain Logic Objects============ =========== Object-based SQL Server facadeObj to XML ^^^^^^^^^^translators XML to Obj JAXB assisted marshalling/unmarshallingvvvvvvvvvv translators possibly using your own XML Schemas========== ==========XML-based SQL Server API

---------------------------------------------------------------------------

How can I implement the jaxb marshalling/unmarshalling using adapter pattern? or any other pattern?