Best way for convert dateTime (xml constraint) to date object?

[montyshaw1 (montyshaw *)]

Dude, you are a real trip. I’ve really enjoyed this discussion. Yes I always start out in FLOW until the if statements get too nested or I just have to use Java or C#. I agree that you should always start out doing the implementation in FLOW. What you usually find out is that it is enough. But and it is a big butt, basically what I’m leaning towards is to not do anything other than ‘glue’ and mapping in FLOW. The fundamental business logic (whatever that means) needs to be done in real code.

And I don’t mean to be condescending, but I’m not going to argue obvious generally recognized truths on an internet forum. You get it or you don’t. Kind of like: I’m OK, sorry about you.

jtu100 - We’re just having fun. This kind of exchange is what is good about these forums. So we disagree, but at least we know why we disagree.

As far as .Net support, it is going to be great. I use the future tense because sadly, for what ever reasons, the .net support Web Methods added in 7.1 just didn’t get proper QA. I think it fell thru the cracks with the SAG transition. webMethods is getting the bugs I’ve reported fixed, but it would help if everyone tried it out and reported your problems as well. Believe me it won’t be hard to find a problem. Anyway, they supply a nice addin for visual studio 2003/2005 that allows you to connect to IS and select either services or documents and generate code. If you select a document, it generates code to serialize and deserialize an object version of the document into and out of the IData object (the pipeline). If you select a service, it generates everything you need to call the service. And deployment is simply copying the .net assembly to the server and then using Developer to define a .net service. And you can have the .net service run under a named app domain, so redeployment is a simple as shutting down the app domain and copying a new assembly to the server. It really is slick. Or really will be slick once they get it debugged.

They have also added some great web service support in 7.1, like contract first support where you give it the wsdl and it creates stubbed out services for you, and the new web service descriptors support consuming web services (based on wsdl) and exposing services as web services. Much easier than the old way of doing SOAP in previous versions (again will be much easier after the bugs are fixed) Also they default now to document-literal which is a nice touch. I’ve heard that Microsoft helped them with this new feature, and theoretically they did a nice job. Just way too buggy at the moment. Give them time.

I would recommend skipping 7.1 and going right to 7.1.1 as it has at least 2 of my bug fixes incorporated into it. There are more coming.

]Monty[

[jtu100]

@montyshaw

As far as .Net support, it is going to be great. I use the future tense because sadly, for what ever reasons, the .net support Web Methods added in 7.1 just didn’t get proper QA. I think it fell thru the cracks with the SAG transition. webMethods is getting the bugs I’ve reported fixed, but it would help if everyone tried it out and reported your problems as well. Believe me it won’t be hard to find a problem. Anyway, they supply a nice addin for visual studio 2003/2005 that allows you to connect to IS and select either services or documents and generate code. If you select a document, it generates code to serialize and deserialize an object version of the document into and out of the IData object (the pipeline). If you select a service, it generates everything you need to call the service. And deployment is simply copying the .net assembly to the server and then using Developer to define a .net service. And you can have the .net service run under a named app domain, so redeployment is a simple as shutting down the app domain and copying a new assembly to the server. It really is slick. Or really will be slick once they get it debugged.

How do you call the .NET service from flow then? That’s the bit I dont get. From what you describe it sounds like you are talking about calling a flow from .NET? Can you call .NET from flow? Does it let you publish and subscribe from .NET? Can you host those .NET objects inside IS?

I think I need to actually install 7.1 and have a play!

[montyshaw1 (montyshaw *)]

Within 7.1 developer there is a way to create a .net service. You have to select an assembly on the server machine, and then select the method within the assembly that you want to expose. I find it easier to create the input and output documents within Developer and then use the addin in Visual Studio to create the code to serialize/deserialize it. I also then create a function that has the following signature:

public IData SomeServiceMethod(IData input).

After you create the .net service in Developer you can now call your .net code from another service, like any other service.

That said, you will run into a bunch of problems trying to do this.

Also currently, webMethods only supports 2.0. I don’t know when they will have 3.5 support.

]Monty[

[reamon]

@montyshaw

Dude, you are a real trip. I’ve really enjoyed this discussion.

[In my best Joe Pesci impersonation]: Do I amuse you?

@montyshaw

Yes I always start out in FLOW until the if statements get too nested or I just have to use Java or C#. I agree that you should always start out doing the implementation in FLOW. What you usually find out is that it is enough. But and it is a big butt, basically what I’m leaning towards is to not do anything other than ‘glue’ and mapping in FLOW. The fundamental business logic (whatever that means) needs to be done in real code.

Agreed on all points, though you and I may differ on what “too nested” is. We also will undoubtedly differ on when one just “has to use Java or C#.”

On average, how much of a given integration in your environment is Java and how much is FLOW?

I agree too, that business logic should be in so-called “real” code–which should be elsewhere, not hosted in IS. The integration layer is no place for business logic, generally speaking.

@montyshaw

And I don’t mean to be condescending, but I’m not going to argue obvious generally recognized truths on an internet forum.

It wasn’t entirely clear in the thread, but my comment about being condescending applied to your comment “people that really don’t know how to code, and maybe should stick to Flow.” I don’t think that qualifies as a recognized truth.

Or perhaps you thought my comment pertained to the supposed FLOW vs. Java argument? As mentioned earlier, my argument has never been about which is the better language.

@montyshaw

You get it or you don’t. Kind of like: I’m OK, sorry about you.

Throwing your hands up and saying “you just don’t get it” is an easy way out. For example, instead of explaining to you that XML is typeless and that XML data elements are strings that are constrained by a separate (and independent) XSD and thus the statement “in xml they truely are those data types” is just outright wrong, I could have simply said “you just don’t get it”, or “that’s BS.” But those aren’t compelling arguments.

Make a case for your points. Don’t hide behind self-aggrandizing rhetoric.

[montyshaw1 (montyshaw *)]

@reamon

Agreed on all points, though you and I may differ on what “too nested” is. We also will undoubtedly differ on when one just “has to use Java or C#.”

On average, how much of a given integration in your environment is Java and how much is FLOW?

You use Java or C# or C/C++ when that is the only way to get at legacy code.

@reamon

I agree too, that business logic should be in so-called “real” code–which should be elsewhere, not hosted in IS. The integration layer is no place for business logic, generally speaking.

Almost all of my legacy apps are not service oriented. When I need them on the bus, I will write a service layer in the legacy’s native language and expose them within IS.

@reamon

It wasn’t entirely clear in the thread, but my comment about being condescending applied to your comment “people that really don’t know how to code, and maybe should stick to Flow.” I don’t think that qualifies as a recognized truth.

By that I mean if you look at Java/C/etc as something to avoid, and feel that FLOW is equivalent, then you should probably stick to FLOW. Unfortunately, FLOW is not a very well thought out language, can only be written using developer, does not support refactoring, and has insufficient program control constructs for me to even consider doing more than mapping and invocation. It would be like saying this edit window I am typing this into is just as good as a word processing program. I am able to create a document, what is the problem?

@reamon

Throwing your hands up and saying “you just don’t get it” is an easy way out. For example, instead of explaining to you that XML is typeless and that XML data elements are strings that are constrained by a separate (and independent) XSD and thus the statement “in xml they truely are those data types” is just outright wrong, I could have simply said “you just don’t get it”, or “that’s BS.” But those aren’t compelling arguments.

Sigh… come on we were talking about XML from the stand point of IS and documents etc. If you are dealing with XML in that scenario, you most likely have an xsd that does describe a strongly typed document. You then create an IS document type from it, and suddenly everything is a string. To say a string is constrained to a certain format (for example the on-the-wire format of a date or integer defined by xsd) is not that same as saying it IS a date or integer. At some point I have to say you just don’t get it if you don’t, in fact, get it. I am willing to stop at the point where I obviously am not going to change your mind.

@reamon

Make a case for your points. Don’t hide behind self-aggrandizing rhetoric.

No I won’t :p:

]Monty[

[reamon]

@montyshaw

You use Java or C# or C/C++ when that is the only way to get at legacy code.

Almost all of my legacy apps are not service oriented. When I need them on the bus, I will write a service layer in the legacy’s native language and expose them within IS.

Cool. I think we’re closer in our philosophies and approaches than this thread might lead one to conclude.

@montyshaw

By that I mean if you look at Java/C/etc as something to avoid, and feel that FLOW is equivalent, then you should probably stick to FLOW.

I’ve never claimed that FLOW is equivalent to Java. Your comments seem to indicate you feel I’m holding FLOW up as some awesome piece of work. I’m not.

The primary language for IS is FLOW. Java services are next to an afterthought, which is reflected in all the warts you’ve rightly pointed out.

@montyshaw

Unfortunately, FLOW is not a very well thought out language, can only be written using developer, does not support refactoring, and has insufficient program control constructs for me to even consider doing more than mapping and invocation. It would be like saying this edit window I am typing this into is just as good as a word processing program. I am able to create a document, what is the problem?

We agree then. FLOW is reasonable for mapping and invocation. As mentioned before, I haven’t come across a control construct that couldn’t be handled within FLOW.

The proprietary nature of FLOW and Developer are indeed significant constraints. Refactoring is indeed a big pain. And mapping large documents is just a pure joy! Click, click, click, click, click, click…auugh!

We also agree that using this little editor for this forum is okay and that using Word would be overkill. So it goes with FLOW and Java in IS, sort of. FLOW is the primary language. Java can be used to augment things. For integration work, FLOW is sufficient a majority of the time, IME. If one wants to use Java primarily to develop integration solutions, then my opinion is that IS is not the right tool.

@montyshaw

Sigh… come on we were talking about XML from the stand point of IS and documents etc. If you are dealing with XML in that scenario, you most likely have an xsd that does describe a strongly typed document. You then create an IS document type from it, and suddenly everything is a string.

A great summary. I can definitely see where having the option to have the XSD import wizard generate fields with native types could be desirable. Personally, I would still keep the fields as strings for the aforementioned reasons. I’d still be able to validate for structure and content constraints in incoming and outgoing documents without issue.

I assume I haven’t swayed you on the legitimacy of this approach.

@montyshaw

To say a string is constrained to a certain format (for example the on-the-wire format of a date or integer defined by xsd) is not that same as saying it IS a date or integer.

But that is EXACTLY what you said. “…where in xml they truely are those data types.” If you mispoke, or I misunderstood you, then that disconnect is now clarified. We agree then, XML data elements are strings which can be constrained by XSD.

@montyshaw

I am willing to stop at the point where I obviously am not going to change your mind.

This got me thinking about who’s trying to change who’s mind on what? Let’s see if I can summarize the positions (in no particular order):

1. Integration Server and Developer
   R: IS is great for integration.
   M: IS is great for integration.

R: Developer stinks at refactoring.
M: Developer stinks at refactoring.

R: Exception handling is sufficient. There are quirks to work around.
M: Exception handling is awful.

---

2. FLOW and Java
   R: Most integrations should be comprised mostly of FLOW services. Java services should be minimal. Use Java when required for interaction with another component.
   M: Start off with FLOW and use Java as needed when FLOW is insufficient or becomes cumbersome. Use Java when required for interaction with another component.

R: Developer/IS is not great for developing Java. Getting externally developed code into IS as Java services has issues.
M: Developer/IS stinks for developing Java. Getting externally developed code into IS as Java services has issues.

R: FLOW can be used sufficiently for the majority of control constructs.
M: FLOW stinks at flow control.

R: FLOW has many flaws and constraints. Developer has some usability issues.
M: FLOW has many flaws and constraints. Developer has some usability issues.

---

3. Strong typing vs. weak typing
   R: Use schema validation techniques to enforce structural and content constraints, when required. Use weak typing within integration services (e.g. keep data elements in string representation). Use native types and objects only when needed for manipulation. Use strong typing at the borders, if needed, otherwise use weak typing.
   M: Use schema to both enforce constraints and convert to native types/objects that are then used within integration services. Use strong typing throughout.

Does that summarize our thread and differences of opinion accurately? Are there others I missed?

Purely out of curiosity, how long have you been working with wM products? Just IS and BPM or have you worked on other components too?

[montyshaw1 (montyshaw *)]

Uncle! You win

But that is EXACTLY what you said. “…where in xml they truely are those data types.” If you mispoke, or I misunderstood you, then that disconnect is now clarified. We agree then, XML data elements are strings which can be constrained by XSD.

This is the only place we still disagree. A date is IMPLEMENTED as a string in a file that is said to have XML in it (and would be described by meta-data in an XSD file as a date). Conceptually, it is not a string, it IS a date. Physically on-the-wire, it is a string conforming to a specific format.

Purely out of curiosity, how long have you been working with wM products? Just IS and BPM or have you worked on other components too?

I’ve mostly been doing IS stuff for 4 or 5 months. I’ve been to class on BPM, but haven’t done anything in it.

]Monty[

[reamon]

@montyshaw

This is the only place we still disagree. A date is IMPLEMENTED as a string in a file that is said to have XML in it (and would be described by meta-data in an XSD file as a date). Conceptually, it is not a string, it IS a date. Physically on-the-wire, it is a string conforming to a specific format.

With that clarification on what you meant, we agree.