In general terms, software systems are (usually) broken up into "layers" (such as the User Interface (UI), Business Logic (BL), Data Access Layer (DAL) and so on). These layers also provide natural places to integrate with. So...
the access to the data on database has
to be by this way or I need to provide
a Service?
From what you've said I would think other systems should integrate via a service, or API. Giving direct access to the database means that they'll side-step the Business Logic that should apply to the interactions they want to perform. In your specific case it will probably also mean they'll side-step your security measures.
Modularity
There is two parts to this:
- Architectural styles and design patterns which assist modular systems (specifcially regarding maintenance and extensibility); these are all technology agnostic (it doesn't matter what technology you're using).
- Implementation and technology specific frameworks and techniques.
Design Patterns
Wikipedia is a great place to get an introduction into patterns, and StackOverflow has lots of great content around them too.
I's start off getitng to grips with what's known as SOLID, although it's all useful I think you'll find the S, O, I and D areas of most value.
Dependency Inversion (the "D") is going to be particularly relevant to you as far as modularity goes. By creating a "contract" via an interface, you create something that other parties can build on - for example: they can swap out your "default" implementation with one they have made.
Technology Specific
I can't speak specifically for Java (although it should be easy for you to find out) but .Net has a few frameworks that are specifically built for this kind of thing, e.g: the Managed Extensibility Framework (MEF).
The point is that most technology stacks will offer various frameworks, tools and approaches for building modular systems.