Menu
▾
▴
jboss-dev-forums
|
From: ddossot <do-...@jb...> - 2006-06-02 10:58:06
|
I can not disclose real data but this is the kind of things I have to do:
* Transform Raw Data to Raw XML (using Regexp extraction) then to Target XML (using XSL):
[ABC;123]->[<group1>ABC</group1><group2>123</group2>]->[123]
* Transform ad hoc security scheme to WS-Security:
Env{Body:usr=ABC;pwd=123;...}->Env{Head:{ws-security:usr=ABC;pwd=123};Body{...}}
* XSL Processor accessing a data cache service so stylesheet performing data enrichment can do it efficiently.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3948664#3948664
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3948664
|
|
From: tfennelly <do-...@jb...> - 2006-06-02 11:14:27
|
Fair play to ya. That's great, thanks!! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3948671#3948671 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3948671 |
|
From: tfennelly <do-...@jb...> - 2006-06-13 00:10:35
|
It took a while, but I eventually got around to writing a tutorial to demostrate how the transformation described by David (above) might be done using Smooks. http://milyn.codehaus.org/Transforming+a+SOAP+Message David, if you see this message, I'd be interested in your thoughts. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3950554#3950554 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3950554 |
|
From: d_widyantoro <do-...@jb...> - 2006-06-20 01:50:33
|
I have been doing some research on Mule-ESB. Mule has a great idea on transforming any incoming/outgoing message. From mule point of view, they call service processor as endpoint. We can set the transformer as we want. Simple case, i receive the transaction over HTTP protocol and deliver the transaction to partner system as ISO8583 message. I can create HTTPtoInternalMessage, InternalMessagetoISO8583 as the input transformer and ISO8583toInternalMessage, InternalMessagetoHTTP as response transformer. Regards. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951809#3951809 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951809 |
|
From: ddossot <do-...@jb...> - 2006-06-20 11:36:09
|
This is a dual reply (sorry for the delay). * Mule & Transformation: I have been using Mule quite extensively for a client and I confirm their transformation model is really good. In fact I have implemented the "Transform Raw Data to Raw XML" and "XSL Processor accessing a data cache" that I mentionned before as Mule transformers. * Re: "http://milyn.codehaus.org/Transforming+a+SOAP+Message", this is extremely promising approach. Could the bean be defined in Groovy to avoid compiling it? It would complicate the administration of the ESB if people had to use a compiler when editing the configuration. Now as a general matter, one thing that was annoying (to me) with Mule is that I basically had to take a node down to modify a transformation chain. For my project, this was ok but for a central ESB, this is not an option. I am expecting that whatever approach you guys follow, it will not mandate a service disruption to be deployed. I reckon that the Smooks-driven transformation will be hot reloadable. Thanks! David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951928#3951928 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951928 |
|
From: tfennelly <do-...@jb...> - 2006-06-20 12:42:38
|
anonymous wrote : Could the bean be defined in Groovy to avoid compiling it? It would complicate the administration of the ESB if people had to use a compiler when editing the configuration. For sure (but I haven't tried it :-) ). It could also be implemented such that the Groovy Bean script could be embedded in the smooks-resource configuration. I tried this with BeanShell scripting (http://www.beanshell.org/[/url]). It worked fine, but to be honest I found modifying Java code inside an XML file to be a pain in the neck, so I didn't publish it. If you want to take a look at the code: [url]http://cvs.milyn.codehaus.org/browse/milyn/smooks-cartridges/beanshell/src/main/java/org/milyn/smooks/beanshell/BeanShellTransUnit.java?r=1.2 View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951953#3951953 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951953 |
|
From: tfennelly <do-...@jb...> - 2006-06-20 12:44:53
|
sorry about the messed up formatting View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951954#3951954 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951954 |
|
From: <mar...@jb...> - 2006-06-20 12:47:27
|
Versioning of services should be able to cope with hot-deploying of transformation engines and rules. Although we may not have that in play with the first GA release, it will be something that will happen eventually. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951956#3951956 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951956 |
|
From: ddossot <do-...@jb...> - 2006-06-20 13:06:27
|
I agree that code in XML is not great, an independant file that could be loaded by the transformation engine would be better (Groovy or BSH, whatever best fits). The whole stuff would then be packaged together. Thanks, David View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951963#3951963 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951963 |
|
From: tfennelly <do-...@jb...> - 2006-06-20 13:08:51
|
anonymous wrote : Versioning of services should be able to cope with hot-deploying of transformation engines and rules. Although we may not have that in play with the first GA release, it will be something that will happen eventually. Is David talking about hot redeploy in a production type environment? Would someone really make changes to a prod env in this way? I can see how hot redeploys (without a new version) could be useful in Dev/QA type envs. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951964#3951964 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951964 |
|
From: <mar...@jb...> - 2006-06-20 13:14:06
|
Yes they would. I've come across systems that are deployed and running continuously and cannot be taken down for more than 24 hours in a year! So being able to cope with changes to services on a running system is something we need to factor in from the start. Obviously there may be some changes that simply cannot be coped with while the system is running, but with any luck those will be the exception rather than the rule. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951972#3951972 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951972 |
|
From: ddossot <do-...@jb...> - 2006-06-20 13:15:08
|
"Hot redeploy" is probably an overstatement from my side. Say, the contract of an outbound service has changed and you want to modify the transformation chain to be able to keep routing messages to it. You would then have to deploy a new config without stopping the whole service. Sorry for using the wrong terminology. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3951973#3951973 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3951973 |
|
From: ddegroff <do-...@jb...> - 2006-06-22 15:38:29
|
"ddossot" wrote : "Hot redeploy" is probably an overstatement from my side. | | Say, the contract of an outbound service has changed and you want to modify the transformation chain to be able to keep routing messages to it. You would then have to deploy a new config without stopping the whole service. | | Sorry for using the wrong terminology. I'm not sure I would know the "correct terminology" myself in this case, David. But, to introduce another practical example of what I believe this thread is discussing: Suppose you are exchanging a format (let's just say X12 EDI) with a trading partner external to the ESB. The trading partner (a major player who dictates what "standard" shall be used to communicate with them, "or else") revises their "standard" as of a certain date in the future. It would be wise to employ versioning, including date/time effectivity, so that development and testing could ensue prior to the "deadline", and deployment of the new version could occur even prior to the "go date". Once the effective date passes, the transformation would use the "new" format in compliance with the trading partner's demands. I'm working on yet another example for you, Tom. I wanted an opportunity to work through your tutorial beforehand. Thanks all, Dave De View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3952720#3952720 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3952720 |
|
From: tfennelly <do-...@jb...> - 2006-06-23 19:47:50
|
anonymous wrote : I'm working on yet another example for you, Tom. I wanted an opportunity to work through your tutorial beforehand. That would be great Dave, thanks! View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953115#3953115 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953115 |
|
From: ddegroff <do-...@jb...> - 2006-06-24 16:32:46
|
OK, Tom. Here's the challenge: The data (the most simple example I could devise in the environment where I typically work) looks like this: ISA*00* *00* *ZZ*EXTERNAL_TP *ZZ*INTERNAL_TP *010806*1200*U*00401*000000003*0*T*: GS*HS*EXTERNAL_AP*INTERNAL_AP*20010101*120000*001*X*004010X092 ST*270*0001 BHT*0022*13*10001234*19990501*1319 HL*1**20*1 NM1*PR*2*ABC COMPANY*****PI*842610001 HL*2*1*21*1 NM1*1P*1*JONES*MARCUS****SV*0202034 HL*3*2*22*0 TRN*1*93175-012547*9877281234 NM1*IL*1*SMITH*ROBERT*B***MI*11122333301 REF*1L*599119 DMG*D8*19430519*M DTP*472*D8*19990501 EQ*98**FAM SE*14*0001 GE*1*001 IEA*1*000000003 Pretty, huh? This is ANSI X12N, the required format for US healthcare these days (stay tuned, HL7 is being knocked about as the "new" standard upcoming -- it, at least, is XML). X12N format is based on "segments" (each line starting with a two- to three-character code). Each "element" of data is, at least in this example, separated by asterisks. For readability, I've left the segment terminator as a line feed. This format is excruciatingly hierarchical. That is, a single transmission might contain multiple "interchanges" (that's the bit between the lines starting with "ISA" and ending with "IEA"). Each interchange may have one or more "groups" (bracketed by "GS" and "GE"). The target, if you will is the "transaction", located between "ST" and "SE". I'm going to take a crack at this myself, but my suggestion would be to tackle this in stages. First, check the transmission for interchanges, validating the ISA and IEA segments according to rules (to be posted subsequently). Then, invoke one secondary action for each interchange found, to check for groups. And so on. The output for the exercise is XML (the publisher who came up with the X12 has a version that I'm not too keen on) -- I'll be back shortly with my version, along with more descriptions for the input data elements. For now, I would recommend transforming this mess into an XML like <batch><ISA><ISA01>00</ISA01>... etc.</ISA></batch> where ISA01 is the first element found in the ISA segment, etc. Where an empty value is found (see the HL segment), the example would be <HL02></HL02>. I will be posting subsequent info via URLs so the forum can be spared the volume... :-) Please advise if this makes little sense. Dave De View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953215#3953215 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953215 |
|
From: tfennelly <do-...@jb...> - 2006-06-24 19:31:27
|
Nice one Dave !!!! You're not joking, it is ugly!! Anyway, what doesn't kill you will make you stronger etc, so I'm looking forward to trying this out. To be honest, I was sorta thinking more in terms of SOAP to SOAP style examples, but this is great because I need to understand all the scenarios - especially the ugly ones ;-) anonymous wrote : Please advise if this makes little sense. I've only had one read through it and it makes *some* sense :-) After a dozen or so reads I'm sure a clearer pisture will start to form. First thought that came into my head after reading this was... would it be possible to write an X12N to SAX event parser? This would be a parser that could generate bog standard SAX events from an X12N stream, thereby allowing you to construct an XML DOM directly from the X12N stream - or alternatively, serializing the SAX event stream straight out to HL7. So, this would make the X12N stream *appear* as though it was an XML stream. Can't think why this wouldn't be possible, if X12N is hierarchical/predictable!! On your XML'ified version of the X12N stream: <batch><ISA><ISA01>00</ISA01>... etc.</ISA></batch> Why did you choose to represent each of the interchanges with new element tags i.e. ISA01, ISA02 etc?? Could it not be something like: <x12n><isa whatever="00">....</isa><isa whatever="13">....</isa> ... etc... </x12n> ... and use the position of each element to infer the 01 (ala ISA01) etc. Is the position of an interchange, within a batch, actually all that important? I'll take a closer look when I get a chance. Sat evening now and I'm away for the day tomorrow - our county team is playing a big game against Dublin :-) Thanks again Dave!! You certainly have me thinking now :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3953235#3953235 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3953235 |
|
From: tfennelly <do-...@jb...> - 2006-06-28 20:27:59
|
OK, so I've put something together on this.
So the solution I implemented revolves around a standard SAX Parser implementation called X12nToSaxEventParser. As its name is supposed to suggest, it parses an X12N stream and generates a set of SAX Events which it fires at a standard SAX ContentHandler implementation. It has 2 support class:
1. X12nStreamReader: Wraps the stream and makes the X12N segments easier to access.
2. X12nModel: Contains definitions to help the parser convert the X12N stream to a stream of SAX events.
Here's a sample of its output after parsing the sample X12N stream in Dave's above post - actually it's 2 blocks of the above sample X12N, hence the 2 blocks inside the root <x12n> element.
So, this parser could be used by any XML transformation tools that support SAX based processing and transformation. I had to make a very small mod to Smooks in order to make it easier to specify specific SAX parsers for specific message types - available in the v 0.7.2-SNAPSHOT build from the downloads.
See the JUnit test code. The x12n-config.cdrl config file illustrates how to configure the X12nToSaxEventParser to parse messages originating from X12N based message producers ("x12n-requester" - "x12n-producer" might have been a better profile name). See X12nToSaxEventParserTest for the units test code for executing a parse. Excuse the fact that this test has no assertions - it just runs the parse :-) This test doesn't perform any actual XML based transformations on the XMLified X12N stream. This would probably be required in a real life situation (different transformations for different consumers) and is easy enough using the standard Smooks mechanisms (see tutorials) - once we have it in XML, we can do whatever we want!!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954185#3954185
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954185
|
|
From: ddegroff <do-...@jb...> - 2006-06-29 14:34:11
|
Absolutely brilliant, Tom! Your solution provides an excellent framework from which to build. I will pursue moving toward delivering the output I've constructed here: http://www.ehealthconnect.net/ehc/test270.xml For further thought/discussion, I should make mention of some ancillary issues (not at all requisite for pressing forward with straight transformation): 1. Validation (use of X12n implementation guides to determine correctness of both structure and content of entire EDI message). I can pretty much take ownership of this tedious issue, unless someone has extensive experience/expertise in this. 2. Looping. I will provide later further explanation of this issue. Suffice it to say at this point that there is a concept I refer to as "behavior of data", that has certain constructs repeating some number of times (see issue #1). 3. Reusable Objects. Quite a number of elements found within EDI are actually context-appropriate reuse of "standard" structures (name, address, etc.) This issue will become apparent when I publish the schema for the 270 output XML. Thanks again, Tom. Dave De View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954391#3954391 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954391 |
|
From: tfennelly <do-...@jb...> - 2006-06-30 20:43:18
|
Dave, do you need this for something real?? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954754#3954754 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954754 |
|
From: ddegroff <do-...@jb...> - 2006-07-01 15:35:49
|
anonymous wrote : Dave, do you need this for something real?? Boy, Tom, the short answer is "yes". The long answer is a bit more involved. My objective is to deliver an eCommerce infrastructure based on JBESB. In truth, this concept is applicable cross-industry. My main focus/passion is US healthcare, certainly. My experience, in fact, has been in multiple industry environments, including international. The infrastructure of which I speak would apply for X12 (cross-industry, including healthcare, retail, manufacturing, logistics, etc.), EDIFACT, SWIFT, on and on. Now, I can get off my "soap box'. If your question relates to timescales/existing client, the short answer is: no existing client--yet; but I would like to see this "generic" infrastructure in place by Q1 2007. In the interim, I seek a client to partner for early adoption/alpha and beta testing, etc. Maybe my reach exceeds my grasp, but I see enormous potential for this. Dave View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954831#3954831 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954831 |
|
From: kukeltje <do-...@jb...> - 2006-07-01 17:08:14
|
Dave, Would you be interested in a ebMS 3.0 B2B connector? I'm working on one that should be fairly easy to integrate with JBESB. I hope to have it ready by Q4 2006. To be as backwardscompatible as possible I hope to have a ebMS2.0 version available in Q1 2007. I see lots of opportunities for this in Europe as well. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954844#3954844 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954844 |
|
From: ddegroff <do-...@jb...> - 2006-07-01 19:00:58
|
Ronald, I would be most interested. Having ebMS capability along with EDI would offer a pathway to the future of eCommerce. Your involvement in jBPM intrigues me, as well. I am of the opinion that BPM, along with data transformation, offers a powerful platform for extending a core capability to integrate an entity (public or private) within an ESB framework. Is there a website where I can learn more about your connector (from a functional description perspective)? I will be posting a functional description for the capability I've been describing. Most likely, I should create a new topic for this, so that those with similar interest/capabilities can merge their expertise. Agreed? ... and Thank You, Dave View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954850#3954850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954850 |
|
From: kukeltje <do-...@jb...> - 2006-07-01 19:41:15
|
David, (Since this is off-topic, which I as a jBPM forum moderator hate ;-), I'll for now respond one here. Maybe we should indeed start a new thread) I'm currently developing this 'off-line', so there is no website at all. Regarding the functionality, i'm focussing on the following items, ordered by priority 1: Full envelop compliancy (user messages and signal messages) 2: Soap one-way MEP (one way push) 3: Errorhandling 4: Reliable messaging for this mep 5: One way pull 6: Reliable messaging for this mep 7: Request response MEP 8: Reliable messaging for this MEP After this basic functionality, I'll look into storing partner profiles, agreements etc. So on this part I am open to any requirements (I prefere to use LDAP though on the technical level) Only after this, I'll pay attention to persistent security aspects (signing etc) Reliability is the challenge, since there are two competing standards for it, both under OASIS (????? admired and hated by me cause of their flexibility. Speed ok, TWO protocols.... stupid) Maybe JBossWS will include one, I personally have a preference to use the SUN version, WS-Reliability) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954852#3954852 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954852 |
|
From: <mar...@jb...> - 2006-07-02 21:41:59
|
Being a member of both WS-R TC, I can say that OASIS WS-RM is pretty much dead. Despite having superior technology to WS-RX, the realities are that everyone (including Sun) is now looking to support WS-RX. JBossWS will eventually support WS-RX, though that's further down the roadmap. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3954917#3954917 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3954917 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X