Hi Chaamini, Think about how a standalone application would communicate with SWIFTNetLink. Does it use HTTP or some other well known protocol to do that? Or does it use some custom SWIFT specific protocol or an API (like JMS)? If it's the first case then we don't need a separate transport. But in the second case we probably need a new transport. I think you should write a simple client-server application using SWIFT and really understand how the integration with SWIFTNetLink works. Then you will be in a position to decide whether we need a new transport or not.
Andreas is also making an interesting point here. If SWIFT messages are XML based then we don't need a new message builder/formatter either. So I think what we need to decide is whether we need a new transport or not. If we don't need a transport either, I'd still like to have a sample and some documentation on Synapse-SWIFT integration. Also we might be able to find some interesting project ideas that combine SWIFT integration with the mediation library stuff Udayanga did. Thanks, Hiranya On May 9, 2013, at 6:39 AM, Supun Kamburugamuva <[email protected]> wrote: > Hi Chaamini, > > If you use the SWIFTNetLink to get the message that will be the application > layer protocol. > > Thanks, > Supun.. > > > On Thu, May 9, 2013 at 7:08 AM, Chaamini Mangaleswaran <[email protected]> > wrote: > Hi Supun, > > If a new transport is written to enable swift message transfer through > SWIFTNetLink, what would be the new application protocol that needs to be > supported? Though I read several specifications I couldn't find information > regarding this. > > > > > Thanks & Regards, > Chaamini > > Keep Smiling ! > > > On Wed, May 8, 2013 at 10:09 PM, Supun Kamburugamuva <[email protected]> > wrote: > If you need SWIFTNetLink to transfer messages you may want to consider > writing a transport. You can use message Formatters/Builders when the wire > message come from a transport like HTTP. > > Thanks, > Supun.. > > > On Wed, May 8, 2013 at 12:30 AM, Chaamini Mangaleswaran <[email protected]> > wrote: > I guess therefore message builder and message formatter for SWIFT MT messages > would meet the requirement. > > > > > Thanks & Regards, > Chaamini > > Keep Smiling ! > > > On Tue, May 7, 2013 at 11:52 PM, Andreas Veithen <[email protected]> > wrote: > On Tue, May 7, 2013 at 6:38 PM, Chaamini Mangaleswaran > <[email protected]> wrote: > > Hi Hiranya, > > > > I read SWIFT Specifications and I found out the following : > > > > An organization has to connect to SWIFTNet to connect with all the > > institutions participating. SWIFTNetLink is a mandatory software product > > for the users of SWIFTNet. This provides the technical interoperability > > between users by providing the minimal functionality required to communicate > > over swift services. > > > > SWIFTNet Link provides a set of XML-based APIs, to connect the local > > application with the remote application and with the SWIFTNet. > > > > Therefore I think basically SWIFT will be a content exchange format like > > XML. I couldn't find supporting material which > > > > requires to > > support a new application layer protocol to integrate SWIFT as you > > mentioned. > > Therefore as from my findings I think a message builder and formatter > > suffice the requirement. > > > > Another concern I came across was, though WIFE supports SWIFT MT standards > > (ISO 15022), there is another emerging XML based standard for SWIFT called > > SWIFT MX standards ( ISO 20022). This is not supported by WIFE yet > > > > and > > I couldn't find any other open source SWIFT Framework which addresses this > > need. > > I am not aware of any possible > > alternative > > ways > > to incorporate > > XML based > > SWIFT MX Standards > > at the moment. > > If these new messages are already XML based, then I guess that they > don't need any kind of translation/transformation when entering or > exiting the Synapse runtime. > > > I would like hear your thoughts regarding this issue too. > > > > > > > > > > > > Thanks & Regards, > > Chaamini > > > > Keep Smiling ! > > > > > > On Tue, May 7, 2013 at 3:40 AM, Hiranya Jayathilaka <[email protected]> > > wrote: > >> > >> The real question is whether SWIFT is an application layer protocol (like > >> HTTP) or just a content exchange format (like XML). You should probably > >> look > >> into the SWIFT specification and figure out an answer to this question. The > >> type of implementation required depends on the answer. If it is an > >> application layer protocol then we need a transport. But if it's just a > >> content exchange format that runs on existing application layer protocols, > >> we only need a message builder and a formatter. > >> > >> It's also possible that we need both. HL7 is a good example to such a > >> scenario. HL7 integration requires supporting an application layer protocol > >> known an SMPP. But it can also work on existing protocols such as HTTP by > >> leveraging HL7 message formats. So we need a transport as well as a > >> builder/formatter in that case. Perhaps SWIFT also falls into that > >> category. > >> > >> Let us know what you can find out from the SWIFT specs. > >> > >> Thanks, > >> Hiranya > >> > >> On May 5, 2013, at 9:12 PM, Chaamini Mangaleswaran <[email protected]> > >> wrote: > >> > >> Hi All, > >> > >> I am trying to develop a new feature for Apache Synapse to support SWIFT > >> Protocol. As the initial step I am trying to use the JMS transport already > >> available and build a message builder and message formatter, which can > >> convert SWIFT messages to XML and vice versa. For this conversion I am > >> trying to use the open source SWIFT message management framework called > >> WIFE. > >> But there is another approach to implement it as a standalone transport > >> protocol by using Apache Mina and a transport sender and receiver. Will the > >> first approach will be sufficient to meet the requirement ?I would like to > >> hear your thoughts on this idea! > >> > >> > >> > >> > >> Thanks & Regards, > >> Chaamini > >> > >> Keep Smiling ! > >> > >> > >> -- > >> Hiranya Jayathilaka > >> Mayhem Lab/RACE Lab; > >> Dept. of Computer Science, UCSB; http://cs.ucsb.edu > >> E-mail: [email protected]; Mobile: +1 (805) 895-7443 > >> Blog: http://techfeast-hiranya.blogspot.com > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > > > > -- > Supun Kamburugamuva > Member, Apache Software Foundation; http://www.apache.org > E-mail: [email protected]; Mobile: +1 812 369 6762 > Blog: http://supunk.blogspot.com > > > > > > -- > Supun Kamburugamuva > Member, Apache Software Foundation; http://www.apache.org > E-mail: [email protected]; Mobile: +1 812 369 6762 > Blog: http://supunk.blogspot.com > -- Hiranya Jayathilaka Mayhem Lab/RACE Lab; Dept. of Computer Science, UCSB; http://cs.ucsb.edu E-mail: [email protected]; Mobile: +1 (805) 895-7443 Blog: http://techfeast-hiranya.blogspot.com
