Facade Pattern
Hi everybody,
We are designing a system where we want to access a Workflow System (Bonita) installed in a remote server. To do that we want to provide a service following the Facade pattern to give access to the API of the Workflow System through either a RMI or Web services (it seems us WS are too slow, for out requirements, any other idea?)
The classes of the facade pattern would be included in a jar file (as in future will be used by other apps). This jar would be imported by the final web application (so the workflow api would also be imported to the client application).
We are not fully happy with this design and we would like to hear different ideas and point of views.
Thanks in advance,
Antonio
[747 byte] By [
amartela] at [2007-11-27 5:22:00]
# 1
> Hi everybody,
>
> We are designing a system where we want to access a
> Workflow System (Bonita) installed in a remote
> server. To do that we want to provide a service
> following the Facade pattern to give access to the
> API of the Workflow System through either a RMI or
> Web services (it seems us WS are too slow, for out
> requirements, any other idea?)
Have you considered messaging (e.g. JMS)?
# 2
No, I haven't considered JMS. We were thinking now about using EJBs, any idea an implementation with one or another?Thanks for your reply
# 3
Do you synchronous communication or is it OK to send commands and no check on their success immediately?
# 4
To help you to get an idea of the kind of things the service or facade should 'serve', I will describe some examples of communication:
In web application code (client)
serviceFacade.setFlowAttribute(Date)
serviceFacade.getFlowTaskList(user);
Then, for each one of these services the facade will execute one or more methods of the Workflow Server API.
Thanks for your interest
# 5
> To help you to get an idea of the kind of things the
> service or facade should 'serve', I will describe
> some examples of communication:
>
> In web application code (client)
>serviceFacade.setFlowAttribute(Date)
> serviceFacade.getFlowTaskList(user);
>
> Then, for each one of these services the facade will
> execute one or more methods of the Workflow Server
> API.
OK but I'm not sure this is relevant to what approach to use for the remoting. What matters is what kinds of commands are you running. Are they synchornous requests? Are they send only or do you need to query the server?
# 6
Those requests are synchronous; in other words, the client waits for a response from the server (ie. list of tasks or workflow state). Thanks again
# 7
> Those requests are synchronous; in other words, the
> client waits for a response from the server (ie. list
> of tasks or workflow state).
Messaging will probably not be appropriate. How do EJBs fit in? That seems like a strange option for this task.
RMI may be an option. I'm not sure I would choose it myself, though. Another thing to consider is that in 2007, a web service isn't necessarily SOAP-based. My experience is that SOAP based web services are indeed slow and/or problematic. I would not expect that this is something you will want to open up to the world. So the need to have a public WSDL seems pretty low. You could implement a simpler web service with plain XML documents and a shared schema. If you parse the requests with SAX instead of DOM, speed should not be an issue.
# 8
Thanks for yor answer dubwai.Just one point more. Could you please, point us any document or web page about those simpler, no-soap based web services.Regards
# 9
Here's one that seems decent.
http://www.artima.com/webservices/articles/whysoap.html
I think you should also ask yourself if there's anything that SOAP provides that you don't get from just using XML? In my experience, SOAP is merely used to deliver a payload, which is XML and does not depend on SOAP at all.
Really the only thing that is useful about SOAP based webservices is the WSDL. A lot of tools understand WSDL. The problem is that a lot of tools also interpret WSDL 1.1 in different ways. I've even worked with two tools from a single vendor that could not understand each other's WSDLs.
In any event you are already considering not using Web Services anyway so I don't really consider this a loss.
