Develop Reference

JAVA Spring to MS Azure Logic App and Functions

I am exploring options how to convert my existing java application which has Sprint framework to Azure Cloud server less "Logic App" and "Functions" concept
without re-writing.
As far as i can see, there is no accurate information in microsoft websites.
Can any one please suggest me on the road map, that, how i must lift and shift my java spring frame work to Azure Function?
I am aware of the fact that there will be little modifications that i might need to do, that is ok with me. But not a complete re-write into some other language.
Thanks !

Hard to say exactly but with the new Java support as long any package you are using can be resolved with Maven it should work in Functions. The potential bigger question is what can remain as-is. Likely each of your controller methods would become Azure Functions - the method signature would change but the code inside should remain largely the same (HttpTrigger with a request message to a route). The models should be able to stay untouched. If you had any orchestration or workflows that would become orchestrated by Logic Apps - but since Logic Apps has no-code, it would mean re-creating that workflow/orchestration in Logic Apps.
Java is still in preview so you may hit some snags here and there, but let us know if you have any other questions along the way.

How to consume ad hoc web services (non-SOAP, schemaless XML)?

I need to write integrations to multiple external web services. Some of them are SOAP (have WSDL), some of them pretty much ad hoc - HTTP(s), authentication either by basic auth or parameters in URL (!), natural-language like XML which does not really map nicely to domain classes..
For now, I've done the spike integrations using Spring Web 3.0 RestTemplate and binding using JAXB2 (Jaxb2Marshaller). Some kind of binding is needed because domain classes need to be cleaner than the XML.
It works, but it kind of feels bad. Obviously this partially just because how the services are built. And one minor issue I have is naming of RestTemplate as services have nothing to do with REST. This I can live with. JAXB2 feels a bit heavy though.
So, I'm looking for some other alternatives. Ideas? I'd like to have a simple solution (so RestTemplate is fine), not too enterprisey..

While some of your services may be schemaless XML, they will still probably have a well-documented API. One of the techniques that the Spring folks seem to be pushing, at least from the web-service server side, is to use XPath/XQuery for retrieving only the information you really need from a request. I know that this may only end up being part of your solution, but I'm not sure that this is a situation where one particular binding framework is going to meet all your needs.

If I understand correctly you have 1 application that has to make calls to various external (web) services by use of different technologies. The first thing that comes to mind is to have some intermediate level. While this could be something as elaborate as en ESB-solution, my guess is that is not what you're looking for.
You could for example achieve this intermediate level by having a class hierarchy with at its top an interface 'Consumer'. Method to be implemented: doConsume() and so on.
If you look into it you'll probably have the opportunity to make use of several design patterns like Strategy or Template. Remember to be pro-active and try to ask a few times 'What if ..' (As in: what if they need me to consume yet another service? etc.)
If JAXB feels too heavy there are other API's to be found:
Axis
JAX-WS
CXF
other
It'll depend on the situation which one would be better. If you run into troubles with any of them I'm sure you'll be able to find help here on SO (and from people who have more hands-on experience with them than me ;-)

Need Resources to Learn Java Web Services from SCRATCH

I've bounced around Java and C# the last several years but now want to get up to speed with Web Services (RESTful). I used to be a master of J2EE circa 2003, but have since got side tracked into all kinds of stuff. I've worked through a couple of NetBeans tutorials (my IDE of choice) but they don't seem to expose the nitty gritty. I enjoy seeing how things exactly work, building an app from the byte array up.
Although I've touched a couple of frameworks, I've most enjoyed working with Java EE proper to understand the base case before the sugar of Spring/Hibernate is added.
Does that make sense? I am looking for a book or tutorial that really builds up your knowledge piece by piece so that you understand everything, not some Rails-like toolkit for rapid development.
Thanks-in-advance,
Guido

I'd start by doing a review of HTTP, since in practice this is a fundamental building block of REST web services, and it gets you into the right mindset for what comes next.
Next, think about how you'd structure the URIs for various resources. Martin Fowler wrote a good article on this topic. Various java frameworks for creating web services try to make it easier for you to map requests to specific methods, and even to map parts of requests (including path elements, query parameters, and the entire request body) straight into your object model. But all of this just help with the identification and manipulation of resources through URIs.
Next, if your resources are related, then think about hypermedia controls. You're probably used to putting <a href=""> links in web pages, and you certainly wouldn't want people to hardcode or bookmark every single URL in your website. How does the same idea extend to web services?
Next, think about actually moving data between client and server. JSON or XML? URI element or query parameter? Again, lots of java frameworks exist just to make this easier -- for example, Jackson and Gson for REST, JAXB for XML, etc. -- but the problem of dealing with HTTP-based requests and responses is very similar to the one that your average servlet container solved years ago.
Finally, consider security. For example, username/password or OAuth? HTTP or HTTPS?
There are lots of other details, but these topics should keep you busy for a while.

Have you checked out Jersey yet? This is the Java reference implementation of JAX-RS. There is a great community around this project, and the main author is available via mailing lists and forums and has personally answered questions of mine for some gnarly situations I ran into. The jersey site has a lot of great links to get you started from a variety of angles, depending on what you're interested in learning.

RestifyDayTrader has very good details of how to build a RESTFul service.
Java implementation can be found at Restified Trader

Java Web Services is a good read on learning Web Services.

Pros and Cons of DFC and DFS?

I am new to Documentum, I have to upgrade one code from Documentum foundation class to Documentum Foundation Services. Can someone provide the pros and cons of each, and good source of information to get started with it.
btw, I am writing code in Java to get information from documentum.

DFS is an abstraction layer on top of DFC.
SourceRebels is partially right, except for the detail that EMC is now treating DFS as a primary model of integration for external applications (API). You no longer need to use a compiled language (Java or .Net), since you can do everything via SOAP webservice calls. DFC remains available for low-level interaction, but with every Documentum release there are more services added to DFS.
One of the key differences is the object model. In DFS, you can create a batch of operations to send to the server for execution (for instance, create 10 objects). There are also some complex operations in DFS that would take much more code to accomplish using DFC. DFS also allows you to deploy your code to machines without the DFC installed.
Your best resource for Documentum-related questions is http://developer.emc.com.

IMHO they are not comparable because they are not focused on the same. DFC is an API to access Documentum while DFS is a service framework with some predefined services providing some functionality to interact with Documentum.
Thats important: I never used DFS :-)
DFC = Do-it-yourself. Traditional Client-Server programming. Faster.
DFS = Use predefined services or do it yourself for non-trivial tasks. SOA. Probably you need to deploy your services in a new server or purchase more Documentum licenses (not sure about that). Slow but I will feel more comfortable using this if I want to access Documentum from some legacy systems.
Thats my grain of salt I hope you find it useful.

DFS is the new age API for Documentum ( built on the web services concept). You need to read the documentation for DFS which is pretty explanatory. In addition to this you need to have a basic understanding of web service calls (exposing a service, WSDL, building remote clients).

Should I invest in GraniteDS for Flex + Java development?

I'm new to Flex development, and RIAs in general. I've got a CRUD-style Java + Spring + Hibernate service on top of which I'm writing a Flex UI. Currently I'm using BlazeDS. This is an internal application running on a local network.
It's become apparent to me that the way RIAs work is more similar to a desktop application than a web application in that we load up the entire model and work with it directly on the client (or at least the portion that we're interested in). This doesn't really jive well with BlazeDS because really it only supports remoting and not data management, thus it can become a lot of extra work to make sure that clients are in sync and to avoid reloading the model which can be large (especially since lazy loading is not possible).
So it feels like what I'm left with is a situation where I have to treat my Flex application more like a regular old web application where I do a lot of fine grained loading of data.
LiveCycle is too expensive. The free version of WebOrb for Java really only does remoting.
Enter GraniteDS. As far as I can determine, it's the only free solution out there that has many of the data management features of LiveCycle. I've started to go through its documentation a bit and suddenly feel like it's yet another quagmire of framework that I'll have to learn just to get an application running.
So my question(s) to the StackOverflow audience is:
1) do you recommend GraniteDS,
especially if my current Java stack
is Spring + Hibernate?
2) at what point do you feel like it starts to
pay off? That is, at what level of
application complexity do you feel
that using GraniteDS really starts
to make development that much
better? In what ways?

If you're committed to Spring and don't want to introduce Seam then I don't think that Granite DS will give you much beyond Blaze DS. There is a useful utility that ensures only a single instance of any one entity exists in the client at any one time but it's actually pretty easy to do that with a few instances of Dictionary with weak references and some post-processing applied to the server calls. A lot of the other features are Seam-specific as alluded to here in the docs:
http://www.graniteds.org/confluence/display/DOC/6.+Tide+Data+Framework
Generally, the Tide approach is to minimize the amount of code needed to make things work between the client and the server. Its principles are very similar to the ones of JBoss Seam, which is the main reason why the first integration of Tide has been done with this framework. Integrations with Spring and EJB 3 are also available but are a little more limited.
I do however think that Granite's approach to data management is a big improvement over Livecycle's because they are indeed quite different. From the Granite docs:
All client/server interactions are done exclusively by method calls on services exposed by the server, and thus respect transaction boundaries and security defined by the remote services.
This is different to how Livecycle DS uses "managed collections" where you invoke fill() to grab large swathes of data and then invoke commit() methods to persist changes en-mass. This treats the backend like a raw data access API and starts to get complicated (or simply fall apart entirely) when you have fine-grained security requirements. Therefore I think Granite's approach is far more workable.

All data management features (serialization of JPA detached entities, client entity caching, data paging...) work with Spring.
GraniteDS does not mandate anything, you only need Seam if you want to use Seam on the server.

Actually, the free version of WebORB for Java does do data management. I've recently posted a comparison between WebORB for Java, LiveCycle DS, BlazeDS and GraniteDS. You can view this comparison chart here: http://bit.ly/d7RVnJ I'd be interested in your comments and feedback as we want this to be the most comprehensive feature comparison on the web.
Cheers,
Kathleen

Have you looked at the spring-blazeDS integration project?

GraniteDS with Seam Framework, Hibernate and MySql is a very nice combination. What I do is create the database, use seamgen to generate hibernate entities then work from there.