service per method or router action

[tobysaville]

if i understand claudio's question here corretly
http://www.jboss.org/index.html?module=bb&op=viewtopic&t=114213

i have a similar question - specifically should i create a separate EPR (category and name) for each method in my service interface?

For example, if i have

public interface IService {

 public Object method1();
 public Object method2();

}

Should I create 2 service entries in my jboss-esb.xml along the lines of:

<services>
 <service category="Service" name="Method1">
 ...
 </service>

 <service category="Service" name="Method2">
 ...
 </service>
</services>

Or, alternatively, should i create a routing style action which determines which method to call based on the body of the message?

I guess i would lean towards using a routing action so the caller doesnt need to know which service they are calling. If this is so, what would be a use case for having multiple EPRs in a service?

thansk for your help/time

tobes

[tfennelly]

To be honest, you can dice and slice this whatever way you want + use content based routing too.

Not sure why you'd want to do any of that though when you can simply expose a single ESB webservice endpoint for your backend EJB Service (1:1) (as illustrated in the quickstart) and leave the webservice stack to "route" the SOAP request to appropriate endpoint operation.

[kurtstam]

Hi Tobes,

It's entirely up to you. But note that an ESB is about messages, and not so much about 'exposing methods'. You would typically want to minimize the number of methods/services and send around coarse grained messages.

Take a look at:
http://www.enterpriseintegrationpatterns.com/

and our wiki:
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossESBEIP

--Kurt

[tobysaville]

Thanks for your suggestions - ill check out those links Kurt.

I was a bit confused by the webservice_producer quickstart actually. it seemed to me that when you accessed the service via the exposed webservice, then the message wasnt utilising the ESB - it was simply a standard, direct web service call. And isnt that what we are trying to avoid by using the ESB?

thanks again
tobes

[burrsutter]

I'd lean towards the "routing" way of thinking. Currently, your brain is more focused on RPC - remote procedure calls where methods are exposed across the network. This strategy normally runs into trouble when your server-side object has a large number of methods with relatively simple parameters.

The best example I can think of is:
Customer
getName
setName
getPhone
setPhone

Would you wish to expose all the getters/setters over the network via RMI?

Or would you rather expose a single method that took the entire Customer (e.g. setCustomer) as a single "message"?

Once your server-side component (e.g. ESB Service) receives the big, course-grained "message" it can unpack that message and invoke all the individual setName, setPhone, etc methods.

A message should often related to something at the business level as well. Order, Invoice, Part, Catalog, Customer, Patient, Employee, etc. This will make the use of Rules & jBPM as part of the end-solution that much easier to work with.

Burr

[tfennelly]

"tobysaville" wrote:
I was a bit confused by the webservice_producer quickstart actually. it seemed to me that when you accessed the service via the exposed webservice, then the message wasnt utilising the ESB - it was simply a standard, direct web service call. And isnt that what we are trying to avoid by using the ESB?

So Toby, implementing a 181 endpoint and exposing it through the ESB gives you the following:
1. These 181 endpoint impls are ESB message aware. You can get the Message instance via the SOAPProcessor.getMessage() method. So, your 181 endpoint can interact with an ESB action pipeline - get and set on the message.
2. The endpoint is invokable through any channel supported by the ESB, not just HTTP. So you can perform a Webservice endpoint invocation via HTTP, FTP, File, email etc etc

So what's ugly about this at the moment is the fact that you have to manually implement the 181 endpoint and wrap it up so the JBossWS Deployer will deploy it. That's a bit of a pain in the head for sure. We do intend eliminating this.

"burrsutter" wrote:
I'd lean towards the "routing" way of thinking. Currently, your brain is more focused on RPC - remote procedure calls where methods are exposed across the network. This strategy normally runs into trouble when your server-side object has a large number of methods with relatively simple parameters.

The best example I can think of is:
Customer
getName
setName
getPhone
setPhone

Would you wish to expose all the getters/setters over the network via RMI?

Or would you rather expose a single method that took the entire Customer (e.g. setCustomer) as a single "message"?

Once your server-side component (e.g. ESB Service) receives the big, course-grained "message" it can unpack that message and invoke all the individual setName, setPhone, etc methods.

A message should often related to something at the business level as well. Order, Invoice, Part, Catalog, Customer, Patient, Employee, etc. This will make the use of Rules & jBPM as part of the end-solution that much easier to work with.

Burr

Burr, I really think this is a separate issue re service granularity. Sure, if the backend Service is fine grained, then creating a facade on that Service makes sense.

What I read out of the original question on this thread was whether or not creating a completely separate service per endpoint-operation was a good or bad idea. I don't think we need to read too much into the choice of words here either i.e. "method" - invoking images of RPC etc and => the follow on "SOA" type reaction to that.

So, if for example I have an existing backend Service that supports 5 *course grained* operations (sync or async) and I want to expose a Webservice interface for this backend Service, should I do this by exposing a single Webservice that supports 5 operations ala the backend Service, or should I create 5 Services, one for each Service operation?

If this is the real question, then I would def lean towards 1 Webservice (not 5), as closely aligned with the backend Service as possible (remembver, hopefully users won't have to manually impl these 181s post 4.2GA). I also see no real need to introduce CBR in this usecase, unless there's an exceptional need. The SOAP stack is effectively doing this for you anyway i.e. via the SOAPAction. Am I missing something :-) ?

[burrsutter]

What if I'm not using SOAP? My solution only calls for JMS and FTP at the moment.
Should I have a service, as declared in the jboss-esb.xml, per method on a backing EJB/POJO?
Or would I write my backing EJB more like an MDB so that it essentially has a single method that receives the entire message?
Or would I write an "adapter" action to review the message contents/headers/properties/etc and invoke the correct method on the backing EJB/POJO?

Obviously your solution will varying depending on what is relatively easy to change. Perhaps you don't have the source code to the backing EJB.

Burr

[tobysaville]

Hi Burr,

thanks for your input. I think this is the approach I am taking, accepting a OrderRequest object and returning an OrderResponse

thanks again for your help guys,

tobes

[tfennelly]

"burrsutter" wrote:
What if I'm not using SOAP? My solution only calls for JMS and FTP at the moment.

Not with you there. Why are we equating SOAP with JMS or FTP. SOAP is the message payload format - JMS and FTP are transports. SOAP can be carried over JMS or FTP too, right?

Are you saying - what if I'm not interested in exposing a Webservice for the backend EJB? In that case, sorry. I was basing my answers on the original thread that was linked to ("One ESB Service to provide various methods like a webservice") and the fact that we were talking about the webservice quickstarts. If your not interested in webservices then forget everything I said and the field is wide open :-) So why are webservices excluded as an option then?

"burrsutter" wrote:
Should I have a service, as declared in the jboss-esb.xml, per method on a backing EJB/POJO?
Or would I write my backing EJB more like an MDB so that it essentially has a single method that receives the entire message?

If changing the backend EJB impl is an option, then you can probably provide integration points with requiring to introduce an ESB at all. Not sure if JBossAS does it, but I know some of the other EJB containers allow you to automatically expose Webservice interfaces on top of EJBs

"burrsutter" wrote:
Or would I write an "adapter" action to review the message contents/headers/properties/etc and invoke the correct method on the backing EJB/POJO?

Yep, you can do anything I suppose, depending on what you're ruling in and out as possible options.

"burrsutter" wrote:
Obviously your solution will varying depending on what is relatively easy to change. Perhaps you don't have the source code to the backing EJB.

Exactly, this is always my assumption because this is one of the main reasons I see people using the ESB. If it's a green field site, then all sorts of other options are open, some of which may be more straightforward than introducing ESBs etc.

This thread has gotten lost a this stage I think hehehehe

[tobysaville]

sorry, posted that reply to Burr from a cached version of the post, didnt notice the follow on.

So Toby, implementing a 181 endpoint and exposing it through the ESB gives you the following:
1. These 181 endpoint impls are ESB message aware. You can get the Message instance via the SOAPProcessor.getMessage() method. So, your 181 endpoint can interact with an ESB action pipeline - get and set on the message.

This is what i assumed. However, when calling the WS directly, via

http://127.0.0.1:8080/Quickstart_webservice_producer/GoodbyeWorldWS?wsdl

the following test in the GoodbyeWorldWS in the webservice_producer quickstart is false and nothing is printed:

Message esbMessage = SOAPProcessor.getMessage();
if(esbMessage != null) {
 System.out.println("**** ESBMessage set on ThreadLocal");
 System.out.println("esb msg reply to: " + esbMessage.getHeader().getCall().getReplyTo());
}

making me think that in this case, you dont infact have access to the action pipeline. Am i not understanding it correctly? Are you not supposed to call the WS directly when it is exposed via a service?

Im sure im missing something here with this quickstart, but i am very eager to get a full understanding of it.

As for the second issue here that Tom elegantly rephrased for me, yes, it was a question of granularity. There are some interesting points made by Tom and I think Burr has raised the same questions that Toms post raised for me. Perhaps the answers will become clearer with a better understanding of how the producer sample works (such as how does the SOAPProcessor action know to call the sayGoodbye method?).

cheers,
Toby

[tfennelly]

Ah right.... now I see where the confusion re the quickstart is coming from and this is something Burr, Tom Cunningham and I only talked about yesterday.

So you're going directly to the Service via it's JBossWS HTTP endpoint address. This will bypass the ESB.

The SOAP messages need to be posted via the ESBs HTTP gateway on that service:

 <jbr-provider name="JBR-Http" protocol="http" host="localhost">
 <jbr-bus busid="Http-1" port="8765" />
 </jbr-provider>

This is indeed a problem for you if you're trying to use something like soapUI via a wsdl. If you're using the wsdl published directly by JBossWS (which you are - and understandably so), well then you're hosed because it's port addresses for the endpoints will be its own and not the ESBs.

What we created for this (and were talking about yesterday) is a little web application that's in the tools folder of the ESB src (i.e. not in the distro). It's not in the distro because it's really just a prototype and we were expecting it to be superseded by something better. That hasn't happend yet though. It's in a folder called "jboss-esb.war" in product/tools.

Through this you can see all the Endpoints registered in the registry, plus (for SOAPProcessor containing endpoints/action-chains) you can access the ESBs version of the WSDL publication. This will work for you in soapUI etc. Only thing is, I'm not sure if it's actually working in source - TomC was looking at it yesterday.

[tfennelly]

Sorry, was too fast there....

"tobysaville" wrote:
Perhaps the answers will become clearer with a better understanding of how the producer sample works (such as how does the SOAPProcessor action know to call the sayGoodbye method?).

Yep, it does know because all that information is in the SOAP message - JBossWS handles all that for you. Modify that quick start and add multiple operations on the endpoint.

[tobysaville]

thanks Tom

I think i have more questions, but im going to go away and look at the quick start harder and that EIP site and arrange thoughts in my head a bit better.

Thanks to all who've helped so far
tobes