It is a basic question. What is the main advantages of using the service builder? If my portlet doesn't have anything to do with database, everything is of using webservices, will service builder help in any case like caching? will the service builder provides service layer, so that i can apply AOP on it ?
You can create a Service without any attrs, so service builder will create all the services and injections for these services.
The advantage maybe could be having a service wrapper, You can also use Liferay Catching solution.
For example you use services classes, and create method that calls Web Services.
Well there you can use the liferay cache solution.You can take a look to this class: MultiVMPoolUtil.java
Hope this helps
Related
After read the Gordon's article about Best Practices to build Enterprise Application using Spring Framework, I would like to share some ideas about the Service layer.
My architecture represents exactly what Gordon described in this image http://gordondickens.com/wordpress/wp-content/uploads/2012/07/Spring-App-Layers.png
The application is complex, has a heavy business rule and demands to use different resources like Database, SOAP, REST and file handle sometimes in the same use case.
For this scenery that I have described above, I have a Service class that needs to perform SOAP and REST requests and handle some database data. So, I have autowired in my Service class a SOAP and a REST component and the Repository to handle the database stuff.
I'm concerned about if this is the best approach do handle the integration between my Services and the resources like SOAP, REST, Database and etc.
Thanks
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds problematic even though it will work.
Think about the dependency between layers. Service layer will depend on Repository layer (Business logic layer will depend on data layer). Service integration layer (or service communication layer) for incoming requests will depend on the Service layer. But the data layer does not depend on the service layer. Nor the service layer depend on the inbound service invocation layer.
So, remove the SOAP and REST components from the Service class. To the SOAP and REST components, wire the Service instance (i.e. avoid SOAP and REST components wired into the Service, do it in the reverse direction).
This way, when you want to support another integration protocol (say JMS), you do all such work not by modifying your service.
Your data access seems to be fine. I hope your Service accesses the repository via DAOs.
So, I have autowired in my Service class a SOAP and a REST component
and the Repository to handle the database stuff.
Sounds fine. You are using dependency injection, this means they can be easily tested or altered.
I have a requirement to expose my business logic in RESTFul API. One of my colleague mentioned Dropwizard seems to be quite good. However i would like to know if it suits my requirements. My requirement is to invoke multiple SOAP services and REST APIs to build the application logic.
Does dropwizard have anything native support for consuming soap services / rest apis ?
or
i should integrate with other frameworks like Spring, CXF ? If i use CXF or Spring, i am aware that i will need to generate the JAXB annotated classes, Service endpoint interfaces etc, provide cxf beans and inject the dependencies into my code and implement business logic.
Pls let me know if the requirements can be met with just dropwizard without any other frameworks like spring, cxf etc ?
Thanks a lot for your help.
Yes, you can invoke external REST Services using this library
dropwizard-client
Demo example is given in this manual.
I'm developing a new application based on Spring MVC and Hibernate for data access.
I want the data access layer to be running on a separate application server, preferably JBOSS.
I want the data access layer to be running behind a firewall.
How can I achieve this?
Right now I'm concerned about hibernate lazy initialization in this scenario. Would there really be any problems with Hibernate lazy initialization?
There could be some performance penalties to this approach - the IO will be a bottleneck. However, Spring Remoting allows you to easily achieve this.
Create an interface for you DAO.
Implement the concrete implementation.
Use spring remoting to export the interface.
Inject the interface - from your apps point of view its just something that implements the interface. It doesn't care the the calls are being fired off to the remote server.
The mechanism for achieving this is called DynamicProxies - a Java SE feature. DynamicProxies allow you to provide a class that responds to the method calls on an interface at runtime. In this case the method calls are dispatched across to the corresponding methods on the remote server.
Both the service layer and DAO layer servers should be behind the firewall on the same domain.
From the UI, use REST web services to fetch the data from application server (hosting the DAO's and Transactional services). Annotate the entity classes with #Proxy(lazy=false) to avoid lazy loads of entities. For the server to validate the clients (web application querying the business layer behind firewall), use client identity certificates, you can use Bouncy Castle CMS APIs to validate the identity, trust and message integrity. If you have SSL offloaders in network, use detached signatures in http(s) headers.
Is there any way to create a custom mediator that access existing osgi services?
Basically I already have some functionality published as OSGi Services, that I want to be able to call from a custom mediator, but I can't find any way to get access to them. While the class mediator allows for creating instances of classes exposed through osgi, it doesn't appear to allow for the injection of other osgi services.
If you cannot do it using the class mediator, you can write a complete mediator. It will allow your mediator to access OSGi services as other mediators.
These three blog posts describes how to create a such full featured mediator for WSO2 ESB.
Part 1
Part 2
Part 3
And this is how to create a such mediator using WSO2 Developer Studio.
So we've decided to rebuild an application in our business since it's been sitting in Sharepoint for no apparent reason other than to make use of its document indexing feature.
We've decided to create our new app in ASP.NET MVC3 using C#. We're trying to decide on the overall architecture.
I was thinking something like the following:
Core - domain objects (poco's)
Data - Entity Framework (Code First) or nHibernate exposed as Repositories
Service - This layer would encapsulate any business logic and act as a facade. This could be broken down into further modules.
UI (MVC) - Controllers and Views.
This would all be tied together using a DI container such as Autofac.
We also want to be able to write unit tests so we need to be able to mock our service layer and data repositories for testing our controllers etc.
So - does the above sound like a good overall architectural pattern for a pretty standard business application?
The idea being that data, service, ui can reference Core but the UI would only really talk to the service level components and not know about the implementation details of data etc.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming?
OR
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
Any thoughts would be really helpful as I don't know what best route would be.
Should we use a WCF service as our service layer facade in nTier application
Depends on if any other application than the MVC application is going to talk to the service.
MVC3 is the only app: You aint gonno need it
Other apps too: Sure. Do it.
What, in your view, would be the best option. Build the service layer in WCF and call this from our Controllers in MVC? If so would this be testable or would we need to write a wrapper around the web service? Could this be time consuming
Don't use the concrete service classes. Use the service interfaces. Problem solved.
My next question is that at some point we're going to want to expose some functionality outside our application i.e. WCF Services/ASP.NET Web API
I hope that you mean the same WCF service.
Continue writing a service layer (i.e. Service1.CreateObject(object obj);) in C# classes and create a web service as a separate entity exposing just the functionality we need that calls our service layer?
ehh. What kind of method is Service1.CreateObject(object obj)? That looks just wrong.
Using WCF Service is the right approach. (As you need to host this as web-api and web-api is over http).
In your mvc application you can consume the service by endpoint url.
Time factor depends on the connectivity between your servers(WebServer for MVC app and the Server to host WCFservices).ideally it should not be a bottle neck.
Still you can do unit testing of MVC code (as service layer call can be mocked.(using Moq/NMock?RhinoMock...))