August 2009 - jboss-dev-forums - Jboss List Archives

[JBoss ESB Development] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : I don't understand why the service mep is not an indicator of whether or not the invoked http-gateway should return the service response as its response (mep=RequestResponse), or should simply return an empty response as its response (mep=OneWay). It is not an indicator, and never can be in the current implementation, because it only reflects an intent on that particular service *implementation*. It has no bearing on whether the client expects to receive, or should receive, a response. The mep is not a contract for the service which is how I believe you are interpreting it. The only service type mechanism we have at present is the EBWS declarations, i.e. inXsd, outXsd, faultXsd, and it is these declarations which determine the contract for the exposed webservice, not a service mep. "tfennelly" wrote : It seems to me like having an additional sync/async config on the gateway would be very confusing for users. I think this is what's being proposed, right? It is the only way in the current architecture. I want a proper service contract as part of the architecture and, as you know, we have discussed this as part of the ESB 5 work. Once we have the contract then it will be the definitive location for making these types of decisions but, until then, a separate configuration is necessary. "tfennelly" wrote : So, assuming we add a "sync" flag on the http-gateway, how should the gateway respond when... Ignore the service mep, it is irrelevant to the caller (see below). "tfennelly" wrote : If the http-gateway used the mep, what use case breaks, and how does it break i.e. what actually goes wrong e.g. with the chained services example outlined in the IM? If I understand correctly you are expecting the service mep to declare the outcome of the invocation from the perspective of the client, but this has never been the case. It has always been an indication of intent on behalf of the service implementation. Originally there was no mep, and the decision for a pipeline to return a response was left completely up to the implementation of the actions. If they returned a null response then the pipeline terminated at that point, if a message reached the end then it would attempt to send a response to a client. This caused numerous issues, especially when actions were intended to be used in both scenarios as it required a new action, or specific handling, to decide whether the message was to be propagated along the pipeline. If this was not done, or if the wrong action was used, then we had situations where multiple responses were being sent to the caller. The mep was introduced, to the service implementation, as a way of trying to clean some of this up and allow the service to declare, regardless of how the actions behaved, whether a response could be sent at the end of the pipeline. It meant that it was no longer necessary to know which action could progress the pipeline processing and it removed a major source of problems. If the mep is declared RequestResponse then the service is stating that it should, directly, respond to the caller. If the mep is declared as OneWay then the service is stating that it will not respond to the caller but this does not prevent another service, invoked as part of the pipeline (i.e. routing), from responding. So your table should look as follows 1. gateway sync=true, service mep=OneWay? Synchronous invocation, response may come from a second service (as highlighted in IM conversation). 2. gateway sync=true, service mep=RequestResponse? Synchronous invocation, service pipeline should return response. 3. gateway sync=false, service mep=OneWay? Asynchronous invocation. Pipeline will not return a response, even in subsequent services, as the client has indicated that it does not want one. 4. gateway sync=false, service mep=RequestResponse? Asynchronous invocation. Pipeline will not return a response as the caller has indicated that it does not want one. So in every case the gateway configuration you are discussing will map directly onto the invocation, irrespective of the service mep. It appears that you are looking for a service contract definition but the mep is not, and has never been, that. The closest we have at present is the EBWS configuration on the service. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252493#4252493 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252493

14 years, 8 months

1
0
0 / 0

[JBoss ESB Development] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"Kevin.Conner(a)jboss.com" wrote : put this to bet put this to bed :) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252491#4252491 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252491

14 years, 8 months

1
0
0 / 0

[JBoss ESB Development] - Re: Http Gateway - requirements please...

by Kevin.Conner＠jboss.com

"tfennelly" wrote : Not sure what you mean here Jim. Both sync and async are/will be supported. The only outstanding question (AFAIK) is the how part i.e. if we can't use the associated service's mep to decide how the gateway should respond (and Kev has indicated that we can't), what do we use and how would that work ala the questions I asked a few posts back. Sorry, thought we had put this to bet a long time ago but I will look back and follow up on your latest posting. Kev View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252490#4252490 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252490

14 years, 8 months

1
0
0 / 0

[JCA Development] - Re: Implementation of the ConnectionManager Service

by gurkanerdogdu

Hi Jesper; I have ported ConnectionManager 's Connection Pool part. I did the followings | 1* Created a new package structure under the connectionmanager/ package. This reflects better class encapsulation. | 2* Removed inner classes as a top level if it is really necessary | 3* Changed "multiple synchronized" keywords with using concurrent list and sets. | 4* Divided long methods into fine-grained several methods. | 5* Removed MBean and Statistics related methods. | 6* Changed all collection classes with Java 5 generics siblings | 7* Added more comments | 8* Removes unnecessary codes | 9* Apply our code formatter | | | Patches are found in the | | https://jira.jboss.org/jira/browse/JBJCA-153 | | Thanks ; | | --Gurkan View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252479#4252479 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252479

14 years, 8 months

1
0
0 / 0

[JBoss Portal Development] - Re: Exception during deployment in JBP 2.7 RC1

by krisdasword

I tried deploying a JSR 168 portlet, even it throws the same error message... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252461#4252461 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252461

14 years, 8 months

1
0
0 / 0

[JBoss OSGi Development] - 3.6.3 Optional Packages

by thomas.diesler＠jboss.com

3.6.3 Optional Packages https://jira.jboss.org/jira/browse/JBOSGI-143 A bundle can indicate that it does not require a package to resolve correctly, but it may use the package if it is available. For example, logging is important, but the absence of a log service should not prevent a bundle from running. Optional imports can be specified in the following ways: Dynamic Imports â The DynamicImport-Package header is intended to look for an exported package when that package is needed. The key use case for dynamic import is the Class forName method when a bundle does not know in advance the class name it may be requested to load. Resolution Directive â The resolution directive on an import definition specifying the value optional. A bundle may successfully resolve if a suitable optional package is not present. The key difference between these two mechanisms is when the wires are made. An attempt is made to establish a wire for a dynamic import every time there is an attempt to load a class in that package, whereas the wire for a resolution optional package may only be established when the bundle is resolved. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252390#4252390 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252390

14 years, 8 months

1
0
0 / 0

[JBoss ESB Development] - Re: Http Gateway - requirements please...

by tfennelly

"jtyrrell" wrote : A few thoughts from this page: | http://www.jboss.org/community/wiki/HTTPGateway Hey Jim... thanks for ahving a look and providing some feedback... "jtyrrell" wrote : What about performance and tuning considerations? I'm fairly sure this would be done at a container level and that there's nothing in the servlet spec wrt performance tuning etc. So, I think the answer to your question is... same as for any other war deployment in the JBossWeb container. "jtyrrell" wrote : From that link: | In the "Synchronous/Asynchronous Responses" | To be worked out!! Currently using the Service MEP to decide whether or not the gateway should wait on the Service response (mep=RequestResponse), or deliver an empty response immediately (mep="OneWay"). Kev has indicated that we can't use the mep, so we need to find out how it should work. | section. | | Why should we mandate one or the other, why can this not be configurable. Why would we change the "semantics" for this option around mep, although maybe that is not a valid thought either. | | I think both sync and async should be support with this, with hopefully the same kind of configurations as the mep parameter? Not sure what you mean here Jim. Both sync and async are/will be supported. The only outstanding question (AFAIK) is the how part i.e. if we can't use the associated service's mep to decide how the gateway should respond (and Kev has indicated that we can't), what do we use and how would that work ala the questions I asked a few posts back. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252369#4252369 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252369

14 years, 8 months

1
0
0 / 0

[Embedded JBoss Development] - Re: Reloaded eclipse project usage

by scott.stark＠jboss.org

Running mvn -Peclipse eclipse:m2eclipse produces the separate eclipse-target classpath entries. I guess I was expecting that to be done when one imports an maven project. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252366#4252366 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252366

14 years, 8 months

1
0
0 / 0

[JBoss ESB Development] - Re: Http Gateway - requirements please...

by dward

"jtyrrell" wrote : David W, was working on XSLT in/out of a gateway (it was faster the smooks for him) he was writing around Web Services, should that idea be included in this gateway. Does that even make sense? I dropped the XSLT capability of the SOAPProxy a long time ago. It didn't make architectural sense, as it makes the proxy do more than it is supposed to. Daniel Bevenius wrote an XsltAction, which can be put in front of and/or after the SOAPProxy, which makes a lot more sense for the pipeline ala' "separation of concerns". View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252358#4252358 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252358

14 years, 8 months

1
0
0 / 0

[JBoss Messaging Development] - Re: JBoss Messaging and App Server

by clebert.suconic＠jboss.com

HornetQ can be used in other applications servers. We have provided our own JCA adapter. We have basically tested it into JBAS only, but I have reports of an user using it for instance on OpenEJB. We should do some tests with other application servers before GA. I would say JBoss Messaging is more dependent on JBAS due to the library dependencies. While HornetQ is totally independent. You could have more information about this on www.hornetq.org View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4252354#4252354 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4252354

14 years, 8 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums August 2009