On Sat, Feb 18, 2012 at 10:27 PM, Senaka Fernando <sen...@wso2.com> wrote:
> Hi Shankar, > > We need a consitent solution in defining endpoints (that's a part of what > endpoint unification should be doing). > +1 But we need both the ways; 1. Ability to store in registry - To share across diffrent tiers such as development, staging, production, etc 2. Ability to get the unified EP path from a config file - To deploy an artifact in different places Please add if I miss anything. Thanks Thilini > If the consistent solution is to use the registry, we need to go for it. > If there are limitations in the deployment process when the registry is > being used we need to identify the concern and address that. > > For example, we found it useful to create a CSV import tool to import > Services into the registry rather than asking the user to use the GUI for > everything. Also, its about using the registry properly. If we need to > change 10 different places for each change, that means the registry is not > being shared properly. > > Thanks, > Senaka. > On Thu, Feb 16, 2012 at 9:12 AM, Selvaratnam Uthaiyashankar < > shan...@wso2.com> wrote: > >> On Wed, Feb 15, 2012 at 11:10 PM, Sameera Jayasoma <same...@wso2.com> >> wrote: >> > >> > >> > On Wed, Feb 15, 2012 at 11:57 AM, Thilini Ishaka <thil...@wso2.com> >> wrote: >> >> >> >> Hi, >> >> >> >> I want to add some more information regarding this. >> >> Unified endpoint per each file is okey to go with as far as we do not >> need >> >> to edit configurations in any of the artifacts (deploy.xml, wsdl files, >> >> etc..) inside the BPEL package when deploying the same in different >> >> environments. >> >> >> >> When we keep the .epr files outside the BPEL package we need to give >> >> the absolute path for each .epr inside the deploy.xml as AmilaM >> mentioned. >> >> And this is the limitation I see. >> >> >> >> Can this be achieved by passing a parameter to deploy.xml to get the >> path >> >> from a system property? >> >> >> >> <invoke partnerLink="MultiplierPartnerLink"> >> >> <service name="MultiplierService.wsdl:MultiplierService" >> >> port="MultiplierServiceSOAP11port_http"> >> >> <endpoint xmlns=" >> http://wso2.org/bps/bpel/endpoint/config"; >> >> endpointReference=$xxxxx /> >> >> </service> >> >> </invoke> >> >> >> >> >> > >> > How about giving a registry key here. This would enable us to use >> endpoints >> > stored in the registry. >> >> But it will be a maintanance problem at the deployment time. For >> example, if I have to deploy this system in 10 different places, it is >> lot easy to modify in the configuration file, rather than create in >> registry. >> >> Shankar >> >> > >> > Thanks, >> > Sameera. >> > >> > >> >> >> >> Thanks >> >> Thilini >> >> >> >> >> >> On Wed, Feb 15, 2012 at 8:52 AM, Thilini Ishaka <thil...@wso2.com> >> wrote: >> >>> >> >>> >> >>> >> >>> On Wed, Feb 15, 2012 at 8:49 AM, Thilini Ishaka <thil...@wso2.com> >> wrote: >> >>>> >> >>>> >> >>>> >> >>>> On Tue, Feb 14, 2012 at 9:54 PM, Keheliya Gallaba <kehel...@wso2.com >> > >> >>>> wrote: >> >>>>> >> >>>>> Hi Thilini, >> >>>>> >> >>>>> I think currently we can have that functionality via unified >> endpoints. >> >>>>> You can refer to an external endpoint configuration in the >> deploy.xml like >> >>>>> the following: >> >>>>> >> >>>>> <invoke partnerLink="CreditRatingPL"> >> >>>>> <service name="crns:CreditRatingService" >> >>>>> port="CreditRatingPort"> >> >>>>> <endpoint >> >>>>> xmlns="http://wso2.org/bps/bpel/endpoint/config"; >> >>>>> >> endpointReference="CreditRatingService.epr"/> >> >>>>> </service> >> >>>>> </invoke> >> >>>>> >> >>>>> That file can define an address like this: >> >>>>> >> >>>>> <wsa:EndpointReference >> >>>>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> >>>>> xsi:schemaLocation="http://www.w3schools.comuep_schema.xsd"; >> >>>>> xmlns:wsa="http://www.w3.org/2005/08/addressing"; >> >>>>> xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/";> >> >>>>> >> >>>>> <wsa:Address>http://localhost:9000/services/CreditRatingService/ >> </wsa:Address> >> >>>>> </wsa:EndpointReference> >> >>>>> >> >>>>> One restriction is you will have to define a config file for each >> >>>>> distinct invoke in a process. But the advantage is, when the >> environment >> >>>>> changes you can just change the file without changing the deployment >> >>>>> artifact. >> >>>> >> >>>> Yes. That's true. But the initial thinking was to have a single >> config >> >>>> for each invocation. >> >>> >> >>> I mean to avoid updating multiple configuration files. >> >>> >> >>> >> >>>> >> >>>> >> >>>> Thanks >> >>>> Thilini >> >>>> >> >>>>> >> >>>>> >> >>>>> Regards, >> >>>>> Keheliya >> >>>>> >> >>>>> >> >>>>> On Tue, Feb 14, 2012 at 9:38 PM, Paul Fremantle <p...@wso2.com> >> wrote: >> >>>>>> >> >>>>>> Isn't this something that our endpoint unification is meant to take >> >>>>>> care of? >> >>>>>> >> >>>>>> Paul >> >>>>>> >> >>>>>> On 14 February 2012 15:16, Thilini Ishaka <thil...@wso2.com> >> wrote: >> >>>>>>> >> >>>>>>> >> >>>>>>> Hi All, >> >>>>>>> >> >>>>>>> Consider a situation where we have multiple service (partner >> >>>>>>> services) invocations in a business process. >> >>>>>>> We need to change soap:address location for each and every wsdl >> once >> >>>>>>> a particular service uri is changed from x to y. This is a >> frequent >> >>>>>>> situation which we need one step solution. >> >>>>>>> I would suggest two approaches as; >> >>>>>>> >> >>>>>>> Have a single configuration file which lists soap:address location >> >>>>>>> for each wsdl (Then you only require to change the URIs inside >> the config >> >>>>>>> file); >> >>>>>>> 1. A script based solution. (perl/python) >> >>>>>>> 2. Write an own wsdl extension >> >>>>>>> >> >>>>>>> What would be the best solution here? >> >>>>>>> kindly appreciate your thoughts. >> >>>>>>> >> >>>>>>> Thanks >> >>>>>>> Thilini >> >>>>>>> >> >>>>>>> Regards >> >>>>>>> >> >>>>>>> Thilini Ishaka >> >>>>>>> WSO2 Inc >> >>>>>>> >> >>>>>>> >> >>>>>>> _______________________________________________ >> >>>>>>> Carbon-dev mailing list >> >>>>>>> Carbon-dev@wso2.org >> >>>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> -- >> >>>>>> Paul Fremantle >> >>>>>> CTO and Co-Founder, WSO2 >> >>>>>> OASIS WS-RX TC Co-chair, VP, Apache Synapse >> >>>>>> >> >>>>>> UK: +44 207 096 0336 >> >>>>>> US: +1 646 595 7614 >> >>>>>> >> >>>>>> blog: http://pzf.fremantle.org >> >>>>>> twitter.com/pzfreo >> >>>>>> p...@wso2.com >> >>>>>> >> >>>>>> wso2.com Lean Enterprise Middleware >> >>>>>> >> >>>>>> Disclaimer: This communication may contain privileged or other >> >>>>>> confidential information and is intended exclusively for the >> addressee/s. If >> >>>>>> you are not the intended recipient/s, or believe that you may have >> received >> >>>>>> this communication in error, please reply to the sender indicating >> that fact >> >>>>>> and delete the copy you received and in addition, you should not >> print, >> >>>>>> copy, retransmit, disseminate, or otherwise use the information >> contained in >> >>>>>> this communication. Internet communications cannot be guaranteed >> to be >> >>>>>> timely, secure, error or virus-free. The sender does not accept >> liability >> >>>>>> for any errors or omissions. >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >> >>>>>> Carbon-dev mailing list >> >>>>>> Carbon-dev@wso2.org >> >>>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> Keheliya Gallaba >> >>>>> Software Engineer; >> >>>>> Integration Technologies Team; WSO2 Inc.; http://wso2.com, >> >>>>> email: keheliya [AT] wso2.com >> >>>>> mobile: +94 71 551 8881 >> >>>>> blog: http://galpotha.wordpress.com >> >>>>> twitter: http://twitter.com/keheliya >> >>>>> linked-in: http://lk.linkedin.com/in/keheliya >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >> >>>>> Carbon-dev mailing list >> >>>>> Carbon-dev@wso2.org >> >>>>> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >>>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> Regards >> >>>> >> >>>> Thilini Ishaka >> >>>> WSO2 Inc >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> Regards >> >>> >> >>> Thilini Ishaka >> >>> WSO2 Inc >> >>> >> >> >> >> >> >> >> >> -- >> >> Regards >> >> >> >> Thilini Ishaka >> >> WSO2 Inc >> >> >> > >> > >> > >> > -- >> > Sameera Jayasoma >> > Technical Lead and Product Manager, WSO2 Carbon >> > >> > WSO2, Inc. (http://wso2.com) >> > email: same...@wso2.com >> > blog: http://tech.jayasoma.org >> > >> > Lean . Enterprise . Middleware >> > >> > _______________________________________________ >> > Carbon-dev mailing list >> > Carbon-dev@wso2.org >> > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > >> >> >> >> -- >> S.Uthaiyashankar >> Senior Architect & Senior Manager >> WSO2 Inc. >> http://wso2.com/ - "lean . enterprise . middleware" >> >> Phone: +94 714897591 >> _______________________________________________ >> Carbon-dev mailing list >> Carbon-dev@wso2.org >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> > > > > -- > *Senaka Fernando* > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > * > Lean . Enterprise . Middleware > > > _______________________________________________ > Carbon-dev mailing list > Carbon-dev@wso2.org > http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev > > -- Regards Thilini Ishaka WSO2 Inc
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
