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

Reply via email to