I was watching a webinar made by lightbend talking about refactoring monoliths into microservices and a question came to me. The framework's main target seems to be refactoring monoliths, but lagom seems to run on its own container and set of technologies. When I think about monoliths and legacy Java apps, the main technology that came to my mind is Java EE. I think most of the applications in productions today rely on some Java EE technologies. The one I work in is based on EJB's mostly. So my question is: how Lagom solves this issue? I imagine refactoring this kind of application involves convert the remote EJB lookup into rest calls. But how would I keep the local EJB's of my application if lagom does not run in a Java EE container? Is it possible to use both?
I don't have a deep knowledge about Lagom, however, the market that is using architectures based on Microservices are heavily relying on spring boot/cloud. Currently, I'm working on a really large project using Microservices and it seems that the spring guys provide a lot of frameworks/tools for each microservices pattern that you should have in mind when you're thinking in microservices. By other hand, Netflix (the biggest microservices user) rely on Spring, I think that Spring Boot/Cloud is a good way to refactor your Java EE monolithic app to microservices
I suggest watching https://vimeo.com/163760711. The answer is that you shouldn't just be taking your EJBs and turning them into services, if you do that, you'll just introduce all the complexity and performance pain of having many services, and get none of the benefits of microservices. You need to rethink your architecture if you want to benefit from microservices.
You can start with representing your existing EJB services with a set of REST web-services, which in turn will be consumed by your new Lagom-based microservices, like this:
[EJB services] <- [EJB based REST services gateway] <- [Lagom based microservices]
or as deployment modules:
[your EJB app .EAR] <- [EJB-REST gateway .WAR] <- [Lagom based app]
Since your EJB app will run in a container (e.g. Wildfly), your Lagom app will be deployed independently (possibly on different host). Introducing the REST Services layer will allow you to develop each of the modules independently, which is the key to success in this case.
Next, gradually you would implement new functions and possibly reimplement some of the legacy functions in the new Lagom based app.
This is exactly what I did, and it works like a charm.
Related
I've started looking at osgi with the main purpose to achieve the task ahead of me. Basically i would be able to distribute an web based application and build specific features of the whole web app separately in such a way that i can deploy at A my web app with features a,b,c and deploy at B with features a,c,d.
A little like how one can install plugin in joomla. So for example when i want to add a different aspect of the web application, i would build a small war with all the html and its admin section and have this feature admin section available in the main admin panel.
Second question is about Spring DM. most likely i will be using Spring and it seem logical i see what Spring DM has to offer.After downloading Spring DM .1.2.1 i found out that its lib folder contains spring jars for version 2.5.6.SEC01 but i planned on using 3.1.2 so am a little confuse as how everything will play nice together.
Thanks for reading
I've just been doing such an exercise so I can shed some light how you do it without the overhead of Spring. I've made a clear division: all application code is in the browser, all data handling is in the server. With HTML5 the browser has grown up to an impressive, portable, and powerful application environment. One has multiprocessing, messaging, modularity, and amazing visuals. I am using angularjs as the framework in the browser.
Angular works with a central routing table mapping the hash part of the page url to "modules" in Javascript. This makes it very easy to define what modules are part of the application. The server can easily control this part.
On the server side I have bundles that carry the Javascript code, the html fragments and the data handling. I based this on the OSGi Http Server model since it is more flexible. However, I added proper support for static resources in bundles: caching, streaming, ranges, etc.
In the server I used DS and bndtools to develop the bundles. This is an impressive development experience since it works like Smalltalk. You change and it is immediately reflected in the server. Adding bundles, removing bundles, the server keeps on running. Server restarts are rare during development.
The disadvantage is that there are unfortunately very few components that leverage OSGi. Most components, with Spring being the archetypical example, rely heavily on class loading hacks to wire applications from a central point. This is fundamentally not modular. For this reason I had to develop many highly cohesive and uncoupled components that leverage the OSGi service model. Once I get time I will donate them to an open source project.
I'm not sure you need to be considering OSGi, at least not directly, to achieve your state requirements. You said:
Basically i would be able to distribute an web based application and
build specific features of the whole web app separately in such a way
that i can deploy at A my web app with features a,b,c and deploy at B
with features a,c,d.
If these are youre requirements, then you don't actually need to concern yourself with OSGi directly, but rather find a web app framework that supports modular extensions. Which most likely means that the framework itself uses OSGi. I'm not familiar with Spring, but I do know that Struts 2 ( a comparable web app framework ) has an OSGi based plugin meant to achieve your use case.
On the other hand, if your idea is to play with OSGi, then I suggest you pick a lower level task, such as writing a web application framework, rather than a web app itself.
Assume we have a .NET application that exposes its web services. This app needs to be integrated with our J2EE application running on Weblogic. Both are internal applications so we don't worry too much about security.
There are no really complex data structures/types so we should be able to map them between .NET and Java tier (or at least write adapters on the Java tier to ensure the match).
What is the best approach of consuming these .NET web services in the J2EE application?
The simple approach would be to just generate WSDLs for the .NET web services, and generate Java client classes using wsdl2java or other similar tool and see if that can work without adapters/changes, create unit tests, etc. But in case of data related challenges we may need to deal with XSD/Schemas, generating classes, etc.
I know there is WSIT to deal with interoperability issues, but want to keep this as simple as possible. Any thoughts, ideas?
You could connect the two applications with a RESTful API. This lets them talk in a shared, high level API over HTTP. Both languages have plenty of support for both creating and using HTTP/RESTful services, so this should be fairly simple to implement in either language.
I'm currently working on a specification for a web application which consist of a administration interface, and a set of web-services which will be consumed by parter websites.
I been playing around with GWT and it seems like an amazing fit for the administration interface, but at the same time, I would love to use the Spring framework to produce the REST based web-service API exposed by the application.
My plan is to create two separate web applications, one for the admin and one for the web-services. One set up for spring and the other with the GWT app. Obviously, I wish to share the domain model between the two applications, I'm guessing this should be fairly trivial to accomplish? I'm thinking just to keep it simple, implement the full domain model in the GWT client project, and simply setting the sourcepath of the web-service to include the domain model from the relevant folders in the GWT project.
Now, to my question. I'm sure somebody out there have done something similar to this, are there any potential pitfalls I should be aware of before starting out?
I got a fair amount of time set aside for this project, but I never actually used GWT before for anything "serious" I just played around with it out of personal interest and I'm fairly experienced in both Swing and Android UI development, so I'm confident I can mange to use it for the (very simple) UI. The "unknown" in this equation is sharing of a domain model. I cant imagine this being a problem, since the domain model will be just POJO's (using JDBC, but again, I cant really imagine this being a problem).
Also, are there better ways of integrating GWT and Spring than simply doing to separate web applications and sharing their domain model?
Why do you want to create two separate applications?
Create one, with a clearly separated application services tier. Expose this services via standard Spring annotations as webservices, and also expose access to this services via GWT requestfactory (unfortunately, as far as I know, currently requestfactory does not play nice with REST requests, mainly because their way of serialization). This approach results in only one entrance (facade) to your application and allows to use this facade in two different ways.
I've worked on several GWT+Spring projects - for standard cases development goes very fast, frameworks integrates very well. However, if you want to do some customization, e.g. introduce security based on spring security - you will need to do some hacks, such as overriding transport classes. Of course it takes some time, but results are very nice.
I would definitely recommend to take a look at Spring ROO sample applications (as far as I know, roo is partially developed by google guys).
I'm developing a web application with multiple frameworks (spring, hibernate, spring-security, ZK for GUI), and using Tomcat as app server. I must say I have absolutely no experience with java web services technologies. Thing is, I will almost certainly have to expose number of services for some external applications in the near future, and I was wondering what would be the way to go (considering the frameworks I'm using)...
I saw and read various tutorials and some questions (link) regarding Axis, Axis2, JAX-WS... Thing that confuses me a little bit is that I don't know what is the common practice (if any) to integrate services within existing web application (mainly in the terms of project organization). As I see it now, these services that I need to implement will rely partially on the existing source code, so I don't know whether I should use completely separate project, or I can put it inside my existing web app folder (which I tried with Axis2, but don't know if it's a good practice).
Thanks.
How to organize the projects?
In general I agree with #ericacm, but there is one thing you should keep in mind... You said you're going to develop a number of services in the near future. You may come to a point at which you want to host the services on a separate server, e.g. for performance, availability or maintainability reasons. This may influence your decision of separating the projects. Furthermore, separation "enforces" loose coupling, but therefore introduces other challenges like session sharing across multiple WARs. It's a case-by-case decision.
If I were in your situation I'd first ask myself whether the service(s) logically belongs to the web application or not.
Implementation
When in comes to WS-* implementations you have to make 2 decisions:
Decide for an API to use; today, I can't see any reason for not going with JAX-WS together with JAXB as API, they work well and they are standardized.
Decide for a Framework; I've experience using Axis2 as well as METRO (keep in mind that JSE 1.6+ provides basic JAX-WS support). Both work well. It's fairly easy to change the frameworks if you use the JAX-WS APIs.
I have good experience with Spring-WS 2+ and manual Castor mapping . Is is easy but powerful combination.
Spring-ws 2:
provides contract-first development (specially good for the web app with number of services).
provides WS annotation
supports XML mapping (Castor, JaxB, etc)
Castor:
mapping based on xml configuration
allows map multiple messages (requests/responses) to one java object (based on xml configuration)
If you are using some Java EE 6 server, consider also JAXB for manual mapping:
mapping based on annotation
should be faster than Castor
allows map multiple messages (requests/response) to one java object (when you use java inheritance)
You can go ahead and put them into the same project. Each web service will be an additional interface and implementation class along with some configuration.
Since you are using Spring CXF is a good choice as a for JAX-WS as it integrates well with Spring. See this page as a starter.
Spring-WS is complex framework for simple web services. If you want to understand web services completely and to know the nuts and bolts of web services, learn Spring-WS. It is extremely flexible and provides lot of options.
Else, if you want simpler alternative use JAX-WS. Spring supports JAX-WS annotations. Refer to the section 17.5.7. Exporting web services using the JAX-WS RI's Spring support.
http://static.springsource.org/spring/docs/2.5.x/reference/remoting.html
Is it possible to create WS Server and WS Client manually (without generators) by JAX-WS? Specially if you are developing a big application you want to re-use objects but generators are generating a lot of classes that can be in 99% the same (for example if your app is WS Client and you have to connect to badly designed external WS Server). Is there some tutorial how co create ws manually?
There is a lot of reasons why I don't like generators and completely agree with http://ogrigas.eu/spring/2010/04/spring-ws-and-jaxb-without-a-code-generator
I have experience developing java web applications with Spring, but not so much with the world of SOA. I was reading about SCA- SCA4J - http://www.service-conduit.org/user-guide.pdf - and alot of this seems very similar to Spring.
I was trying to learn about what situations SCA would be useful, but still dont understand what features / benefits SCA offers over using Spring standalone.
I found this old blog post - http://rajith.2rlabs.com/2007/08/05/sca-vs-spring-a-reply-to-dans-post/ - but nothing really stood out to me from the SOA jargon.
I'd appreciate it if anyone could give an explanation geared more towards a spring developer (who is very green in the world of SOA terminology / methodology).
Thanks
I'm not the most knowledgeable about Spring, but am pretty familiar with SCA from having worked with it in IBM's WebSphere Integration Developer IDE and the environments it deploys to: WebSphere Enterprise Service Bus and WebSphere Process Server.
It really all has to do with abstraction and the thought of allowing developers to focus on what is most important - business logic. We are all familiar with the concept of Object-Oriented Programming and how that abstraction better represents the "real world". Then along comes web services and the service-oriented architecture approach. Web services further abstract our logic by making it less dependent on what language is behind our logic. Now C++ or .Net or Java or even RPG or COBOL or whatever could be behind our web service. We can get languages and systems to talk to each other in a way that doesn't depend on CORBA and libraries and what not.
SCA (Service Component Architecture) attempts to take SOA to the next level. It attempts to abstract the protocol and address used to talk to another system or service. Here's the why: With working with web services, you as a developer still need to work with protocol and write or hook in a LOT of boilerplate code. You have to know if you are http or https. You have to know if you are (in the Java world) JAX-RPC, JAX-WS 2.0, JAX-WS 2.1, JAX-WS 2.2 or even JAX-RS (REST based). You need to know if you are working with JSON, XML, or SOAP and if SOAP, is it 1.0, 1.1, or 1.2? And sometimes you even have to know how the vendor of your application server implements certain things (you shouldn't, but it can be the case). And then what happens if you want your web service to talk to another service. But that second service happens to be messaging based. Does that mean JMS? MQ? JMS over MQ? other? And what about just pure HTTP POST and GET?
This is where SCA comes in. SCA attempts to abstract the end points of your services and hide the protocol implementation from you the developer. When you need a service you just look it up via the SCA API's and then invoke the service (I think the method is execute? At least it is in IBM's extension of SCA). But anyway....Now you do not have to know that the service you are communicating with is JAX-WS 2.1 or REST or even MQ. You don't have to know that you working with SOAP/HTTP or JSON/XML or SOAP/JMS or whatever. SCA hides this all from you. It allows you to connect services of differing implementations to each other so they can all talk to one another via a common "service interface".
As you can imagine, this is another layer of abstraction and technology on top of existing abstracted technologies. But having seen it myself, I believe it is worth looking into. I know IBM and Apache (and I think others that just don't come to mind at the moment) worked on coming up with the SCA standard. (And actually IBM's version of SCA is now built on the open standard that Apache presented. Hopefully other vendors that support SCA do the same.)
I think it is worth taking the time to look at. It can help you to focus not so much on the integration of services based on their protocols, but rather the business logic of the services, which is really the value they bring to the table.
SCA is being standardized through OASIS (Assembly Specification), so you can chose from different implementations (e.g. Apache Tuscany or Fabric3).
SCA defines applications in terms of the following basic building blocks:
interface: defines available operations
component: describes an implementation artifact in terms of which "services" it offers, which "references" it requires, and which configurable "properties" it exposes
binding: declares the communication protocol used by a service or reference
policy: captures non-functional requirements for services, references, or implementations
To build SOA applications, concrete "types" of these entities are assembled into composites. For example:
interface: WSDL port type, Java interface
component implementation: Java class, BPEL process, Python, Spring
binding: JMS, Web Service, RMI/IIOP
policy: transaction, security
In addition, SCA defines unified client APIs to invoke components both synchronously and asynchronously (including one-way). For Java this includes annotation-based reference injection.
Combining these capabilities enables you to easily create distributed applications from heterogeneous technologies and evolve them by adding or swapping binding, implementation, interface, or policy technologies.
It is worth looking at Spring Integration (http://www.springsource.org/spring-integration) as opposed to basic Spring when comparing to SCA, since Spring Integration offers a very nice framework for transparently wiring together remote components.